工程師應該如何保證代碼質量？

12-28

在目前行業內的成熟方案有如下幾個

1、代碼評審。
2、單元測試
3、靜態分析工具

還有幾個手段是業界在嘗試的
1、結對編程
2、代碼建模
3、編譯分析

據說所有的工程項目中，質量、成本、時間三者每次只能保證其中之二。而作為一個工程師，聰明、原則、守時也只能同時達其二。

身為工程師，聽項目經理（我們那行當叫工程負責人）指揮、按要求寫好代碼畫好圖，要是再能和同事、業主和睦相處，就太好了。

設計和實現一定要分割開來。起碼在較大的層面上分割開來。
一旦你需要同時創建介面，還要同時完成介面的實現的時候，危險就已經在等著你了。
等到你開始頻繁地修改介面函數的參數，名稱和語義的時候，你的代碼質量就在迅速下降途中。

不要同時工作在多個抽象級別上。

Feb,2015補充：
1.學會將思維過程外化，UI草圖，需求和概要文檔之類就是思維外化的工具。
2.做事的時候學會找到「尺子」，比著做。學會比照著上一階段思維外化的產物來進行本階段的設計，當你學會把一個任務分解為各個環環相扣的流水線式的簡單操作時，你就距離專業更近了一步。

俺最近也在想這個問題。因為碼農們堆代碼是碼農堆代碼的思想，並不是質量保證的思想。二者都兼顧是很難的。特別是你一個項目緊，還有一些坑都不清晰就要開始動手的情況下，很難~
總結以下的一些方法。

1，通過測試的同事來測試。這個是最最靠譜的。不過比較遺憾的是，別人直面你的bug，這個比較不爽~甚至影響到KPI。

2，通過測試用例。寫程序之前，根據需求寫好測試用例。寫完了以後跟著測試用例跑一遍。這個有助於掃清一些新功能的地雷。但是寫業務梳理需求分析功能設計代碼模塊部署文檔了還要寫測試用例，這個其實很麻煩的。。。

3，時間。項目開發之前就要預約好時間測試時間和風險時間。否則開發的時間都不夠，談何測試。

4，代碼審查（code review）。這個有待討論。如果是一個熟悉業務，已有代碼的人review你的程序，肯定是好的；但如果是一個不熟悉的碼農review，可能review出來的是一些代碼規範，或者小性能細節。對於質量保證每多大影響。

希望拋磚引玉，樓下有大牛補充~

1.單元測試；
2.不斷重構；
3.code review；

一個月的工作量壓縮到一周你怎麼保證代碼質量。

排期排長點，有足夠的時間才能保證質量

個人覺得比較靠譜點的就是代碼審查和單元測試這兩個。
代碼審查應該由懂業務，並且有編碼能力的人來操作；
單元測試，這個肯定是有自己來弄了，一定要結合實際需求，檢查輸入和輸出。
另外就是在業務需求不斷變化的過程中需要不斷重構那是最好的。也可以慢慢培養團隊人員的重構習慣，且不可因為改了一個BUG引起更嚴重的BUG。
最近也是因為這個問題傷了腦筋，也是在思考。

1.累積代碼
2.不斷完善

把代碼體系構建成這麼一種方式：當有可能因為疏忽導致bug的時候，在編譯時或者運行時能獲得提示，無論這個bug有多微妙

當你通過精巧的設計把所有疏忽之門都堵上，或至少安裝上了警報器以後，代碼質量就有數量級程度的飛躍

論程序員的自身修養:

Code Complete
Clean Code
Refactoring
The Art of Unix Programming

看完這幾本自然有答案. (其實我也沒有看完, 囧)

不過並不妨礙我拋磚引玉說幾條

需求分析要到位, 實在搞不定, 用快速迭代的開發流程.
不能做和客戶談笑風生的程序員不是好領導.
數據結構比代碼邏輯重要.
邏輯和實現(用抽象層)分離. (policy | mechanism)
如果用的是面向對象的語言, 注意保證S.O.L.I.D.
代碼審查是個寶
代碼規範少不了
重構是把雙刃劍, 條件不成熟要慎用.
重視工具, 多寫腳本, 磨刀不誤砍柴工. 起碼做到自動測試和連續集成.
程序員自己寫單元測試, 自動測試
...