這幾個月來，大部分業餘時間，都花在閱讀軟體工程和編譯原理方面的書籍上了。軟體工程方面的書，包括軟體需求、風險管理、敏捷建模，系統設計，軟體專案管理，還有一些類似於的沉思錄書籍等。
在這些書中，都只是講了如何讓專案健康發展，最後成功的提交乙個產品。儘管它們都是從不同的角度，用不同的方法去完成同樣的事。但它們幾乎都支援這樣的觀點：計畫
+修正計畫（不但設計是迭代的，計畫也是迭代的）。用其中乙個作者的話說，傷害你的，不是那些你沒有考慮完整的，而是你根本沒去考慮的事情。
然而，幾乎沒有一本書裡，講到關於消防隊的事，唉，真是奇怪，老外聲稱有超過
50%的專案是失敗的，那麼在他們的專案中，失火也是常事，為什麼就不談談救火的招數呢？難道他們也相信，不叫出魔鬼的名字，魔鬼就不會找上門來嗎？
唯一的解釋就是，救火太難了，可能老外的救火能力遠不如我們，他們乾脆就不談了。我在上乙個專案中犧牲慘重，巨大的壓力之下，和女友分手，精神上和身體上都受到極大的傷害，當然，我不是那個專案唯一的犧牲品，很多同事，他們很優秀，也一樣的無助。之後，我一直在想，既然有
50%的專案會失火，那麼救火能力和計畫能力至少是等同重要了。我苦苦的思索，回憶上次的經歷，查詢相關資料，然而收穫甚微。
救火的銀彈也許永遠不會出現，我把自己一些經驗寫出來，或許對大家有點幫助，如果能達到拋磚引玉的效果那是更好了： 1.
在fix bug
過程中，持續進行重構。在設計時沒有做好，重做是不太可能的了，但絕望也是沒有意義的，我們只能想法去改進它。利用前人一些經驗，持續進行重構，每
fix乙個
bug，我們讓**更好一點，而不是更壞一點，
fix了乙個
bug，**中就少了乙個
bug，而不是引更多的
bug。在實際上，重構最大的困難是沒有完整的自動測試程式和測試用例，這使得我們根本不敢去改動**，或者為了讓改動最小，採取一些折中的方法，這都使得**不斷的變臭。在這種情況下，建議是建立自動測試，然後不斷完善測試用例，我覺得建立自動測試任何時候都不晚。如果建立自動測試確實比較困難，那就列出所有的測試用例，然後手工測試。這時候，工程師的工作就是：重構à測試à
fix bug
à測試。有人說，我沒有時間去重構，沒有時間去測試。呵，這會使我想到，乙個人圍繞著乙個小圓圈拼命的奔跑，累得半死的時候，發現在原地，他還在說，我沒有時間去看清方向。 2.
關注常用功能。在專案的最後階段，千萬不要被
qa牽著走，他們發現乙個
bug，我們就
fix它。
fix乙個
bug當然好，但是
fix bug
不是免費的，要不但要成本，還有潛在的風險。編譯的優化原理是基於：
20%的**花了
80%的時間。如果這個原理成立，可以推出：
80%的使用者實際上只使用
20%的功能。
qa並不是終端使用者，
qa和終端使用者的不同在於：
qa盡力去發現不常見的問題，而終端使用者經常使用最常用的功能。這時候我們可以把自己想成終端使用者，列出最常用的測試用例，如果不在這些測試用例中的情況，即使
bug的現象很嚴重，我們也要考慮一下再決定是否修改它。 3.
確定哪些
bug不改同樣重要。這一點與
2有一定的重複，為了強調有必要單獨提出來。在軟體需求分析時，分析師們都認為，要確定什麼不在系統內和什麼在系統內一樣重要。程式設計師對於
bug態度，有時往往走兩個極端：一種是老子就不改。一種
qa怎麼說我就怎麼改。前者往往被看著工作態度不端正。而後者呢，卻被視為好孩子。其實，在專案的最後階段，後者未必正確，正如前面所說，
fix bug
不是免費的。這時候建立乙個仲裁委員會有必要的，確定哪些
bug不改是他們的職責之一。 4.
bug分類，明確責任。以前接手別人乙個模組，處於
pending
狀態的bug
已經有110
多個了。要把每乙個
bug都看一遍就要花幾個小時，不看吧，每次改乙個
bug時，總有只見樹木不見森林的感覺。最初，我很努力的去修改
bug，進展還是甚微。後來我花了幾天時間，仔細分析了所有
bug，把它們歸納幾類：其它模組引起的
bug;
和其它模組的介面引起的
bug;
超出需求之外的
bug;
完全是本模組內部的
bug。然後把其它模組引起的
bug提交給相關人員，和相關人員確認因介面不統一引起的
bug，把超出需求之外的
bug提交給需求控制委員會，最後剩下本模組的
bug又根據引起
bug的原因分為幾類。這樣，這些
bug很快被
fix了。 5.
工程師應該積極尋求幫助。有什麼自己解決不了問題，應該向知道的人請教，或者向上司尋求幫助，不要出於面子或者其它原因，而花費大量的時間。在專案的最後階段，每一分鐘都很寶貴，不要重新發明輪子，對於有共性的難題也應該由專人解決。 6.
bug，你的
bug少，並不能說明你是個好專案經理，在專案失敗時，你個人的
bug少，並不能真正減輕你的罪惡感。據說軟體團隊遵循水桶原則，最低的那塊木板才是決定裝多少水要素，而不是最高的那塊。專案經理應該隨時關注哪塊是最低的，然後把它補起來，自己成為最高的那塊是沒有意義的。 7.
person review
以提高士氣。呵，不知道有沒有
person review
這個術語，反正我覺得挺好的，在專案的最後階段，士氣是非常寶貴的東西，可以說得士氣者得天下。在前乙個公司，每週一，老闆會把每個工程師叫到他的辦公室，一起聊會兒，聊天內容不限，多半是問問你這邊工作上存在什麼問題，有什麼看法，非常坦白的談一會兒，最後會得到他的鼓勵和讚揚，自己感覺這對提高士氣很有幫助的，當然老闆最好是個好的煽動者。 8.
bug review
。建立乙個
bug review
小組，他們的主要責任是：
發現一些具有共性的
bug，確認哪些
bug需要
fix，哪個
bug不用
fix。有共性的
bug，讓專人解決或者督促。不管乙個
bug是要
fix還是不用
fix，都要註明足夠的理由。 9.
加強qa和rd
之間的合作。呵，根據遺傳學和適者生存原理可以知道，在最後階段，
bug的生命力極強，往往花費很長時間才能重現。加上自然語言本身具有的二義性和個人看問題的側重點不同，
qa可能忽略了
rd讓認為很重要的重現步驟，qa的
bug描述在
rd眼中也可能迥然不同。在這個階段，直接到現場和
qa交流一下，可能會節省很多時間。同時也要尊重
qa的勞動成果，這樣他們才會更積極的配合。
10.
經驗積累。每遇到乙個
bug，想一想，它為什麼會出現，為什麼才出現，修改它後會有什麼後果。把重要的記錄下來，可能對自己和別人都有所啟發，以減少犯同樣錯誤的機會。
救火沉思錄 關於專案最後階段的思考
這幾個月來，大部分業餘時間，都花在閱讀軟體工程和編譯原理方面的書籍上了。軟體工程方面的書，包括軟體需求 風險管理 敏捷建模，系統設計，軟體專案管理，還有一些類似於的沉思錄書籍等。在這些書中，都只是講了如何讓專案健康發展，最後成功的提交乙個產品。儘管它們都是從不同的角度，用不同的方法去完成同樣的事。但...
專案沉思錄 1 1
1.1 團隊缺什麼 團隊結構 什麼樣的團隊才能算是優秀的團隊？關於這個問題，真是仁者見仁。但乙個為人認知的基本規則是，十個個最優秀的員工，並不能組成乙個優秀的團隊。那麼乙個優秀團隊裡面究竟應該具備什麼樣的性質呢？首先，團隊的人數應當受到限制。作為基層管理者，需要至少做到一定程度上的微觀管理。然而微觀...
C Web專案開發第一階段沉思錄
好不容易熬過了第乙個月，系統終於從什麼都沒有，到現在業務上基本資料部分結束，開發框架已經搭好，開發成熟度上公升乙個空間，心裡面還是挺開心的。不過回憶這個階段的開發還是有頗多感慨。現在利用 blog 作一紀錄全當笑笑 這個系統立項的非常倉促，而且是乙個大專案，存在著明顯的技術難點，集中於資料量方面，實...