[日記] 啊～ debug 到吐血的一天

話說評量 CMMI 是軟體成熟度的一種方式。照理說一家通過 Level 3 準備越級挑戰 Level 5 的公司, 其內部的整個軟體開發流程及品質應當是在水準之上; 然而, 事實卻非如此...

CMMI 或許能夠評量軟體開發流程的成熟度, 但, 似乎卻無法評量到軟體開發人員本身程度及素質的問題。會有這個想法, 是因為我在今天深刻體認到了。

今天寫程式時, 我花了一個下午的時間在 debug 一個錯誤, 我一直以為是我的疏忽, 才造成程式的錯誤; 因此我花了相當多的時間在前後比對我的程式邏輯。直到... 我無意見在某個 JavaBean 的建構子發現了下面這行程式碼:

createUser = ( ( (WelcomeBean) ActionContext.
getActionContext().getRequest().
getSession().getAttribute("welcomeBean")).
getPersonalDate().getPersonalName());

這行程式碼不是我寫的。我們先不論程式碼本身的寫法如何; 我們純討論一個 Programmer 的觀念。

就 一般的認知, 拿來當成 domain object 的 JavaBean 實在是不應該被綁死在某種協定下才是, 因此多數時候, 我開發 JavaBean 時會特別去注意這點。但, 上例的這行程式碼很明顯的被綁在 HTTP 下; 因此當我在一般的 class new 這個 domain 物件時, 便發生了無法 initial 的情況, 這造成了我寫的程式無法執行... 並花了我近一下午的時間除錯...

政府單位及資策會還要再繼續吹虛 CMMI 帶來的神奇功效嗎? 在這之前, 是否應該先好好的加強一下程式開發人員或系統分析人員本身的素質呢? 不然, 就算生產出來的軟體程式執行時沒問題, 但, 一見原始碼就看到一堆為了隱藏錯誤而「硬湊」出來的程式, 這真的就代表是品質及流程的改善了嗎?

相關網站:

• CMMI 模式 1.1 中文版