軟件項目經(jīng)理經(jīng)常面臨及早交付產(chǎn)品的巨大壓力。時間是關鍵。你如何才能快速完成任務呢?假設你的團隊有兩名程序員，伯尼和羅布。兩人都很能干，知識面相同， 編程語言技巧也相當。你發(fā)現(xiàn)在開發(fā)過程中伯尼實現(xiàn)軟件功能的速度遠遠超過羅布。
當伯尼著力于快速完成編程時，羅布正花時間寫代碼并對其進行重構。重構就是改動代碼，完善其內部組成結構而不改變其外部功能。它改進軟件產(chǎn)品設計。重構代碼 是回過頭去完善以前倉促創(chuàng)建并測試的某項可用的功能?，F(xiàn)在需要進一步對該功能進行內部改進， 以便長期使用，也使日后增加功能更為方便。羅布對變量和方法的命名更擅長。一旦寫的程序能夠運行起來，他就把這個程序分 成幾小塊?，F(xiàn)在他要寫測試來確保該程序的每一塊都能按照他的意圖運行。當他覺得結果比較滿意時才宣稱實現(xiàn)了功能。
但是假設你并不知道上述這些細節(jié)。如果你只看他們誰先宣稱實現(xiàn)了功能，那么很明顯伯尼表現(xiàn)得更好，對嗎?
幾個星期之后，你向客戶演示這些功能。像往常一樣，顧客喜歡你已經(jīng)完 成的功能，但現(xiàn)在需要你做一些改動和完善。你讓軟件開發(fā)人員修改這些代碼。當你把新改進的功能帶回給客戶時，他們試用了羅布實現(xiàn)的功能，對他做出的 改動十分滿意。
遺憾的是他們發(fā)現(xiàn)伯尼實現(xiàn)的功能有些奇怪。當伯尼編寫好新的功能后，一些以前能使用的功能現(xiàn)在卻不能用了?？蛻舭堰@些作為缺陷標記出來，然后你讓 伯尼來修改?？蛻粲忠淮螠y試這些功能，結果后來新增的功能也不能用了。這到底是咋回事呢?
如果你有孩子，就會知道發(fā)生了什么。伯尼創(chuàng)建的是一個打地鼠式的應用程 序。打地鼠是一種游戲，孩子們拿著一個木棒敲打幾個孔中隨意彈出的地鼠，他們會很驚奇接下來是哪個地鼠彈出來，而且還樂此不疲。然而，在修改應用程序 的時候如果總有壞代碼不知從何處隨意彈出，那可不是好玩的事情。那會令人沮喪，結果也難以預料，并且它會減慢產(chǎn)品開發(fā)速度。伯尼一開始就全速沖刺，只是南轅北轍了。
盡管羅布從一開始就表現(xiàn)得較慢，但實際上他編寫的代碼更勝一籌。事實證 明，他的節(jié)奏是可持續(xù)發(fā)展的。由于最初編寫的代碼就有較好的質量，所以，他才能更快地做出可行的改動。而且他早期編寫的測試能隨時帶給他反饋信息，讓 他了解自己新寫的代碼是否與原有應用程序的其他部分兼容。
當估計某一功能的實現(xiàn)時間時，不要只考慮最初寫代碼所花費的時間，還要 加上提升、調整和改進這些代碼所需的時間。寫高質量的代碼和測試都需要花時間。從短期來看，這似乎是一種損失，然而它帶來的卻是長期收獲。