人月神話劄記：整體部分

前言：關于測試，的确太過重要，尤其是把新做成的功能加入到原來已經正常運作的系統中，先随我一起進入到Brooks的世界中看一看。

剔除bug的設計

産品的概念完整性在使他易于使用的同時，也使開發更容易進行，而且bug不容易産生。

在我所經曆的項目中，我隻參與了其中一部分，或者負責了較大部分，在與别人負責的代碼打交道的過程中，如果我稍不留神，就會滋生很多bug在其中。除去我對整體業務掌握的不夠全面以外，大部分的原因是因為我們彼此之間的差異太大。

自上而下的設計。我所經曆的項目的确都是自上而下的設計，都是先搭建整體模型，再不斷細化。但是很多時候，做的不好，是因為子產品之間的耦合度太高，導緻不夠靈活。

構件單元測試

Brooks提到了本機測試和互動性測試，也許我了解的不夠深刻，我認為的本機測試就是我們在個人的電腦中配置軟體運作所屬環境，進而對代碼進行整體性測試，等本地測試通過後，我們在部署到伺服器當中。這個時候，因為代碼以及伺服器的一些固性原因，我們需要手動去改變服務的某些狀态，我們在這個時候，就會對代碼多加上一些人為操作手段，進而控制程式進行互動性測試。

系統內建調試

系統內建調試的概念，對于每個學習程式設計的開發人員來說，并不陌生，甚至我們經常挂在嘴邊，我們都傾向于隻做內建測試，而不太重視做內建測試之前先要做構件測試，也就是說保證內建到整體系統的每一部分都順利通過。

小型團隊沒有代碼review，也缺乏同級的代碼評審，更缺少自我的代碼測試，我們經常性的隻要完成了代碼，就認為可以放到伺服器上供使用者使用了，然而這個時候，我們經常吃很大虧，一些不負責任的程式員經常為我們埋雷。

我個人最近也深有體會，寫完代碼之後，我自己會反複檢查幾次， 然後對重要的部分進行單元測試，然而，等放到伺服器上運作時，就出現了不應該出現的錯誤。

在內建測試之前，一定保證每個部分已經被測試通過了，至少確定你在內建測試時候發現問題時，能盡快的定位到為題發生的所在之地。

搭建充分的測試平台。這個非常的必要，我們項目部有兩個小組，有一個小組雖然有測試伺服器，但是很多時候，代碼在正式環境上線後，依然出現很低級的錯誤，這其中一個很主要的原因就是沒有保持好兩者之間的同步。

僞構件、僞檔案。我想很多時候，我們都經曆過，并且取得了很多的成效。當我們無法真實産生所需的xml時，我們會手動構造一個；當我們的某個功能尚未完善時，我們會假裝它已經完成。這些在測試的時候，都會給我們很大的幫助，讓我們的整體測試順利的進行下去，而不是阻塞，當然這是因為僞構件和僞檔案足以讓我們發現應該找到的bug。

控制變更。由于我們的小組成員人數隻有我和另外一個人，再加上兩人可以随時語言溝通，是以我們沒有進行變更控制。但是如果項目人數有5人以上時，遵守Brooks的觀點是應該的：

一個是供構件測試使用的最終鎖定版本；一個是測試版本的拷貝，用來進行缺陷的修複；以及一個開發庫，供其他人員進行各自的程式開發。雖然我知道svn有分支，但是我還是不太确定如何在SVN上執行這些操作。

一次添加一個構件。在很重要，交易平台的項目目前主要由我整體把控，是以我經常性的優化代碼結構，但是有的時候會事與願違，優化後的代碼不足夠保證程式正常運作，這很大一個原因就是我改動的太多，是以出現問題後，如果我反複很多很多次後，依然無法找出問題所在的原因時，我就會還原版本，再改動。再次改動的時候，我就會縮小範圍，保證每一次修改都不會影響到原有的程式。這很重要。