關於我們的思考——“專案開發”及讀《人月神話》有感 (轉)

關於我們的思考——“專案開發”及讀《人月神話》有感 (轉)[@more@]關於我們的思考
——“專案開發”及讀《人月神話》有感:NAMESPACE PREFIX = O />

　　專案開發終於結束了，按專案流程，我應該寫一份《專案開發總結報告》。拿來“GB856T——88”標準文件，有指導我該寫些什麼，但是怎麼能讓這些框架協束縛了自由的思想呢？於是決定換一種形式。

　　專案開發接近尾聲的時候，也是最關鍵的時候，有人送來一本《人月神話》。我很幸運能在這個時候讀這本書，因為會有很多思考，關於專案，關於團隊，關於我們……

　　經過兩個多月的艱苦熬戰，我驚奇的發現我們的竟然可以良好的執行，而且完成了需求裡所有的功能；雖然並沒有完全按原計劃完成，但仍可以說：“我們創造了一個神話！”

　　這段日子每個人都很辛苦。我們日落而作，日出而息；吃泡麵，炒雞蛋；24小時在旁邊……這不正是我們曾經夢想的生活麼？辛苦的日子總是令人回味的，讓我們一起回味這段永生難忘的日子吧。

　　我們把這塊骨頭啃下來了，就是我們的成功；我們為最終的成功邁出了第一步。當然，我們還有很多不足的地方。成功還是失敗，很難下一個具體的定義。不以成敗論英雄，不拿勝負談輸贏。重要的是我們能從這次專案開發中學到什麼。

　　如果要指出專案的成功之處，“需求分析”算一個，詳盡明確的需求分析為設計和開發明確了方向；失敗的地方主要應該在協作開發上，否則我們可能會更早的完成任務。
雖然我們這裡有些人在一起合作過，但對於整個團隊來說我們是第一次合作，算做一次嘗試，我們應該從中吸取教訓，找到一條適合我們發展的道路。下面把專案中遇到的，我想到的，結合《人月神話》中談到的一一列出來與大家一起討論。

　　毛主席說：“不打無準備之戰。”

　　我們的這一戰作了充分的準備。接到客戶的“需求說明書”後便著手分析哪些是可行的，哪些是不可行的。經過多次的協商，終於得到了一份雙方都認可的《需求分析說明書》。與此同時對專案中必須要完成的技術進行研究，搶得了時間。

　　在《人月神化》中有一段被擷取，稱為“員的苦與樂”，在網上廣為流傳。Brooks大師用簡短的篇幅，描繪出整個程式世界的苦與樂。在這次專案開發中，有兩個苦惱體現的比較明顯。

　　一是追求完美。“因為是以這樣的方式來變戲法的：如果口語中的一個字元、一個停頓，沒有與正確的形式一致，魔術就不會出現（現實中，很少的人類活動要求完美，所以人類對它本來就不習慣）。實際上，我認為，學習最困難的部分，是將做事的方式向追求完美的方向調整。”

　　看來我再次做出了正確的選擇，我是個追求完美的人，而且我也一直認為程式設計師就應該有這種本性。在寫程式的時候，甚至對一個變數名我都要反覆斟酌，直到選擇一個我認為可以表達這個變數的意義的。我並不認為這是在浪費時間：一是有助於對程式的理解和維護，好的程式本身就是註釋；二是減少錯誤發生的可能。這次開發因為時間短，我嘗試採用設計->編碼->編譯的方式來寫程式，經常把一個幾千行程式碼的模組寫完之後才開始。效果不錯，因為對設計考慮的比較充分，基本上都是一些拼寫上的錯誤。不過有一個錯誤卻另我苦惱了很久。因為一個結構的成員變數名與引數的變數名一樣，而這個引數又在多處使用，寫的時候，也可能是複製程式碼的時候，很容易把結構名給忘記或多加了一個結構名，而這時又不會有語法上的錯誤。吸取了這次教訓，我把整個程式檢查了一便，並做了一些修改。這段程式我參考的一位大師的原型，令我欣慰的是，他的下一個版本和我的程式做出了同樣的一些修改。

　　另一個“苦惱來自設定目標、供給資源、提供資訊。程式設計人員很少能控制工作環境和工作目標。”後面章節又提到“結構師獲得了所有的創造發明的快樂，剝奪了實現人員的創造力”。“實現同樣是一項高階的創造性活動。具體實現中創造和發明的機會，產東會因為指定了外部技術說明而大為減少，相反創造性活動會因為規範化而得到增強，整個產品也一樣。”程式設計師要學會放棄一部分樂趣，整個專案也一樣，這是我讀《人月神化》感觸最深的一點。

　　設計的時候，本打算用一種簡單的認證方式實現，因為這不是重點。Y提出用證書加自己寫的Socket類實現認證的通訊過程。這是一個很好的創意，但VC寫出類無法在裡使用，BCB也不行。封裝，回撥……大家都搞暈了，只剩下兩個字：“放棄”。

　　由於時間比較緊，產品的功能上也放棄了一些認為是很有創意的，但需求中沒有提到的部分。後面的開發中也有類似的問題，每個人都按自己的喜好和提供介面，可以說是八仙過海，各顯神通。問題主要在於交流。

1．一切彷彿都很正常

　　由於做了充分的準備，每個人心裡的那股勁兒也已經憋了很久了，一切彷彿都是按照“專案計劃”中的步驟在緊張有序的進行著。可是沒過多久，問題一個接一個的暴露出來了。先是Delphi沒法呼叫Visual C++寫的DLL匯出類，然後一些人對自己的工作不明確，接著模組的介面沒有按照事先約定的實現，之後呼叫方又不知道在什麼情況下呼叫哪一個介面……

　　雖然問題並不是非常嚴重，而且也都得到了解決，但事實的確如此。有客觀方面的原因，比如是在網路上協同開發，但網路的資源是否被有效的利用了呢？有技術方面的原因，比如在程式語言上的缺陷，不能隨心所選擇一種合適的語言，只能選擇一個合適的模組。你可以說：“其實其他公司也差不多如此。”但怎麼能把別人的缺點當作自我滿足的標尺呢？這都不是主要原因，在設計的時候也都考慮到了，如搭建企業內部協作平臺，增加中心呼叫控制模組。最重要的是交流的不夠，或方式不合理。人與人之間的交流是影響整個專案開發的關鍵，這是我在專案開發中體會最深的一點。

2．交流方式

　　人月之所以不能成為神化，正是因為增加人手的同時也增加了人與人之間的交流。

　　我們在專案一開始就透過qq群組進行溝通，後來又搭建了企業內部協作平臺，而且還有不定期的會議。與大師所說的三種交流途徑——非正式途徑、會議、工作手冊——不謀而合。但是，的效果卻不很理想。是大師說的不對？不是。是我們沒有利用好這幾種途徑。我們很好的利用會議，解決很多細小方面的誤解；過多的使用QQ群組，一是在登陸QQ的時候訊息太多而沒看仔細，二是這種方式針對小的誤解是很有效的，但對於一些系統的全面的理解必須透過文件；但是很少使用協作平臺，沒有仔細的閱讀文件的習慣，也沒有寫出一個完整文件的習慣。

　　即使在QQ群組的交流中，也沒有把問題表述清楚。經常看到：“某某：你那裡有問題？”哪裡？什麼問題？QQ都是透過UDP傳輸的，這裡就不需要傳送ACK了，對方不線上可以透過中轉，到論壇發一個貼子或直接傳送。接著有人回答：“不可能啊？”什麼事情都可能發生的，只要能滿足條件。域名都會不易而飛，還有什麼是不可能的呢？出了問題首先從自身找原因，發現一切的可能。

3．如何閱讀別人的文件

　　首先必須擺正姿態，把閱讀文件當成一種習慣，不要抱有不懂再問的心理，寫文件的目的之一就是減少交流的次數，如果你問了一個文件中描述的很清楚的問題，你得到的回答將是：“去看文件。”

　　其次你要知道這是一篇關於什麼的文件，對於整個專案手冊來說它處於一個什麼樣的位置，可以根據你的需要讀取相關的部分。

　　再次，當讀到不明白的地方，從文件作者的角度出發，想一下為什麼是這樣。你要尊重他人的勞動成果，也許你覺得很平常的一句話，卻是作者用86400ms*1K腦細胞換來的（一個腦細胞對應一個方法）。

　　最後，如果還是想不通，可以查閱相關的文件，或到網上去搜尋相關資料。實在是想不通，再把你想不通地方整理好，最好也是用文件的形式，也可以直接告訴作者，等待回覆。也許你是對的，但在得到正式確定之前必須按照原文件中所說的去做，以保證整個系統的完整性。

4．如何寫文件

　　由於專案開發週期十分短，我只定義了各個模組的功能，介面標準，和介面說明的標準。這就要求每個成員把自己模組介面的詳細說明提供給呼叫者。但很少有人按照給出的標準書寫介面和文件，而且文件說明也不夠詳細。

　　為什麼要寫文件？一是減少交流的次數，提高；二是得到清楚、確定的策略，介面說明應該在介面實現之前就已經寫好；三是為整個專案的規劃提供依據。

　　文件並不一定要按照標準來寫，但標準有助於交流。一個好的文件應該讓一個沒的接觸過此專案的人一看就明白你想要做什麼，怎麼做。有些時候閱讀的人只讀他感興趣的部分，因此儘量在每一個部分就把事情描述清楚，如果是引用或繼承要說明出處。不要怕麻煩，現在的一點點工作會為以後帶來很多方便，否則會適得其反。

　　期待已久的整合工作開始了，不過要比以前更加忙碌。大家開始互相指責，一個說：“你的文件沒說清楚”，另一個說：“聽不懂你在說什麼”；一個說：“我這裡沒問題”，另一個說：“我這裡程式碼很簡單”……

　　為什麼會這樣呢？除了上面談到的幾點之外，還有一點就是對測試的理解。客觀條件的限制使我們必須自己動手測試。模組開發人員負責單元測試和整合測試；其他人員進行系統測試和驗收測試。但在測試過程中對一個問題常常需要幾番周折，甚至用重灌系統來證明自己的無辜。一切都是有原因的，現在的麻煩是因為開始準備不足。可以從下面幾個問題來證明這一點：

　　你是否為模組做了詳細的設計？包括提供的介面，引用的模組、實現的流程、使用的等。一個設計良好的模組應該很容易定位到出錯的地方。

　　你的模組是否有可測試性？當錯誤發生時，應該有錯誤型別的說明或代號，或者記錄出錯的過程。這裡包括對工具的使用，除錯的技巧等。沒有測試不了的模組，只是方法和時間上的問題。

　　你是否為你的模組編寫了測試工具？DLL呼叫，訊息處理，臨界條件等不好手工測試的部分應該寫一份測試工具，也許這個會給你帶來一些創造的樂趣。

　　你是否對測試做了計劃？不是每次都那麼好運，一下就能測試出問題。而且一個問題的發現可能會聯想到另一個問題。

　　你是否對測試出的問題做了詳細的記錄？只告訴開發人員：“你那裡有問題！”是沒有任何意義的，這裡又回到文件的交流上。沒有文件就很難對進行跟蹤，有些BUG要說很多次才能修正好。

　　另外還有一點就是整合的時間太晚，問題都堆在了一起。在設計這個系統的時候是想盡早的做出一個可用的系統，拿怕只有“退出”生效。這種設計也可以稱為原型法，不但有助與程式設計師對整個系統結構的理解，還可以鼓舞士氣。但由於上面提到的和一些其它沒有在這裡講到的一些問題，導致這個可用的系統一直未能謀面。

　　從上面的分析可以看到我們存在很多問題，但我們還是把專案開發完了。因為我們有一個法寶——激情，激情可以戰勝任何困難。

　　“我們來自五湖四海，各自為了心中的夢想在網路的世界裡尋找自己的座標。也許是緣分，也許是偶然，也許是心中共同的信念和夢想，讓我們走到一起；共同努力，相互幫助，默默奉獻著自己的力量，在技術的天地中貪婪地汲取養分，渴望成長，渴望強大。”“感謝上帝讓我成為了為數不多的那些開開心心地做著自己喜歡的工作的人之一”。

　　回想這三個月裡的日日夜夜，是一種驕傲與自豪。有人問我這麼辛苦是為了什麼？我也常常問自己，為誰？為錢？都不是。因為我年輕，因為我有激情，因為我從不後悔。在網上游蕩的時候，看到一段話，值得回味：

　　無情的歲月讓我們一秒秒地老去
　　慢慢地封存在發黃的照片裡……

　　在回首過去的時候……
　　在那漸漸被遺忘的歲月中
　　我們應該要為自己的人生留下感動的回憶和汗水……

　　 記得有段時間我們每天MOHAA，而且也頗有心得，還小有名氣。於是有人問：“為什麼這樣，你的激情呢？”我回答：“一個人，不管做什麼事都要有一個目標。目標就是動力，失去了目標也就沒有了激情……”在遊戲人生的日子裡，的確沒有學到多少東西，但是我們不後悔。至少我們走過來了，我們的人還在；而且也再次證明了我們的實力，“我們是冠軍”。

　　曾經幻想中的帝國大廈如今已變成一堆垃圾，經歷了諸多的風風雨雨，我們又回到起點。我們不在迷茫，我們不在徘徊。“投入新的戰鬥吧，為了不改變一切的理想，為了改變不理想的一切”，再創輝煌。希望我們的故事能夠成為更加年輕的，像我們一樣擁有激情的人們的榜樣。

　　本文只是我在專案開發和讀了《人月神化》之後的一點感想，沒有誰的對與錯，對於本文一些觀點的正確於否歡迎與您一起討論。本文只是按照專案流程，挑主要的部分敘述了在開發中體會到的一些感想。這次開發讓我學到太多太多的東西，將使我終身受益。還有很多的想法，如團隊建設、整體設計、開發……希望以後能與大家多多交流，相互學習。

　　《人月神化》這本書推薦大家都去讀一下。它不是良藥，不能為你解決實際工作中的問題，但它可以給你帶來很多思考，讓你變得更加成熟。工程是為開發軟體服務的，標準不是目的，只是手段。《人月神化》沒講標準，但它為怎樣做好一個專案提供了一些參考。它會增強你的自信心，當有人反駁你的觀點的時候，你可以告訴他：“Brooks大師如是說^-^”。