關於如何把項目作得更好的一次思考

以前作開發的時候對項目徹底沒有一個總體的思考，需求來了就知道作，只關心本身作的那部分的功能，作完拉到。但最近所作的項目中，遇到了很多問題，本身都忍不住吐槽起來了。如：項目常常性延期、代碼冗餘、添加一個很小的新功能都須要改動不少地方，還對以前的代碼邏輯產生不小的影響。這使得我不得不對現有的項目進行思考。

怎麼樣才能把項目作的好一點或者更好？
首先，在老闆看來，他確定但願今天提的需求能夠立馬就上線。
而後，老闆但願咱們作出來的產品有很好的用戶體驗，有良好的性能。
最後，但願系統可以穩定運行，出問題時可以儘快修復。

固然，這只是我腦補出來的（我我的的想法，至於老闆是否是這麼想我就不清楚了）。

從技術上來講就是：

• 能夠快速搭建
• 擁有比較好的性能
• 邏輯清晰，易於維護、拓展
• 快速解決線上問題

如何進行快速搭建？

1、組件封裝：公共樣式、邏輯提取。
有時候，咱們須要作一個統一的自定義彈窗樣式，或者自定義的下拉框等。咱們封裝成公共組件以後，其餘地方須要用到時，只需引入組件和傳入數據便可使用，不須要再重複的去寫樣式或者邏輯。有些甚至不須要設計再從新出圖，利用組件就能夠完成咱們的頁面開發了。
封裝前：
多個頁面中，一樣的頁面樣式和js邏輯沒法複用，須要在每一個頁面中進行代碼的複製粘貼，極可能會漏掉部分代碼。發生樣式或者js邏輯改動時須要每一個頁面都改一遍，很容易漏掉。
封裝後：
可進行代碼複用，多個頁面中，一樣的頁面樣式和js邏輯直接引用封裝好的組件便可。發生樣式或者js邏輯改動時，只須要改一個地方便可。

2、 項目的基礎搭建
新開一個項目的時候咱們都須要先去作一些基礎搭建，好比說：項目目錄結構、登陸模塊封裝、http請求處理和其餘輔助小工具等等。這些東西咱們能夠作成一個npm包，發到公司內部的私有倉庫裏，使用的時候直接一個npm install 就能夠快速的完成項目的基礎搭建了。

邏輯清晰，易於維護、拓展

深刻理解產品需求，將功能邏輯劃分，對應成相應的代碼邏輯：

• 哪一部分樣式能夠封裝
• 哪一部分功能能夠封裝
• 頁面裏各個邏輯的關係：點擊一個按鈕，頁面中的其餘展現要如何變更
• 各個頁面之間的邏輯關係：在當前頁面操做，其餘頁面需不須要作出相應的變更

若是開發時不看需求文檔，到了最後除了撕逼以外還得返工。

與其餘功能模塊對接時儘可能多考慮，作成可拓展的通用模塊。與某個模塊對接時，如何與當前模塊完成對接是咱們首要考慮的事情。考慮完這方面的事情以後，咱們還要考慮一下再有另一個模塊或者多個模塊接入時咱們要如何才能在代碼改動量最小的狀況下進行快速接入。

關於註釋：
註釋是有必要的，這個對我的和他人都是有好處的。本身一個月以前寫的代碼，沒有註釋再回去看時可能也不太懂，況且是別人呢。
若是能夠的話，每一個js文件的開頭簡單描述下當面頁面的功能邏輯，讓維護的時候能快速的瞭解到當前頁面上的東西。

關於文檔：
你們都去遵循必定的規範才能更好的去共同創造/維護一個東西，這些規範造成以後必定要遵循下去。當一個新的小夥伴加入到咱們的時候，咱們不可能把每個規範都口頭的跟他講通常，咱們本身也記不住那麼多規範。因此，將這些規範整理成文檔頗有必要，記不清楚或者不瞭解的時候能夠從新去翻一翻。還有咱們封裝好的組件，其餘人使用的時候也不可能花時間去看看你的源碼，或者老是來問你要怎麼用。這樣會很浪費你們的時間，阻礙整個項目的進度。因此，組件的用法、入參/出參、注意事項等等咱們都須要再文檔裏面描述清楚。

擁有比較好的性能

根據當前作的項目，使用的技術棧，找出引發性能問題的點，逐個進行優化。就拿我當前作的這個原生小程序來講，性能問題主要在如下幾點：

• 頻繁的調用setData。
• 在後臺進行多個數據請求並進行多個頁面setData操做。
• 首次加載小程序時包下載比較慢。

解決方案
問題1: 避免頻繁的setData, 將能夠合併的setData合併，不在頁面渲染的變量不在data裏聲明，在page下的其餘字段裏聲明便可
問題2: 當面頁面的改動須要刷新其餘頁面時，不須要當即對其餘頁面進行數據刷新的動做，給須要刷新的頁面加個標識，等到該頁面顯示時經過onShow聲明週期來判斷並刷新 數據。
問題3: 使用小程序的分包加載，加載首頁時只需先下載分包便可，提升首頁加載速度。

快速解決線上問題

遇到線上的bug應該快速的響應和積極的定位問題出現的緣由，從根本上去解決問題，而不是說這不是個人問題，我不用管。
儘早發現問題，在形成更大的影響以前解決問題：
自行搭建一個錯誤收集系統，收集js腳本錯誤和接口請求錯誤的相關信息，爲定位問題提供幫助，還能夠根據錯誤的峯值來檢查當前系統是否異常。怕麻煩，圖省事的還能夠花錢使用fundebug。

日前能想到和記得的就只有那麼多吧， 先記着，以避免遺忘。