主要目標是讓自己維護模組時省時省事。
記得很多年前，那會自己感覺自己寫的**還行，年輕那會寫程式感覺很少有bug，也不怎麼判斷異常分支，**中很多假定了正確分支。
有一次做乙個日本專案，跟日本人溝通，很簡單乙個功能，被日方反反覆覆打回，修改了七八次。初看有點小題大做（有的分支估計等到程式被廢棄都不會執行進去），仔細分析的話，還是有道理的。
放到大型軟體系統中的話，如何制定規則讓所有人的**都能考慮全面，把所有可能的bug萌芽都滅殺在詳盡的日誌資訊中，方便bug調查，方便後期維護、擴充套件。
debug版本程式中assert才會起作用，release版本assert會被忽略，不會被編譯成執行**，並不影響程式效率。
程式中可以考慮用盡量多的assert去判斷各種可能出現的特殊情況，一旦release版本出現問題，需要調查，回到debug下直接執行，就可以最大可能快速定位到bug位置。但是assert會導致程式退出，不方便除錯，可以考慮採用自定義中斷。
#define debugactive 0
#if debugactive
# define breakhere __asm int 3
# define breakherewhenfalse(x) if((x) == false) __asm int 3
#else
# define breakhere
# define breakherewhenfalse(x)
#endif
breakhere;
breakherewhenfalse
(btf)
;
所有可能的問題都輸出，促使問題爆發出來，推進問題的解決。
解析軟體系統穩定性的三大秘密
摘要 隨著軟體複雜性越來越高，穩定性的保障越來越難，隨著服務規模越來越大，穩定性的重要性越來越高。工程師在設計和開發軟體的時候，要堅持底板思維。控制系統理論認為 系統受到某種干擾而偏離正常狀態，當干擾消除，如果系統的擾動能逐漸收斂並最終恢復正常狀態，則系統是穩定的 反之，系統偏離越來越大，則是不穩定...
軟體穩定性判斷的指標和標準
外部標準 1.給客戶帶來的損失 比如資料錯誤，系統宕機。把損失換成金錢，除以此系統本來可以賺的利潤，達到乙個百分比 標準1 客戶損失金額 利潤 說明 得到這個資料可能比較困難，現實有很多情形，我們可以靈活處理。一般的小問題客戶並不去計算損失，只要我們及時的把問題解決了就行了。然而我們總是要付出人力成...
軟體穩定性測試的測試點
1.對軟體多次測試，長時間執行，是否正常執行 2.長時間對軟體開啟關閉軟體和系統是否正常 3.軟體長時間執行某個業務後切換到別的不同的業務操作是否受影響 4.軟體長時間開啟但是不執行任何操作，然後檢查能否正常執行業務操作 5.軟體長時間對日常的使用者數進行操作執行，觀察系統記憶體佔用率是否越來越大，...