Developer Productivity Report 2013 - How engineering tools & practices impact software quality & delivery
在這份文獻中, 針對了很多基礎的practice 做了些調查, 其中有關於程式碼檢視 (Code Review) 這個實務的調查, 是一個有趣的結果. 很少人想要實施, 可是一旦實施效果卻很顯著.
77 % 人的不做”程式碼檢視”, 或者是很少做. 可是如果能進行程式碼檢視的話, 將會使你的時程是比較可預測的, 大約可以達到 58% 以上的準確率.
另一點令人玩味的地方, 開發人員不擅長從程式碼中找出問題, 而是比較擅長從設計或是大方向中, 看出系統有什麼狀況. 因此, 開發早期時就能檢視設計對不對, 那將會對產品品質有較大的幫助.
還有, 從這些調查也發現, 如果你對所有 commit 的程式都做檢視, 可預設性會到 61%, 品質上會有 59% 的機率是後不會發現 critical bugs. 這似乎告訴我們, 這些基本的 practice 是一定要做的, 但是是否不惜代價全部都要做, 可能就要考慮一下, 要平衡一下投資報酬率. 所以對於一些重要的 commit 去做 review, 已經可以獲得很好的效果.
看到這裡, 我的感想是這樣的. 大多數人對於這些很有用的 practice, 會認為要做到很難, 會覺得沒有時間去做.
因為他們覺得去做的意思, 就是要 100 分, 也就是要做到完美才是真的在實踐這個 practice. 例如 code review, 就要所有的 code 都 review, 才叫做有在做 code review, 否則就是假的.
就像在實施 scrum 時, 他們可能只做到 sprint planning meeting, sprint review meeting, 但是沒有做 retrospective, 他們就會說他們並沒有真的在做 scrum.
或者在做 test automation, 他們認為只有些幾個自動化的 case, 沒有 unit testing, 只是 end to end, 涵蓋度又不高, 就會和別人說: 我們並沒有真的自動化.
可是真的做一些就不好, 就沒效果嗎? 或者一定要做到 100% 就是好的嗎?
我想這份調查報告給了很好的答案. 很多 practice 只要妳開始用, 效果就會浮現, 只要有 30%-50% 的地方能用上, 你就會獲得很不錯的投資回報. 不需要每個地方就採用.
所以朋友們, 不需要再猶豫, 有開始就有希望. 放手去做, 做到你能承受的地步就好. 這樣就會有很好的回報了.
全站熱搜
留言列表
