鼎叔的編程慢習慣

這次談談純技術，談一些編程習慣的事情。n

標題是「編程慢習慣」，為什麼是「慢習慣」呢？n

因為我今天分享的這些習慣在短期之內會增加時間開銷，不能立即獲得什麼收穫。但時間久了，至少對我自己是非常有幫助的，為我節省了不少的時間同時在編程能力上也獲得了成長。n

另外在啰嗦一下，本文並非針對高手的，如果您是高手，可以跳過後面的內容了，接著看下去會耽誤到您寶貴的時間。n

一、做自己的需求文檔n

我們在編程時，是否充分的了解了需求，關係到我們後續所開銷在項目上的時間。做一個新功能通常不會讓我厭倦，但是一次次的修改卻會讓我身心疲憊。特別是一些本身就時間緊任務重的項目，就意味著需要一整晚又一整晚的加班趕工了。n

具體比如說，以下3點會大量增加我們的時間精力投入：n

• 需求本身就存在問題，邏輯無法走通，但是這個時候已經寫了不少或者和之前的代碼衝突到了
• 部分需求沒有表達清楚，溝通後發現對時間的需求誤判了，規定時間內完成變得困難
• 寫到一半，發現自己思路不對不得不重頭開始整理

解決這些的方法每個人都有每個人的選擇，我的選擇是做一份自己的需求文檔。這份文檔內容並非是產品經理或者技術主管、需求方所表述的，而是基於我的理解進行的二次整理。n

需求文檔當中大概有這麼幾部分的內容：

1.項目的基本概述n

• 項目的簡述，這個項目到底在做什麼
• 完成的目標，最終使用人對於使用這個系統的實際需求
• 預計交期，DEMO演示的日期，交付測試的日期，上線的日期

2.項目的資料n

• 伺服器賬號和環境
• 需求文檔
• 開發、生產環境需求
• 參考的項目或代碼
• 溝通會議記錄

3.業務相關n

• 業務核心邏輯，通常還會轉換為初步的實現邏輯
• 執行流程

4.實現n

• 需要做的功能拆解
• 數據規模
• 實現方式
• 對現有系統影響的改動點，如果是全新系統可以忽略

5.其他n

• 測試單元規劃

記錄完這些內容會花掉不少時間，中間可能還要跟需求方、產品經理進行多次溝通。至於細節到底多細，沒有一定的標準，視項目和個人情況而定。n

最重要的是做到心中有數，對開發周期的心中有數、對模塊大致劃分的心中有數，對內部流程的心中有數。n

花力氣為自己做的需求文檔。在完成後，不僅核心要點印象深刻，後期檢索也會非常方便，最大限度在已知條件下降低走彎路的概率。從過往經驗來說，等到開始開發以後再去查聊天記錄，或者是找相關人員詢問，就慢的多了。n

二、用最笨的方法先去實現n

需求文檔做好了之後，我就會開始動手寫代碼，會把需求文檔中最核心需要實現的業務邏輯獨立分解出來，做一個Demo。按照輸入、處理、輸出，三個部分進行編寫。n

基本上不會去寫太多的注釋。也不會去想模組如何構建以及語法是否美觀可讀、效率是否是最優。能夠得到正確的輸出結果為第一位有優先。這樣做可以隨意修改，而且代碼量少，如果實現過程出現問題，很容易就可以定位到原因。n

把功能實現以後，先做壓力業務邏輯測試，沒有問題，再移植到項目中。移植的過程時，本身也是對代碼邏輯的Review，思考實現的合理性與是否需要進行一些調整。n

這裡還有一個重點，通常稍大的項目是無論時間有多緊張，也不能不經思考直接的去把代碼直接複製進去。給自己挖坑的事情越少做越好。n

三、做壓力測試調整結構設計n

很多程序員習慣把代碼先寫完，交付前最後在做性能測試，如果前面的設計就沒有考慮到性能問題，就很頭大了，代碼也沒有時間可以重寫，就這麼將就著先用了。最後一直被性能問題所困擾著。n

業務的需求和壓力在哪裡，產生瓶頸的核心點在哪裡。如果你做為程序員也能懂這些，不僅有效避免後續的修改次數，自身價值也會更高。n

所以我在DEMO實現後，就會習慣性考慮性能問題。模擬預想中會出現的高並發高流量，自己寫一個壓力測試模塊。如果發現有問題，先修改DEMO中的核心代碼及實現方式，調整到自我認為平衡為止。n

四、儘可能的砍掉代碼冗餘n

同樣的實現，通常有多個方案可以去實現，我在一開始做的時候，用的可能是當時想到的快速實現方案。n

當想到更好替代方案時，不太會猶豫，保證安全和性能的前提之下會砍掉原有的代碼。用更簡單的邏輯的寫法替換到冗餘的代碼。n

五、多留日誌n

就算測試的再完美，上線之後也難免會出問題。這之中，既有可能是本身伺服器運維方面的問題，也有可能是BUG。如果能再現的故障還算好查，最怕一些偶然發生，但又無法復現的問題。負責運維和開發的工程師兩邊都會非常頭疼，難以快速解決，還會相互扯皮。n

所以我會在代碼里儘可能的多留一些日誌，並且把這些日誌自動進行一些採集。這樣，如果有發生問題，第一時間就會有大量的數據可以去查詢，對定位問題非常有幫助，不必再一點點的去調試，一個個模塊去排除。n

同時如果對業務數據的準確性非常敏感的系統，除了一些常規的日誌外，我還專門針做一些對業務邏輯校驗的日誌，定時通過一些自動化的程序去檢核這些數字。通過結果反推是否存在一些沒有預料到的問題。n

六、忘記編代碼的過程，以其他人閱讀角度進行修改n

雖然程序是給計算機去執行，但是無論是業務的擴展還是BUG的修復、性能提升、演算法優化，都需要通過人來進行。寫好一組代碼之後，並不100%保證自己或其他工程師以後完全不會去做維護。n

基於這個考慮，在完成基本的程序編寫之後，我還會習慣先強迫自己忘記之前寫的代碼，以第三者的視角再來審視一遍程序：n

1、程序邏輯是否清晰易懂n

2、代碼命名是否規範n

3、有沒有留下足夠的注釋線索n

4、一個模塊中是否過於複雜n

5、是否留有進一步改進的餘地n

是選擇前人挖坑後人埋，或是選擇前人種樹後人乘涼，都看寫的人自己的一念之差。但本著負責任的態度，任何情況下都少挖坑為妙。挖了坑，是出來混的，最後總是要還的。

七、記錄錯誤n

這一點和項目沒有關係，但是和個人成長會有直接關係。就像我們中學時做的錯題本一樣，從錯誤中學習是最快的方法。通過錯誤的記錄，發現我們究竟是哪一部分有待提高，是語法不熟悉，是思考不夠全面，還是一開始就用錯了。有了記錄我們就會有可以去發現問題的線索。n

依靠這些線索進行思考，主動意識到我們經常出錯的部分之後。總可以有針對性的去解決。解決後接下來不定期的去反思，通過反思，將學到的能力內化形成戰鬥力。n

最後總結一下，我今天分享的七個慢習慣：

1、做自己的需求文檔，讓自己對將要做的內容心中有數，盡量避免理解不到位所付出的成本。n

2、用最笨的方法先去實現輸入、處理和輸出。核心邏輯優先。不去過多考慮其他問題。n

3、整合項目前，做壓力測試達到一開始的性能需求。而不是全部做完之後再去做性能優化。n

4、如果覺得代碼不合理，盡量多砍掉不合理的代碼進行重構。n

5、多留日誌讓不可預期的問題容易定位、分析、解決。n

6、讓代碼具有可讀性，別給自己與別人挖坑。n

7、記錄經常犯的錯誤，及時反思總結。n

以上是我的心得，歡迎各位同學與我交流。
推薦閱讀：