關於郵箱前端架構的一些思考（續一）--功能模塊

今天主要給大家講講郵箱的功能模塊這一部分，它跟架構有着同樣的權重，因爲如果一個產品就算架構再好，功能點薄弱，這個產品也不會有太多的生命力。給大家建議一點的就是，在功能模塊這一部分，一定要結合自己開發所用到的技術，思想，融合起來，這樣才能更好的去設計一個產品的技術架構。好了，多的不扯了，入正題吧。

1.功能模塊的封裝

在這一塊，是考驗一個FEer的基本功的地方 ，一個功能模塊在實現了產品的業務邏輯與衆多功能點的同時，又保證了其模塊的內部結構組織的清晰，明瞭，這需要FEer在coding過程中不斷的去總結和思考的。我在coding的過程中，有兩三次曾推倒了之前的設計，因爲在直接的結構上，這個功能模塊的耦合性太高了，導致後續涉及到此功能模塊的其他模塊的封裝成本太高，或者是執行效率太低。不過切記，千萬不要怕重構你的模塊，因爲大多數功能你已經實現了，就是在模塊的組織上面需要花費一點功夫，這纔是你能力提升的一種很好的實踐方式。
在模塊封裝之前，你需要去自習閱讀產品設計文檔，可能某個不起眼的小功能會讓你在封裝完之後發現，自己的數據結構擴展起來代價太大，需要重新設計，這就尷尬了，無形中給自己挖了很多坑，不斷的去填一些完全可以避免的坑並不是一個FEer能力的真正展現，反而暴露了很多的問題。

在模塊封裝的過程中，你需要遵循小組內經過討論約定的規範，比如說代碼編寫規範，設計規範，暴露出來的API規範，等等，都需要你去一一的落實下來的，只有很仔細的瞭解了這些規範之後，才能更好與他人合作，也少了許多後期維護的坑。

在模塊封裝完之後，還需要考慮的就是模塊的輸入輸出，直白的講就是你需要測試下你的模塊在多種情況下輸入對應的輸出是否正常，在一些數據類型，數據結構上面一定要多加小心，舉個栗子，一個功能模塊的輸入是一個配置，那麼這個輸入的參數就需要是一個option對象，而不是像function(param1,param2,param3)這樣。

2.功能模塊的複用

這裏還是先舉一個栗子，郵箱中的收件箱，草稿箱，回收站，垃圾郵件箱等，有沒有覺得都差不多一個樣子，只不過在一些細節的地方有略微的差別罷了，所以在郵件列表和郵件詳情功能模塊就要注意了，如何去複用這些功能模塊，這是你需要結合你的實際情況去考慮的，不是所有的人都是做郵箱前端的，將思想融入到實踐中，以不變應萬變。

3.功能模塊的擴展和可維護性

模塊的可擴展和可維護性也是一個功能模塊重要的組成部分。如何實現這兩個特性，對於你的數據結構和函數的封裝有很大的關係，在代碼中多使用HOOK，原型，作用域鏈，對象，可以簡化你的coding過程，同時增強了功能模塊的擴展和可維護性。

^ _ ^