如何保證高質量代碼

如何保證高質量代碼？

有時候程序員會很苦惱，為什么自己這么多bug；有時候測試人員更苦惱，為什么這么簡單的case都有bug。是的，對于資深測試人員來說，他們更愿意去發現深層次的bug，而不是總是被一些小小的，顯而易見的bug給困惱。要知道，反復測試這種bug，對自身來說，也是毫無意義的。

我的身份之一就是程序員，而我敢寫這篇文章，證明我在保證高質量代碼方面還是有些經驗可分享的。廢話不多說，下面就“如何保證高質量代碼”這個話題進行詳細的說明。

背景說明

我現在所在項目是一個年代久遠的項目，有成熟的框架，代碼量已經積累很多，頁面風格固定，時不時會來些大大小小的需求。

方法論

一、拿來主義

如果你的項目背景跟我的項目背景是差不多的，那么拿來主義是非常受用的。項目中已經積累了大量的代碼，很多難點都有“先人”的代碼作為參考，而且“先人”的代碼是經過測試的，所以是經得起推敲的。與其自己新寫一套方法，還不如站在巨人的肩膀上，拿來并學習來得更容易。當然，這并不是說直接拿過來就行了，要結合自己的情況，修修補補，也可以想想，自己是否有更好的方法或者有補充的地方。站在別人的肩膀上的意義就在于，不需要從頭到尾另辟一條路出來，只需要根據別人開辟出來的路來鑒定是否能到達自己的目的地。

所以一拿到需求，分析下阻礙你的難點，再分析下該難點是否在項目中有類似的做法，有則選擇參考。不要一味地陷入自己的思維里。現在項目組就有一個成員，很多問題明明就有參考答案，卻硬是要自己作答，還答得并不比參考答案好。

二、經驗總結，總結分享

只要寫代碼，可以說大大小小的難題肯定是遇到過。此次的難題會不會成為你下次的難題，這就要看你愿不愿意總結了。每次遇到難題，都把它記錄下來，這樣形成自己的一個知識簿，隨時都可以翻閱。在編碼過程中，很多解決方案可能當初或問同事，或查閱資料，或自己百般嘗試才得出來的。很長一段時間過后，可能只是覺得自己曾經解決過這個問題，但是具體方案已經很模糊了。如果不想再次從頭開始，那就好好總結并記錄吧。

分享總結，更能提升你的成就感，加深對問題的印象，更能幫助項目成員少走彎路。總結分享給他人，記錄他人的總結，讓開發代碼既有效率又有質量。

三、邏輯思考

大的需求下來之后是要分成好幾個人開發的。分到自己手上，可能已經不是一個完整的故事，只是當中一個情節。那么我們是不是應該只關心自己的這一個情節呢。有人會說，當然只關注自己這塊啊，分工合作不就是這樣嘛。是的，每個人關注那么一點點，是叫分工。把一點點硬生生的合在一塊，那就不一定叫合作了。

我們做開發的時候，不是照著別人的設計寫就行了。我們還必須關注設計是否合理，關注case是否覆蓋到，關注邊界值，關注故事的合理性，關注故事是不是一個完整的故事，等等。很多人寫代碼，都是一種事不關己的態度，覺得我只負責把設計寫成代碼，而且只把屬于自己這塊的設計寫成代碼。這不是合作。設計人員就算再細心，再厲害，也會有考慮不周的時候。如果開發愿意去發現設計的不周全，愿意真正以合作的態度去做好一個需求，那么開發的質量是不會差到哪里去的。

四、整理思路

很多人一拿到需求就迫不及待的寫代碼，這樣做很可能造成代碼的反攻，整個結構的重組。拿到需求的時候，還是要分析并整理下代碼的思路，就算是稍微在腦子里把整個思路過一遍也好。對于復雜的邏輯，就需要在本子上寫寫思路，寫寫偽代碼。只要思路出來了，寫代碼還是很快的。所以不要急著去堆代碼，一不小心會讓代碼砸了腦袋。

五、深入測試

開發要保證代碼質量，必不可少的就是測試。誰人能保證自己新鮮出爐的代碼沒問題。開發過程中，可能很多case，很多細節不會去細想；也可能一不小心造成筆誤。那么如何去發現這些隱藏的bug？測試，測試，再測試。代碼的每個分支都要測一測。不要想當然覺得某塊代碼沒問題，千萬不要對未經過測試的代碼表現出如此的自信。隨著測試的case越多，你代碼的bug就越少。

沒有bug的代碼都是經過反復測試，反復修改的。我從不對自己的代碼表示自信，除非它經過了我不斷的測試。

希望對大家有幫助，共同進步，共同學習。

來自：http://www.jianshu.com/p/1e2513921a87