Author: Fox

元旦放假3天，本來想把前面寫的一個存在線程安全隱患的模塊推倒重來的，可是改著改著就覺得不對勁了。

既然是返工，就想盡量把現(xiàn)在的理解完全加進(jìn)去，讓后面的人看了不要罵。可是想把幾千行的代碼改得面目全非并且更加安全準(zhǔn)確也并不是一件容易的事，雖然對于功能和邏輯的認(rèn)識比以前要清晰的多。

拿到一個新的模塊，上面一般會給個大致的deadline。除非你對這個模塊和整個項目的依賴關(guān)系（接口、邏輯、功能）有很好的把握，否則，你根本不知道到底有多少東西是已經(jīng)實現(xiàn)的，有多少東西是可以復(fù)用的，有多少東西是需要修改的，有多少東西是要重寫的，有多少東西是要新加的，僅僅根據(jù)需求預(yù)估的進(jìn)度是不可能恰到好處的。而脫離了整個項目實現(xiàn)的模塊是非常可能出問題的，尤其是在使用多線程的項目中。

當(dāng)我的這個模塊完成并上馬之后，我沾沾自喜的跟上面說，應(yīng)該是不會有問題了，上面跟我說了一句：如果不出問題就是奇跡了，我當(dāng)時頗不以為然。在后面一兩周之內(nèi)真的就是沒有什么問題，我真想告訴他是我創(chuàng)造了奇跡。

“奇跡”在2007年的最后一周破滅了。在我從西嶺雪山回來的那天，為了增加新功能把代碼修改了一些，結(jié)果第二天更新之后，服務(wù)器就老是有問題，找了一下午，才發(fā)現(xiàn)在修改代碼的時候居然忘記對一個pointer做NULL判定！我心想，這種錯誤居然都出來了！死了算了！而且這個問題出在非主線程中。然后就和同事在考慮，這個東西如果線程同步出現(xiàn)問題，你就是每次使用前都做NULL判定也沒用，所以就決定把這個模塊重寫了。

在這兒我就不想就線程安全問題多說了，以后想好了再專門去寫點多線程的東西吧，今天只是想說點瑣碎的東西。

因為是放假，心思未必就全部放在上面了，代碼沒改多少，倒是玩了很長時間的游戲。后來想想，也不全是時間問題，幾千行的代碼改來改去，難保不出現(xiàn)更多的問題。必須把它當(dāng)作一個新的模塊去寫，先要把邏輯結(jié)構(gòu)完全理出來，能多細(xì)化就多細(xì)化，最好能夠精確到變量的使用，而且把文檔做細(xì)，這樣就可以在寫文檔的過程中把問題盡可能想全想清楚。改代碼先改文檔，這幾乎是所有學(xué)過軟件工程并寫過項目的同學(xué)都能認(rèn)識并理解的常識，可是在實際工作中，上有任務(wù)催趕，下有閑心雜念，很難把文檔和注釋寫好。而做不到這一點的話，你就不敢保證你的模塊不出差錯。

所以，對于一個一般的需求，如果deadline是2個月的話。讀需求、評估依賴關(guān)系、量進(jìn)度要花掉1周，畫邏輯結(jié)構(gòu)、寫文檔要花掉3周，相當(dāng)于前面一半的時間沒有動手寫代碼，然后寫代碼大概只用1周，甚至更少，其他時間就留給測試和修改文檔、代碼了。從軟件工程的角度，這樣的分配是合理的，而且是應(yīng)該的，但到了實際項目里面，又做不到！看來，不管是manager，還是coder，都不能急，軟件工程不能白學(xué)了。

我發(fā)現(xiàn)，我的軟件工程就是白學(xué)了，以后得改改。

/*****************************************************************************
?不想回頭去動以前的代碼，每次看以前寫過的東西，都有一種想把它徹底刪除的沖動。
?把需求看好、文檔寫好、時間安排好，這才是硬道理……

?畢竟是新年，還是祝大家：新年快樂！
?重要的是，新的一年，別荒廢了……
*****************************************************************************/