這幾個月來，大部分業余時間，都花在閱讀軟件工程和編譯原理方面的書籍上了。軟件工程方面的書，包括軟件需求、風險管理、
敏捷建模，系統設計，軟件
項目管理，還有一些類似于的沉思錄書籍等。
在這些書中，都只是講了如何讓項目健康發展，最后成功的提交一個產品。盡管它們都是從不同的角度，用不同的方法去完成同樣的事。但它們幾乎都支持這樣的觀點：計劃+修正計劃（不但設計是迭代的，計劃也是迭代的）。用其中一個作者的話說，傷害你的，不是那些你沒有考慮完整的，而是你根本沒去考慮的事情。
然而，幾乎沒有一本書里，講到關于消防隊的事，唉，真是奇怪，老外聲稱有超過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，想一想，它為什么會出現，為什么才出現，修改它后會有什么后果。把重要的記錄下來，可能對自己和別人都有所啟發，以減少犯同樣錯誤的機會。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters