這幾個月來，大部分業餘時間，都花在閱讀軟體工程和編譯原理方面的書籍上了。軟體工程方面的書，包括軟體需求、風險管理、敏捷建模，系統設計，軟體專案管理，還有一些類似於的沉思錄書籍等。在這些書中，都只是講了如何讓專案健康發展，最後成功的提交乙個產品。儘管它們都是從不同的角度，用不同的方法去完成同樣的事。但它們幾乎都支援這樣的觀點：計畫+修正計畫（不但設計是迭代的，計畫也是迭代的）。用其中乙個作者的話說，傷害你的，不是那些你沒有考慮完整的，而是你根本沒去考慮的事情。
然而，幾乎沒有一本書裡，講到關於消防隊的事，唉，真是奇怪，老外聲稱有超過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
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，想一想，它為什麼會出現，為什麼才出現，修改它後會有什麼後果。把重要的記錄下來，可能對自己和別人都有所啟發，以減少犯同樣錯誤的機會。
Extjs keyup事件bug修正
用extjs做專案大部分都會用到乙個元件combobox去實現聯想框的功能，如果實現這個功能肯定是要用到事件機制的keyup extjs為我們提供的keyup的事件，但是前提是要開啟enablekeyevents true，開啟鍵盤事件 非常奇怪的現象出現了，在監聽其中測試事件，keyup始終就是沒...
bug是如何被修正的
copy了rumination on c 中的一段控制代碼類生成樹形表示式的程式，第一次匆匆的修正執行後隔了一段時間在第二次重新修正時仍然困難重重，這才了解以前沒有真確的掌握除錯的一些技巧，做個學習總結。源 部分如下 driver.cpp 驅動函式 expr.h 標頭檔案，包含有兩個類？控制代碼類e...
Tomcat修正JDK原生執行緒池bug的實現原理
為提高處理能力和併發度，web容器一般會把處理請求的任務放到執行緒池，而jdk的原生執行緒池先天適合cpu密集型任務，於是tomcat改造之。其實threadpoolexecutor的引數主要有如下關鍵點 限制執行緒個數 限制佇列長度 而tomcat對這倆資源都需要限制，否則高併發下cpu 記憶體都...