神通抵不過業力

現代軟體開發大多是團隊合作，免不了需要一些工具輔助，我想下面這些大家都很熟習：

• 版本控制系統：git, svn...
• bug 追蹤系統：trac, mantis, bugzilla
• 企業協作軟體：trello, slack...

我對這些軟體沒有什麼反對的意思，因為我自己天天在用，也覺得這是必須的。

但是我不禁想到，在這沒有這些工具前，難道人類就沒做出過什麼像樣的東西嗎？

看看 AutoCAD 好了，他是 1982 年誕生的，我初次接觸也大約是 199x 年這時候，請問這時後有上面這些工具嗎？就算有也沒有現在這麼成熟普及。

這時候我們必須捫心自問：

• 請問你開發的軟體有沒有比當時的 AutoCAD 強大？
• 請問你製造的 bug 有沒有比當時的 AutoCAD 少？

如果答案之一是否定的，可見軟體產出的好壞與有沒有這些工具沒有必然關係，工程師是否自律、生產力高低才是關鍵！

就如同佛教講的「神通抵不過業力」：再強的工具也很難阻擋一個差勁的工程師製造問題

如何 WRITING SOLDING CODE 這本書提到(強者我朋友 Yukuan 推薦，他聲稱每次開啟新專案都會重讀一次這本書)，據統計指出，QA 只能測出 60% 的 bug，剩下 40% 是測不出來的：

作者建議：「預防勝於治療」，唯有在程式中預先注入防錯的程式碼，例如用完記憶體就銷毀，用 assert() 檢測不合法參數或指標。透過這些手段，即使程式當掉，至少你知道當在什麼地方。而不是說事後拿著 debugger trace 老半天。相反地，應該把 debugger 視為最後不得已的選擇。

對於預防 bug 的產生，我個人建議是：

• 使用者輸入：網路上的封包、磁碟檔案、使用者輸入...不應該程式崩潰，要給予一些提示或錯誤恢復讓程式可以繼續正常執行。
• 程式邏輯：除了前一條外的，函式參數、臨時變數，要予以苛刻的檢查，如果不會更改就應該使用 const 修飾字，另外用 assert 確保所有的條件成立，assert 會在條件不成立時中斷程式。
• 少用 mutlti-thread：你沒有你想的那麼聰明。
• 少用 new/delete、malloc/free：如果您是用 C++，多用 STL 吧，如果非得用 C 動態配置記憶體，請先幫自己穿上防彈背心(例如使用 memory leak 偵測工具 valgrind)。
• 不忽視任何 compiler 產生的 warning：事實上，除非必要，應該保持程式 0 warning
• 用 cppcheck、PC-lint 檢查程式：這些靜態分析工具可以幫您找出程式中未盡完善的地方，最常見如有 malloc() 但是沒有 free()。
• 確保自己在神智清楚下寫下每一行程式(這可能才是最重要的)

歡迎各方先進幫忙補充!

[2015/05/17 補充]

預防 bug 的產生，我自己還常常進行另外一種測試，就是邊界測試，程式遇到資料邊界行為仍然正常嗎？例如程式有沒有可能越過陣列邊界？

又到了好書推薦時間，下面這本不但是由電腦科學界的大師所寫，裡面所講的測試方法非常實用，不會打高空，不需要特殊軟體，非常值得一讀：