27章How Program Size Affects Construction讀書筆記

 

這章感受最深的應當是從量變到質變，程式的規模應當選擇的方法論，它影響了架構，設計，編碼等等，可以說1+1>2。一個小項目和一個大項目是完全不同的。

1. Communication and Size

項目的人數越多越會增加交流溝通的成本。這是在《人月神話》中講的很詳細。看幾幅圖就更加明白了：

人數的增加交流溝通的線條是平方級的增加，不過這裡的假設是每個人都可以隨意和其他人溝通，通常的項目中應該會有等級，幾個人會分個小組，做一個模組。減少和其它不必要的溝通。儘管這樣，溝通的成本還是很大的，於是項目文檔的重要性就突出了，它可以在一定程度上減少項目的溝通成本，可以讓後來修改維護項目的人，以及新加入項目的人員更快上手。

總結：人數越多溝通成本越大，需要文檔來記錄和溝通。

2. Effect of Project Size on Errors

程式的大小影響著程式的錯誤個數，隨著程式的增大它出錯的機率也就增加。估計越複雜的東西越容易出錯吧。當項目變大時，錯誤很多會來自於需求和設計，不過也有很多來自編碼階段。如果是一個小項目更多的錯誤會在編碼中，需求和設計的錯誤會相對減少。

這幅圖很好的展示了隨著程式規模的擴大，錯誤個數比率的變化。

3. Effect of Project Size on Productivity

代碼的產出率和代碼長度也有關係，不過可惜是成反比的。

這個資料是從《代碼大全》中截取的。在一個小程式中，通常2千行或者更小，對代碼的產出影響最大的是程式員自己的水平。但是當程式變大的時候，團隊對程式的影響更大。現在的時代不會再有求伯君那樣的英雄了，只有一個團隊的成功才可能取得成功。

4. 感受

對於同樣一件事情：寫程式。因為程式的變大，讓寫程式這件事情發生了巨大變化。就好像資料庫一樣，很少的資料可以用記事本，excel等來完成，如果是企業級的應用，那麼就要用到專業的資料庫。

我想就因為這種質的變化產生了軟體工程，產生了一套方法論來完成這項任務。當我們在做不同的項目時，根據不同的需求和項目大小挑選合適的方法論。使用敏捷，還是瀑布等。

到現在我都沒有正式的參加過項目，代碼沒有寫過2k行以上的程式。不足之處大家請指出。