這幾個月來，大部分業(yè)余時間，都花在閱讀軟件工程和編譯原理方面的書籍上了。軟件工程方面的書，包括軟件需求、風(fēng)險管理、
敏捷建模，系統(tǒng)設(shè)計，軟件
項目管理，還有一些類似于的沉思錄書籍等。
在這些書中，都只是講了如何讓項目健康發(fā)展，最后成功的提交一個產(chǎn)品。盡管它們都是從不同的角度，用不同的方法去完成同樣的事。但它們幾乎都支持這樣的觀點：計劃+修正計劃（不但設(shè)計是迭代的，計劃也是迭代的）。用其中一個作者的話說，傷害你的，不是那些你沒有考慮完整的，而是你根本沒去考慮的事情。
然而，幾乎沒有一本書里，講到關(guān)于消防隊的事，唉，真是奇怪，老外聲稱有超過50%的項目是失敗的，那么在他們的項目中，失火也是常事，為什么就不談?wù)劸然鸬恼袛?shù)呢？難道他們也相信，不叫出魔鬼的名字，魔鬼就不會找上門來嗎？
唯一的解釋就是，救火太難了，可能老外的救火能力遠不如我們，他們干脆就不談了。我在上一個項目中犧牲慘重，巨大的壓力之下，精神上和身體上都受到極大的傷害，當然，我不是那個項目唯一的犧牲品，很多同事，他們很優(yōu)秀，也一樣的無助。之后，我一直在想，既然有50%的項目會失火，那么救火能力和計劃能力至少是等同重要了。我苦苦的思索，回憶上次的經(jīng)歷，查找相關(guān)資料，然而收獲甚微。
救火的銀彈也許永遠不會出現(xiàn)，我把自己一些經(jīng)驗寫出來，或許對大家有點幫助，如果能達到拋磚引玉的效果那是更好了：
1.在FIX
BUG過程中，持續(xù)進行重構(gòu)。在設(shè)計時沒有做好，重做是不太可能的了，但絕望也是沒有意義的，我們只能想法去改進它。利用前人一些經(jīng)驗，持續(xù)進行重構(gòu)，每FIX一個BUG，我們讓代碼更好一點，而不是更壞一點，F(xiàn)IX了一個BUG，代碼中就少了一個BUG，而不是引更多的BUG。在實際上，重構(gòu)最大的困難是沒有完整的自動
測試程序和
測試用例，這使得我們根本不敢去改動代碼，或者為了讓改動最小，采取一些折中的方法，這都使得代碼不斷的變臭。在這種情況下，建議是建立自動測試，然后不斷完善測試用例，我覺得建立自動測試任何時候都不晚。如果建立自動測試確實比較困難，那就列出所有的測試用例，然后手工測試。這時候，工程師的
工作就是：重構(gòu)à測試àFIX BUGà測試。有人說，我沒有時間去重構(gòu)，沒有時間去測試。呵，這會使我想到，一個人圍繞著一個小圓圈拼命的奔跑，累得半死的時候，發(fā)現(xiàn)在原地，他還在說，我沒有時間去看清方向。
2.關(guān)注常用功能。在項目的最后階段，千萬不要被QA牽著走，他們發(fā)現(xiàn)一個BUG，我們就FIX它。FIX一個BUG當然好，但是FIX BUG不是免費的，要不但要成本，還有潛在的風(fēng)險。編譯的優(yōu)化原理是基于：20%的代碼花了80%的時間。如果這個原理成立，可以推出：80%的用戶實際上只使用20%的功能。QA并不是最終用戶，QA和最終用戶的不同在于：QA盡力去發(fā)現(xiàn)不常見的問題，而最終用戶經(jīng)常使用最常用的功能。這時候我們可以把自己想成最終用戶，列出最常用的測試用例，如果不在這些測試用例中的情況，即使BUG的現(xiàn)象很嚴重，我們也要考慮一下再決定是否修改它。
3.確定哪些BUG不改同樣重要。這一點與2有一定的重復(fù)，為了強調(diào)有必要單獨提出來。在軟件需求分析時，分析師們都認為，要確定什么不在系統(tǒng)內(nèi)和什么在系統(tǒng)內(nèi)一樣重要。程序員對于BUG態(tài)度，有時往往走兩個極端：一種是老子就不改。一種QA怎么說我就怎么改。前者往往被看著工作態(tài)度不端正。而后者呢，卻被視為好孩子。其實，在項目的最后階段，后者未必正確，正如前面所說，F(xiàn)IX BUG不是免費的。這時候建立一個仲裁委員會有必要的，確定哪些BUG不改是他們的職責之一。
4.BUG分類，明確責任。以前接手別人一個模塊，處于Pending狀態(tài)的BUG已經(jīng)有110多個了。要把每一個BUG都看一遍就要花幾個小時，不看吧，每次改一個BUG時，總有只見樹木不見森林的感覺。最初，我很努力的去修改BUG，進展還是甚微。后來我花了幾天時間，仔細分析了所有BUG，把它們歸納幾類：其它模塊引起的BUG; 和其它模塊的接口引起的BUG; 超出需求之外的BUG; 完全是本模塊內(nèi)部的BUG。然后把其它模塊引起的BUG提交給相關(guān)人員，和相關(guān)人員確認因接口不統(tǒng)一引起的BUG，把超出需求之外的BUG提交給需求控制委員會，最后剩下本模塊的BUG又根據(jù)引起B(yǎng)UG的原因分為幾類。這樣，這些BUG很快被FIX了。
5.工程師應(yīng)該積極尋求幫助。有什么自己解決不了問題，應(yīng)該向知道的人請教，或者向上司尋求幫助，不要出于面子或者其它原因，而花費大量的時間。在項目的最后階段，每一分鐘都很寶貴，不要重新發(fā)明輪子，對于有共性的難題也應(yīng)該由專人解決。
6.項目經(jīng)理應(yīng)該把眼光放在全局上。項目經(jīng)理應(yīng)該更多的關(guān)注于全局的事務(wù)，不要學(xué)只想拿大紅花的小學(xué)生。別只顧修改自己的BUG，你的BUG少，并不能說明你是個好項目經(jīng)理，在項目失敗時，你個人的BUG少，并不能真正減輕你的罪惡感。據(jù)說軟件團隊遵循水桶原則，最低的那塊木板才是決定裝多少水要素，而不是最高的那塊。項目經(jīng)理應(yīng)該隨時關(guān)注哪塊是最低的，然后把它補起來，自己成為最高的那塊是沒有意義的。
7.Person Review以提高士氣。呵，不知道有沒有Person Review這個術(shù)語，反正我覺得挺好的，在項目的最后階段，士氣是非常寶貴的東西，可以說得士氣者得天下。在前一個公司，每周一，老板會把每個工程師叫到他的辦公室，一起聊會兒，聊天內(nèi)容不限，多半是問問你這邊工作上存在什么問題，有什么看法，非常坦白的談一會兒，最后會得到他的鼓勵和贊揚，自己感覺這對提高士氣很有幫助的，當然老板最好是個好的煽動者。
8.Bug Review。建立一個Bug Review小組，他們的主要責任是： 發(fā)現(xiàn)一些具有共性的BUG，確認哪些BUG需要FIX，哪個BUG不用FIX。有共性的BUG，讓專人解決或者督促。不管一個BUG是要FIX還是不用FIX，都要注明足夠的理由。
9.加強QA和RD之間的合作。呵，根據(jù)遺傳學(xué)和適者生存原理可以知道，在最后階段，BUG的生命力極強，往往花費很長時間才能重現(xiàn)。加上自然語言本身具有的二義性和個人看問題的側(cè)重點不同，QA可能忽略了RD讓認為很重要的重現(xiàn)步驟，QA的BUG描述在RD眼中也可能迥然不同。在這個階段，直接到現(xiàn)場和QA交流一下，可能會節(jié)省很多時間。同時也要尊重QA的勞動成果，這樣他們才會更積極的配合。
10.經(jīng)驗積累。每遇到一個BUG，想一想，它為什么會出現(xiàn)，為什么才出現(xiàn)，修改它后會有什么后果。把重要的記錄下來，可能對自己和別人都有所啟發(fā)，以減少犯同樣錯誤的機會。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters