不要陷入極限程式設計的陷阱

國內的程式設計師仍然有不少人是習慣於在編碼的時候，一同去考慮諸如業務、需求、設計等不同性質的問題。而他們在解釋這麼做的原因時，有的是歸諸於專案工期太緊，沒有充足的時間去分開來考慮；有的則認為分出來這麼多的中間工件，是一種膽怯的文牘主義保守做法，嚴重降低了開發的效率；還有的乾脆就覺得軟體開發就是編寫程式程式碼，哪有那麼多複雜的考慮。

軟體開發中出現較多的中間工件，確實會帶來負面的影響。一方面，其絕對的工作量肯定會比只編寫程式碼要大；另一方面，在發生變更的時候，維持需求、設計、與程式碼之間的一致性將是一件痛苦的差事。而業界當前非常熱門的極限程式設計等敏捷開發方法，似乎也給程式設計師們提供了一種批駁較重量級開發過程的有力武器。然而，情緒化地去爭論兩類不同性質開發方法之間的優劣，往往很容易讓人陷入一種誤區甚至是陷阱。

我們探討過中間工件的劃分，是為了隔離不同性質問題的關注面。而之所以要隔離關注面，是因為7±2原則所揭示的人類思維極限的存在。實際上，如果軟體所要解決的業務問題足夠簡單，開發人員有能力同時將業務、需求、設計、與程式碼等想清楚，那麼不劃分中間工件也許是一種不錯的選擇。但是軟體總是複雜的，而且並不僅僅只是程式設計師們自己的事情。需求必須要有使用者的參與，而使用者是看不懂程式碼的；規模較大的軟體需要多個程式設計師來協作開發，這必須有架構師從整體上去把握各種部分的介面和協同，而架構師通過閱讀細節的程式碼來思考其背後所蘊含的那些架構級的關係，顯然也是不可思議的。

而從實踐來看，對於較複雜的軟體，程式設計師其實並不能在同一時刻將業務、需求、設計與程式碼結構等都考慮清楚。即使是高手也不可避免地會留下很多漏洞，只是這些漏洞可能在專案後期才暴露出來。這樣就只能依靠反覆地測試—發現問題—修改—再測試，即所謂的bug-fix-bug週期，來幫助程式設計師最終將所有問題搞清楚。也就是說，如果軟體問題本身就複雜，人們是無論如何也繞不過那個檻的；因此藉口工期壓力而不做中間工件，其結果往往就是將大量時間浪費在修復bug的返工上。

至於中間工件劃分所帶來的負面開銷，這其實是解決複雜問題時無法避免的代價。實際上，軟體開發中會大量地存在著付出某種代價來換取某種利益的情形。我們能做的就是儘量去降低這種代價。業界目前主流的UML語言和MDA模型驅動架構方法，使得開發組能夠儘可能少地編寫文件，而且自動化地同步模型與程式碼，已經在很大程度上消解了上述的負面開銷。

從另一角度看，物件導向的程式語言，與問題域的距離更為接近；特別是自說明的命名和程式碼，使得人們通過直接閱讀程式碼來理解較為簡單的業務或設計思路，開始變得較為容易。因此，極限程式設計自有其發展的生命力。不過，我們一定要注意，極限程式設計只適用於較小規模，並且業務相對簡單的應用軟體；或者是那種與業務無關的，類似IDE等的系統類軟體。