我是如何開發維護8千多行代碼組件的

我是如何開發維護8千多行代碼組件的

背景

• 我在明源雲，咱們是國內最大的地產Saas平臺
• 任何系統都會有遺留項目，越大的公司就會有越多這樣的項目
• 組件行數多，原生事件多，技術棧剛從React0.14版本升上來,UI組件庫也是大量使用了老舊的組件庫
• 業務極度複雜，極度複雜！

爲何會大量出現8K多行甚至1W行的代碼

• 單個頁面的業務邏輯設計太過複雜，沒有拆分
• 實現業務邏輯時候沒有考慮組件拆分,或者組件拆分不夠細緻
• 組件不夠純粹,做爲一個組件，最好的狀態就是一個小孩子，父母(父組件)告訴它怎麼作，它就應該怎麼作(即具體業務邏輯由組件內部實現,可是實現哪一種業務邏輯應該讓父組件控制)
• 存在大量計算邏輯並且純函數封裝度過低,若是純函數封裝度高，能夠用FAAS甚至Serverless來解決這個點

如何維護迭代

• 熟悉業務的人梳理核心業務主線，畢竟８Ｋ多行的代碼，不可能所有梳理清楚了。可是主線要梳理清楚
• 逐漸重構,不斷重構。聽起來一句大話，其實大道至簡，你今年用最新的技術，三年後可能看起來就是一個很老舊的技術。只有不斷、逐漸、從局部到總體的重構才能遇上時代的潮流,擁有不錯的開發體驗
• 業務邏輯千絲萬縷,像我此次一共寫了500行代碼不到,引出了50多個BUG，而這個組件內部只是加了十行代碼（僅僅一個函數）. 跟這塊業務不熟悉也頗有大關係,必定要梳理輸出整個核心業務主線文檔。
• 嚴格遵循單向數據流,不使用髒數據,這是底線。老組件8K多行大量的髒數據,例如:

this.state.xxx = 'ooo'

• 組件拆分，不能超過500行。嚴格來講，一個組件不能超過200行代碼，我在公司是作了webhook檢測的，只要超出就會企業微信全體通知而且@對應的代碼推送人.
• 剔除反作用,儘可能封裝無反作用的純函數,原本業務不該該放在前端處理，這也是爲了將來幾年可能FAAS和Serverless化作準備
• 堅信祖傳的代碼是穩定的,不要試圖去修改祖傳的代碼,存在即合理，若是寫代碼的人已經離職，必定不要觸碰他的代碼.有的代碼寫出來看起來很難閱讀,很不合理,可是確定有他的實現邏輯。（除非你有百分百的把握，可是誰又能說絕對呢？一次大的線上事故，特別涉及到金額的時候，不是一個普通開發能抗住的）

最後

• 這段時間沒寫文章，主要是公司比較忙，還有學習計劃還沒有完成
• 臨近國慶，最近就不發文了，下個月會輸出1-2篇
• 如今，我要去修車了，前天晚上刮到一輛奧迪A6，心痛中。