martin fowler最近在他的bliki中，談到了在開發軟體產品的過程中，是否值得追求良好的軟體設計的問題。即在追求良好的軟體設計過程中，無論是軟體企業，還是作為開發者的programmers,都會付出更多的時間、更多的成本，在多付出了這些之後，在軟體實現了良好的設計之後，他是否能夠給你足夠的，或者說你期望的回報？管理者和開發者在總結專案的時候，會承認這些工作，這些努力都是非常有價值的麼？
在這篇名為design stamina hypothesis（我把它翻譯為「設計的可持久力假設」）中，martin fowler先生給出了明確的回答。做設計當然需要花費時間和精力，需要付出努力，但這些付出都會得到回報，因為良好的設計會使將來軟體公升級、進化、完善過程變得更容易。良好的軟體設計不僅僅是使programmers感到快樂，而是會帶來實實在在的好處和回報。
martin 提出了「技術債」(technical debt)概念。如果在軟體的開發過程中不做設計或者只做很少的設計，那麼在短期內確實能縮短開發時間，提高專案進展速度，但是你卻會欠下技術債，而且這個債務會逐漸累積，並最終在將來影響到你的軟體開發生產率。
martin的假設是，在專案的開發過程中，存在著乙個所謂的design payoff line。在專案的初始階段，當所完成的功能比較少，處於design payoff line以下時，省略設計確實可以贏得時間。當你所需要開發的功能越來越多，處於design payoff line上方的時候，那麼良好的設計就會大大提高生產率，而缺乏設計的軟體，**就會變得越來越難以修改，開發的生產率就會大大下降。套用一句時髦的話就是「出來混得，一切最終都是要還的」。如果軟體開發在開始階段就缺乏設計，那麼在軟體的不斷開發迭代中，你欠下的技術債就會越來越多，開發的難度會越來越大，最後的結果只能是一團糟，導致專案延期，程式bugs不斷。
通過martin fowler先生的假設，我們還會發現，如果你只是在作乙個很小的專案，功能很簡單，將來也不會有很大的公升級，擴充套件，迭代，即該專案位於design payoff line之下，那麼你是可以省略設計，以此來換得時間和市場的。但是，如果不是這樣的專案，如果你的專案的規模最終會位於design payoff line 之上，那麼，在專案開始的時候就花些精力和時間來做設計，無疑是最划算的。關於design payoff line的確定，martin給的建議是幾周，而不是幾個月。
上面這些就是我閱讀martin fowler先生的假設後得出的心得。這些都是我個人的體會，有興趣的人可以閱讀martin fowler先生的bliki的原文。
上面大量引用了martin 的思想和理論，在此向martin fowler先生表示深深的感謝！
Martin Fowler確定QCon北京演講
敏捷宣言締造者之一 thoughtworks首席科學家martin fowler日前確定了他在qcon北京大會上的演講題目。在4月即將舉行的qcon全球企業開發大會北京站上，他將進行兩個演講，乙個是其最近一直關注 的領域特定語言，乙個是對thoughtworks在過去幾年中使用ruby語言的總結和展...
軟體測試談（一）
一 軟體測試概述 軟體測試是軟體開發過程的重要組成部分，是用來確認乙個程式的品質或效能是否符合開發之前所提出的一些要求。軟體測試的目的，第一是確認軟體的質量，其一方面是確認軟體做了你所期望的事情 do the right thing 另一方面是確認軟體以正確的方式來做了這個事件 do it righ...
談《走出軟體作坊》
像書中所說的一樣創新為兩種，一種是創作出以前沒有的技術或方法，另一種是將其他行業的技術或方法應用到沒有使用行業。作者是行業管理軟體出身，對行業管理有著深刻的認識。能將行業管理資訊化借鑑應用到軟體行業，並經過多年自身的總結，可以說這本書對於缺乏管理的軟體行業，特別是中小型公司來說是很好的乙個典範。書中...