Posted on 2008-01-02 02:43
Fox 閱讀(786)
評論(6) 編輯 收藏 引用 所屬分類:
G游戲編程
Author: Fox
元旦放假3天，本來想把前面寫的一個存在線程安全隱患的模塊推倒重來的，可是改著改著就覺得不對勁了。
既然是返工，就想盡量把現在的理解完全加進去，讓后面的人看了不要罵?？墒窍氚褞浊械拇a改得面目全非并且更加安全準確也并不是一件容易的事，雖然對于功能和邏輯的認識比以前要清晰的多。
拿到一個新的模塊，上面一般會給個大致的deadline。除非你對這個模塊和整個項目的依賴關系（接口、邏輯、功能）有很好的把握，否則，你根本不知道到底有多少東西是已經實現的，有多少東西是可以復用的，有多少東西是需要修改的，有多少東西是要重寫的，有多少東西是要新加的，僅僅根據需求預估的進度是不可能恰到好處的。而脫離了整個項目實現的模塊是非?？赡艹鰡栴}的，尤其是在使用多線程的項目中。
當我的這個模塊完成并上馬之后，我沾沾自喜的跟上面說，應該是不會有問題了，上面跟我說了一句：如果不出問題就是奇跡了，我當時頗不以為然。在后面一兩周之內真的就是沒有什么問題，我真想告訴他是我創造了奇跡。
“奇跡”在2007年的最后一周破滅了。在我從西嶺雪山回來的那天，為了增加新功能把代碼修改了一些，結果第二天更新之后，服務器就老是有問題，找了一下午，才發現在修改代碼的時候居然忘記對一個pointer做NULL判定！我心想，這種錯誤居然都出來了！死了算了！而且這個問題出在非主線程中。然后就和同事在考慮，這個東西如果線程同步出現問題，你就是每次使用前都做NULL判定也沒用，所以就決定把這個模塊重寫了。
在這兒我就不想就線程安全問題多說了，以后想好了再專門去寫點多線程的東西吧，今天只是想說點瑣碎的東西。
因為是放假，心思未必就全部放在上面了，代碼沒改多少，倒是玩了很長時間的游戲。后來想想，也不全是時間問題，幾千行的代碼改來改去，難保不出現更多的問題。必須把它當作一個新的模塊去寫，先要把邏輯結構完全理出來，能多細化就多細化，最好能夠精確到變量的使用，而且把文檔做細，這樣就可以在寫文檔的過程中把問題盡可能想全想清楚。改代碼先改文檔，這幾乎是所有學過軟件工程并寫過項目的同學都能認識并理解的常識，可是在實際工作中，上有任務催趕，下有閑心雜念，很難把文檔和注釋寫好。而做不到這一點的話，你就不敢保證你的模塊不出差錯。
所以，對于一個一般的需求，如果deadline是2個月的話。讀需求、評估依賴關系、量進度要花掉1周，畫邏輯結構、寫文檔要花掉3周，相當于前面一半的時間沒有動手寫代碼，然后寫代碼大概只用1周，甚至更少，其他時間就留給測試和修改文檔、代碼了。從軟件工程的角度，這樣的分配是合理的，而且是應該的，但到了實際項目里面，又做不到！看來，不管是manager，還是coder，都不能急，軟件工程不能白學了。
我發現，我的軟件工程就是白學了，以后得改改。
/*****************************************************************************
?不想回頭去動以前的代碼，每次看以前寫過的東西，都有一種想把它徹底刪除的沖動。
?把需求看好、文檔寫好、時間安排好，這才是硬道理……
?畢竟是新年，還是祝大家：新年快樂！
?重要的是，新的一年，別荒廢了……
*****************************************************************************/