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