國內的程式設計師仍然有不少人是習慣於在編碼的時候，一同去考慮諸如業務、需求、設計等不同性質的問題。而他們在解釋這麼做的原因時，有的是歸諸於專案工期太緊，沒有充足的時間去分開來考慮；有的則認為分出來這麼多的中間工件，是一種膽怯的文牘主義保守做法，嚴重降低了開發的效率；還有的乾脆就覺得軟體開發就是編寫程式**，哪有那麼多複雜的考慮。
軟體開發**現較多的中間工件，確實會帶來負面的影響。一方面，其絕對的工作量肯定會比只編寫**要大；另一方面，在發生變更的時候，維持需求、設計、與**之間的一致性將是一件痛苦的差事。而業界當前非常熱門的極限程式設計等敏捷開發方法，似乎也給程式設計師們提供了一種批駁較重量級開發過程的有力**。然而，情緒化地去爭論兩類不同性質開發方法之間的優劣，往往很容易讓人陷入一種誤區甚至是陷阱。
我們**過中間工件的劃分，是為了隔離不同性質問題的關注面。而之所以要隔離關注面，是因為
7±2原則所揭示的人類思維極限的存在。實際上，如果軟體所要解決的業務問題足夠簡單，開發人員有能力同時將業務、需求、設計、與**等想清楚，那麼不劃分中間工件也許是一種不錯的選擇。但是軟體總是複雜的，而且並不僅僅只是程式設計師們自己的事情。需求必須要有使用者的參與，而使用者是看不懂**的；規模較大的軟體需要多個程式設計師來協作開發，這必須有架構師從整體上去把握各種部分的介面和協同，而架構師通過閱讀細節的**來思考其背後所蘊含的那些架構級的關係，顯然也是不可思議的。
而從實踐來看，對於較複雜的軟體，程式設計師其實並不能在同一時刻將業務、需求、設計與**結構等都考慮清楚。即使是高手也不可避免地會留下很多漏洞，只是這些漏洞可能在專案後期才暴露出來。這樣就只能依靠反覆地測試—發現問題—修改—再測試，即所謂的
bug-fix-bug週期，來幫助程式設計師最終將所有問題搞清楚。也就是說，如果軟體問題本身就複雜，人們是無論如何也繞不過那個檻的；因此藉口工期壓力而不做中間工件，其結果往往就是將大量時間浪費在修復bug的返工上。
至於中間工件劃分所帶來的負面開銷，這其實是解決複雜問題時無法避免的代價。實際上，軟體開發中會大量地存在著付出某種代價來換取某種利益的情形。我們能做的就是盡量去降低這種代價。業界目前主流的
uml語言和mda模型驅動架構方法，使得開發組能夠盡可能少地編寫文件，而且自動化地同步模型與**，已經在很大程度上消解了上述的負面開銷。
從另一角度看，物件導向的程式語言，與問題域的距離更為接近；特別是自說明的命名和**，使得人們通過直接閱讀**來理解較為簡單的業務或設計思路，開始變得較為容易。因此，極限程式設計自有其發展的生命力。不過，我們一定要注意，極限程式設計只適用於較小規模，並且業務相對簡單的應用軟體；或者是那種與業務無關的，類似
ide等的系統類軟體。
挑戰極限 極限程式設計中的「極限」
最近，一直在看robert martin的 敏捷軟體開發 原則 模式和實踐 該文中以極限程式設計 xp 來講述敏捷的實踐。看完有關於 xp實踐的部分，對 xp基本的主張和如何去實踐有了乙個大概的了解。但是，一直有個問題在我腦海中，那就是這種開發實踐方式為什麼會被稱為 極限程式設計 看完這部分之後，對...
極限程式設計下的極限測試
極限測試主要由兩部分測試組成 單元測試和驗收測試。單元測試是極限測試中主要採用的測試方法，它具有兩條簡單規則 所有 模組在編碼開始之前必須設計好單元測試用例。在產品發布之前需要通過單元測試。極限測試中的單元測試和普通的單元測試之間最大的區別是 極限測試中的單元測試必須在模組編碼之前就完成設計和生成。...
常見的程式設計陷阱
原資料來自 1.public class privateoverride public static void main string args class derivedclass extends privateoverride 輸出結果為 private f 分析 private方法被自動認為是...