程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> JAVA綜合教程 >> 三年0故障總結,提升代碼質量的秘訣

三年0故障總結,提升代碼質量的秘訣

編輯:JAVA綜合教程

三年0故障總結,提升代碼質量的秘訣


個人經歷

對我代碼質量影響最大的是在一家外資企業,在這家公司我覺得有以下幾個方面做的很不錯。

  • 團隊編碼風格統一
    • 統一到什麼程度? 不看代碼作者,你很難區分代碼是誰寫的(在目前公司一些團隊也能達到這個標准)。

個人觀點:

  1. 這樣做有什麼好處?團隊中每個人閱讀代碼都很容易,減少很多溝通,維護成本(代碼閱讀的次數遠遠大於變更的次數),並且心情非常愉悅。有人肯定覺得愉悅有點誇張,舉個栗子: 有一些代碼,如果不是由於與工作內容有關聯,你是否有種這輩子都不情願去接觸它的感受。但也有一些代碼,閱讀下來一氣呵成,心情舒暢,促使你有種繼續閱讀下去的沖動(並且你也會有種不想破壞這種統一的想法).
  2. 基礎層面越統一,效率越高(不僅僅是指統一編碼規范,還有基本的做事的原則). 舉個栗子: 我們團隊規定個人周報必須在每周五上班前必須發出來,否則罰款10元。之前團隊周報遲發現象比較突出,規則一出,明顯改善(開會缺席情況也一樣得到明顯改善)。罰錢是否不太合理?注釋寫多少才算合理?與其花大量精力討論這些不痛不癢的問題,不如及時統一規范(一般制定的規范不會差的),嚴格執行。後續針對問題即使做調整。關鍵是統一和嚴格執行。
  • 代碼簡潔
    • 能1行解決就不要寫2行(不影響可讀性的情況下)
    • 多余的代碼(比如注釋代碼 or 無實際意義)必須刪除

個人觀點: 大家都懂的, 沒啥好說的

  • codereview
    • 團隊的PLA(團隊骨干)進行codereview, 團隊中PLA之間的代碼質量意識/以及代碼規范非常統一.不會出現一個團隊,多個標准的情況
    • 每周五周會會對這周代碼review出來的問題進行回顧,得出結論。將例子放在wiki上,以供後續遇到類似問題的一個參照。新同學也可參照此內容學習規范,避免犯同類問題。規范中很多內容就是這麼累計起來的。

個人觀點:

  1. 我在阿裡所經歷的一個團隊中,PLA有3,4位, 分別負責各自的一塊業務。PLA之間codereview很少,代碼質量的意識交流似乎也不多。但團隊的普通開發同學在這些PLA之間輪流被codereview, 代碼質量的評比標准差異較大。這可能會導致2種現象:開發傾向review寬松的同學, 因為寬松review發現問題(不僅僅是bug)較少,變動成本不大,不會有改動造成的故障風險,不會影響項目進度(但後續的維護和溝通成本會明顯增加);另一種現象, 開發向不同的PLA提出疑義,PLA之間統一代碼質量標准,在團隊內達成共識並形成文檔,以作為後續參考。
  2. 一個團隊的代碼質量主要取決於團隊幾位PLA,建議團隊早期先統一PLA的代碼質量意識和規范。例如: 先由1-2位PLA對整個團隊開發做review,這個review工作量初期會很大, 並且團隊工作效率不高,但後期的review工作量應該會明顯減小, 代碼質量也會明顯提高, 團隊的工作效率也會明顯提升.

    我在外企這家公司剛入職的那一個月是我最痛苦的一個月,被codereview感覺很不適應:和以前編碼習慣差異較大,review太嚴格(變量名,空行,注釋有單詞語法錯誤也會糾正),感覺限制編碼自由.... 1個多月後體會到了明顯的好處: 編碼bug少; 溝通少,代碼和注釋已經解決了大部分疑問;閱讀代碼效率高; 感覺別人寫的代碼就像是自己寫的一樣,非常有親切感.一個多月後, revew我代碼的PLA明顯放松了對我review的內容,因為他已經很多次沒有review出問題,並且讓我在每次review前告知需重點review的內容即可。


閱讀全文請點擊:http://click.aliyun.com/m/8717/

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved