gistfile1.txt

大哉問，但是我覺得我沒辦法正面回答。

在《人月神話》裡面有提到軟體開發的一個現象，
就是軟體越大，維護越困難（廢話）。
這是因為初期的設計不可能考慮到後期的需求，
所以增加新功能，要顧慮到所有與原有設計接合的部份，
所以增加一個新功能的成本，跟這個軟體的規模成正比。
也就是說，當軟體規模是 10 的時候，加一個新功能成本的 10。
當軟體規模是 1000 的時候，增加一個新功能的成本就變成 1000。
軟體隨著時間，越開發越大，最後新增功能的成本會超過其效益，
這個時候這個軟體就應該被拋棄，也就是砍掉重練，重新設計。
所以，一個設計是有其壽命的，他會死。
當一個設計的壽命到達盡頭之前，
團隊就應該要開始另一個設計，
以便在前者結束之後接續其任務。

如果開發者沒有這種認知，
就會一直付出極高的成本維護原有程式碼，這是不健康的。
更糟糕的是等到維護所需的成本超過團隊的生產力，
程式碼的品質就會開始下降，錯誤百出，
客戶滿意度下降，連帶著團隊士氣低落。
最後最慘的就是產品結束甚至公司收掉。

我聽起來你們現在的軟體應該就是接近生命末期。

不過這是二十年前的版本，新版的人月神話有補充，
現在軟工，軟體經過不斷的重構，可以讓新增新功能的成本維持在一個常數，
也就是說在今天，重構可以不斷維持軟體的生命力。
但是重構的前置條件是測試，沒有測試的重構很危險。

所以我覺得這樣，兩條路：
一、認知軟體設計有其壽命，拋棄原有設計，重新設計。
二、不拋棄設計，對現有程式重構，延續壽命。

如果你們公司的高層，
有「軟體生命有極限」的認知，並且有重新開始設計的覺悟，
那現在應該差不多可以開始進行了。

但如果沒有，
那應該要開始擬定重構的計畫，
並根據重構計畫來擬定自動測試案例的撰寫，
測試案例撰寫完畢以後就開始重構。

我覺得 code review 可以改進程式碼品質沒錯，
但是 code review 其實也是一項需要訓練的能力。
另外，講到底，就算大家都有能力 code review，也有確實施行，
但是光有 code review 並無法阻止軟體複雜化這個強大的慣性。

※ 引述《awert ( )》之銘言：
> 想要改進公司做code review的方式，
> 因此想請教現在團隊有在做code review的人一些問題。
> ◎ 目前公司團隊 spec :
> 1. 7人小團隊，主管、兩位senior、4位junior平均進公司一年多，沒有超級強者，
>    大家進步空間很大，基本上不少人都不太清楚自己寫的code是好是壞。
> 2. 程式碼基本上是6~7年的codebase，中間有數年都沒在維護，長期下來品質很差，功能

>    多又雜，只有兩、三位知道大部份功能實作方式。品質已經影響到開發和客戶滿意度
C
> 3. 去年年初開始有review meeting，每週兩個小組在系統裡找個功能review或心得分享
A
>    目前大家算是蠻習慣的。
> 4. 使用Subversion當source control，branching strategy就每一個版號一個trunk，
>    沒有分dev/main，也很少用branch (只有主管有權限)。
> 5. QA跑光了，目前沒有專職的測試人員 (?!)，也沒有任何automated test
> 6. 我們除了有開發自己產品的project外，通常同時也還有一兩個其他project在進行。
>    通常這些都是幫客戶客製產品居多。
> ◎ 想要透過code review達到的目標 :
> 每個人寫的code都至少有另一人看過，並且能確實改掉有問題的地方。
> ◎ 我的問題：
> 1. 以目前團隊的狀況，如果想要落實pre-commit code review，會不會太勉強 ?
>    是否有更簡易的方式達到類似的效果 ? 重點是在於code有人看過
> 2. 我擔心source control使用方式不適合，開發的人可能做完一項就卡在review，
>    繼續作下去也不是，等著也不是。雖然這個問題可以靠改用DSCS解決，但是似
>    乎有點緩不應急 ?
> 3. 該找誰review、人數。另外考慮到素質問題，是否要有位gate keeper來把關 ?
>    目前我的想法是，當有人需要review時，至少需要找一位senior或是主管看過並認可
C
>    其他就看同時負責開發功能的人有誰，或是較了解該功能的人 ;
>    所以每一次reviewee + reviewer大概會有2~3人參與。
> 4. 想問看看是否有其他實行上需要注意的事情 ?
> 謝謝

一、per-commit code review 不會勉強，而且是應該的。
    大家要習慣，看多以後速度就會快，也會知道該看什麼。
    真的要作的話，就是要作到每份 code 至少都有一個人看過，
    然後重點是要看對東西 http://tinyurl.com/7lkwndw

二、切換到 DVCS 是對的，事實上切換成本很低，
    而且即使不做 code review，切換到 DVCS 也可以馬上增加生產力。
    最好明天睡醒就馬上使用。

三、這個我沒有具體建議，但是我知道的公司，
    有強制的 code reivew 人數都只有低標一個人，
    也就是說一份程式碼最少要有一個人看過，
    至於其他人要不要無聊順便看看都無所謂。
    有的公司是採取一個 senior 看 team 所有人的，
    有的公司是採取循環的，甲看乙，乙看丙，丙看賈，
    我們公司是在自由制，所有的 commit 會被 post 到一個頁面，
    大家有空就上去看，看完的人就留言說我看過了，有意見就提意見，
    有被看過 code 就可以被 merge 到 develop/master。
    然後因為採用 git，所以不會有工作流程被卡住的問題。

如果說還有什麼其他的建議的話，
我覺得如果目標是「提昇程式碼品質」，
那優先順序最高的應該是自動化測試，
一來是可以確保程式碼的基本要求「正確性」，

二來是可以為未來的重構鋪路。

但是在這之前先換成 DVCS，
mercurial 或是 git 都好，
mercurial 無腦，git 強大，
切換成本很低，幾乎可以說是順手之勞而已。
而且如果你們需要 code review 又不希望被卡住的話，DVCS 是必要的。
事實上就算不 code review 也是必要的。