這篇文章是受啟發于要求我寫一些設計和spec的文檔的面試要求。趁這個機會整理整理自己的思路。
什么是軟件開發呢，最常見的一種說法是，軟件開發是一門藝術。我覺得更現實的講，軟件開發應該是一種生產。跟其他所有的生產一樣。要考慮成本和收益。收益這塊，跟其他很多外部因素相關，對開發者或者說開發者的管理者來說無法控制，開發者從職業的角度出發更多需要考慮的是成本。這也是我們職業的目標。
軟件這種產品的生產，材料本身的損耗也就是電腦，電費，基本屬于沉沒成本。不會因為咱們任何努力而改變。（也不是完全不能改變，只能是變多。。。。）那么，最大的成本損耗在時間上。一方面，程序員都屬于高薪人士（相對，相對）。每一天的損耗都意味著大量的錢打水漂了。另一方面，隨著時間的推移，商業價值在降低，風險卻在增加。
對軟件開發來說，需求實現速度，應該說是很重要的，但是實現速度本身并不是考量的標準單位。作為最大成本考量標準的時間，從對她的消耗來看：除去簡單的功能點實現需要，需求的變化浪費的時間則更客觀。而無數實例證明，我們在需求分析階段投入時間誠然可以減少需求的變化，但是并不能達到我們滿意的高度，所以對需求變化的反應也是我們的重要標準。
敏捷這個詞，我覺得非常好。做為一門方法學，從名字上就說明了軟件開發需要關注的兩個重要的點：需求實現速度和對于需求的反應速度。當然，說到這里有點虛了。我想，回歸到不太實際的本質，能更好的指導我們的實踐。Rails框架為什么這么火熱，恰恰因為它做到了這兩點。我們想想，為什么要設計？我讀過讓人舒爽的代碼，也讀過看著讓人想吐的代碼。拋掉個人的感情因素，這兩種代碼有什么區別呢？大部分讓我想吐的代碼里出現的是一些重復的代碼，看起來稍有不同，卻不肯費點心思除掉這些“壞味道”。重復代碼的問題在哪里呢？最大的問題就是隨著代碼量的增多，工作量的與日劇增。維護量也會增大。而且，復雜度絕對不是O(n)。其實我常常覺得，我們最早學程序的時候要學算法與數據結構。其實這個課程很早就告訴了我們編程最重要的兩塊：算法，結構。好的設計就是好的結構。可擴展，可維護，最起碼，可以分工。
好的設計可以大量的減少代碼。減少代碼就意味著成本的降低。也就是文初說的，我們職業的目標達到了。但是現實往往不是那么美好，雖然我們有很多OO的設計模式，我們有很多最佳實踐。但是在現實中，我們往往需要妥協。一般是三個原因：性能、穩定性、各種接口，在左右著我們。其實，很多時候，這也是最考驗一個程序員的功力的地方。如何在這三個沼澤上跳舞，才是軟件開發真正可以被稱之為藝術的地方。而怎么做，則只能靠一行一行的代碼鍛煉，一篇一篇文章和文檔整理經驗，沒法一句半句說得清楚的了。