2015年5月11日 星期一

神通抵不過業力

現代軟體開發大多是團隊合作,免不了需要一些工具輔助,我想下面這些大家都很熟習:
  • 版本控制系統: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 的產生,我自己還常常進行另外一種測試,就是邊界測試,程式遇到資料邊界行為仍然正常嗎?例如程式有沒有可能越過陣列邊界?

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



沒有留言:

張貼留言