很感謝「加大碼」同志在上篇隨筆的恢復，讓我想起了許多問題。
常言道，千里之堤，毀於蟻穴，軟體同樣如此。雖然軟體中的
bug本身不會像蟻穴那樣慢慢變大，但對使用者而言，它引起的錯誤
/異常等的次數卻會越積越多，最終我們會失去使用者，造成不可挽回的損失，因此，這些質量的問題，我們必須注意，並制定相應的措施、計畫、方案去預防、測試、修正
bug的出現。
至於如何做測試計畫、如何寫測試用例等之類如何預防「蟲子」、如何查詢「蟲子」的文章比比皆是，但是發現「蟲子」之後該怎麼辦呢？細想一下，這個問題並不十分簡單。
首先，對於有明顯「病症」的
bug，一旦出現，我們需要立即詳細記錄
bug的表徵，記錄的越細緻越好，對於使用者而言，這一點往往很難達到，因為使用者往往沒有這方面的意識，因而我們得到的反饋往往是「有乙個錯誤」、「執行到
**地方突然提示出錯了」等之類模糊的
bug報告。對於這一點，不管是做專案還是做產品，我們都因該在程式中建立盡可能完善的缺陷機制，這樣，我們的程式的容錯性、健壯性、可靠性等才能得到基本的保障。那麼對於
bug，我們在缺陷機制的設計中因該包含哪些內容呢？我認為至少我們應該有乙個日誌檔案，來記錄
bug的時間、原因、導致
bug的語句或方法、堆疊，甚至包含上下文資料的描述，當然，這是在不嚴重影響效能的前提下完成的。當程式設計師拿到日誌檔案之後，就能夠比較容易的再現
bug，進而改正之了。
以上談得是能夠捕捉到的
bug。那麼對於不能捕捉到的錯誤怎麼辦呢
?我想在進行
β測試之前，我們應該告訴參與測試的人員，一旦出現異常，應當細緻的描述異常之前的操作步驟、使用了哪些資料、異常提示了什麼，甚至乾脆直接把異常抓圖寫在測試報告中，上面這些，在測試用例中都應有所體現。
「蟲子」的問題
最近幾天安裝分公司開發的一套軟體，給本地公司員工作培訓。可誰知軟體裝上了，卻不能用，也不出錯，就是得不到正確的結果。通過rtx詢問了一下，被告知 不可能，怎麼可能呢？這邊一點問題也沒有，你在試一下 於是解除安裝 安裝 解除安裝 安裝 大約進行了n遍，仍是不行。於是俺乙個 過去，這次解釋和上次袋是不太...
蟲子爬進問題
1.問題大意乙個n英吋的井中有一條1英吋的蟲。蟲子u英吋 minutes,爬一分鐘必須休息一分鐘。休息期間蟲子會掉d英吋。給出需要多少秒乙個蟲爬出井。題意的理解很重要，開始時我理解為必須剛好最後一步到達井口，才算爬出井。所以對立面 n 19 u 3 d 1時間為19的例子算了半天都沒有找到乙個合理的...
再談type ahead 問題
問題 給定乙個詞典，包括一些詞和其出現的頻率。實現type ahead功能，要求使用者每鍵入乙個字元，下拉框顯示以當前輸入為字首的前10個最熱門的詞 解法1 用不帶data的trie，data僅僅是詞頻 實時查詢法，需要實時的去build hot list 框架就是triie的 startwithp...