之前做開發的時候對專案完全沒有一個整體的思考，需求來了就知道做，只關心自己做的那部分的功能，做完拉到。但最近所做的專案中，遇到了不少問題，自己都忍不住吐槽起來了。如：專案經常性延期、程式碼冗餘、新增一個很小的新功能都需要改動很多地方，還對之前的程式碼邏輯產生不小的影響。這使得我不得不對現有的專案進行思考。
怎麼樣才能把專案做的好一點或者更好？
首先，在老闆看來，他肯定希望今天提的需求可以立馬就上線。
然後，老闆希望我們做出來的產品有很好的使用者體驗，有良好的效能。
最後，希望系統能夠穩定執行，出問題時能夠儘快修復。
當然，這只是我腦補出來的（我個人的想法，至於老闆是不是這麼想我就不清楚了）。
從技術上來說就是：
- 可以快速搭建
- 擁有比較好的效能
- 邏輯清晰，易於維護、擴充
- 快速解決線上問題
如何進行快速搭建？
一、元件封裝：公共樣式、邏輯提取。
有時候，我們需要做一個統一的自定義彈窗樣式，或者自定義的下拉框等。我們封裝成公共元件之後，其他地方需要用到時，只需引入元件和傳入資料即可使用，不需要再重複的去寫樣式或者邏輯。有些甚至不需要設計再重新出圖，利用元件就可以完成我們的頁面開發了。
封裝前：
多個頁面中，同樣的頁面樣式和js邏輯無法複用，需要在每個頁面中進行程式碼的複製貼上，很可能會漏掉部分程式碼。發生樣式或者js邏輯改動時需要每個頁面都改一遍，很容易漏掉。
封裝後：
可進行程式碼複用，多個頁面中，同樣的頁面樣式和js邏輯直接引用封裝好的元件即可。發生樣式或者js邏輯改動時，只需要改一個地方即可。
二、 專案的基礎搭建
新開一個專案的時候我們都需要先去做一些基礎搭建，比如說：專案目錄結構、登入模組封裝、http請求處理和其他輔助小工具等等。這些東西我們可以做成一個npm包，發到公司內部的私有倉庫裡，使用的時候直接一個npm install 就可以快速的完成專案的基礎搭建了。
邏輯清晰，易於維護、擴充
深入理解產品需求，將功能邏輯劃分，對應成相應的程式碼邏輯：
- 哪一部分樣式可以封裝
- 哪一部分功能可以封裝
- 頁面裡各個邏輯的關係：點選一個按鈕，頁面中的其他展示要如何變動
- 各個頁面之間的邏輯關係：在當前頁面操作，其他頁面需不需要做出相應的變動
如果開發時不看需求文件，到了最後除了撕逼之外還得返工。
與其他功能模組對接時儘量多考慮，做成可擴充的通用模組。與某個模組對接時，如何與當前模組完成對接是我們首要考慮的事情。考慮完這方面的事情之後，我們還要考慮一下再有另外一個模組或者多個模組接入時我們要如何才能在程式碼改動量最小的情況下進行快速接入。
關於註釋：
註釋是有必要的，這個對個人和他人都是有好處的。自己一個月之前寫的程式碼，沒有註釋再回去看時可能也不太懂，何況是別人呢。
如果可以的話，每個js檔案的開頭簡單描述下當面頁面的功能邏輯，讓維護的時候能快速的瞭解到當前頁面上的東西。
關於文件：
大家都去遵循一定的規範才能更好的去共同創造/維護一個東西，這些規範形成之後一定要遵循下去。當一個新的小夥伴加入到我們的時候，我們不可能把每一個規範都口頭的跟他講一般，我們自己也記不住那麼多規範。所以，將這些規範整理成文件很有必要，記不清楚或者不瞭解的時候可以重新去翻一翻。還有我們封裝好的元件，其他人使用的時候也不可能花時間去看看你的原始碼，或者總是來問你要怎麼用。這樣會很浪費大家的時間，阻礙整個專案的進度。所以，元件的用法、入參/出參、注意事項等等我們都需要再文件裡面描述清楚。
擁有比較好的效能
根據當前做的專案，使用的技術棧，找出引起效能問題的點，逐個進行優化。就拿我當前做的這個原生小程式來說，效能問題主要在以下幾點：
- 頻繁的呼叫setData。
- 在後臺進行多個資料請求並進行多個頁面setData操作。
- 首次載入小程式時包下載比較慢。
解決方案
問題1: 避免頻繁的setData, 將可以合併的setData合併，不在頁面渲染的變數不在data裡宣告，在page下的其他欄位裡宣告即可
問題2: 當面頁面的改動需要重新整理其他頁面時，不需要立即對其他頁面進行資料重新整理的動作，給需要重新整理的頁面加個標識，等到該頁面顯示時通過onShow宣告週期來判斷並重新整理 資料。
問題3: 使用小程式的分包載入，載入首頁時只需先下載分包即可，提高首頁載入速度。
快速解決線上問題
遇到線上的bug應該快速的響應和積極的定位問題出現的原因，從根本上去解決問題，而不是說這不是我的問題，我不用管。
儘早發現問題，在造成更大的影響之前解決問題：
自行搭建一個錯誤收集系統，收集js指令碼錯誤和介面請求錯誤的相關資訊，為定位問題提供幫助，還可以根據錯誤的峰值來檢查當前系統是否異常。怕麻煩，圖省事的還可以花錢使用fundebug。
日前能想到和記得的就只有那麼多吧， 先記著，以免遺忘。