這是一個急三火四的年代，人們很不得一口吃下一個胖子，做軟件開發的恨不得一下子就完成一個軟件，然后就在家里數鈔票。
心急火燎的結果呢？下面的情景是否會讓你有種似曾相識的感覺：
* 費了半天努力修改的bug，仔細想來，其實已經在需求明明白白寫好了，只是開發時未曾注意到。
* 好容易寫好的一段代碼，還沒來得及向別人炫耀，卻發現原來一個好好的功能出了問題，更糟糕的是，根本看不出這兩段代碼有什么聯系。
* 這個bug讓你想罵人，因為它居然是其他人修改另一個bug引入的。
* 這個地方有人改過，不過，修改的代碼解決的根本不是真正的問題。
* 客戶要的是一個小功能，但是對我們來說，加入它無異于重寫整個系統。
……
已經有無數人用無數的事實告訴我們，在軟件開發中，要付出就趁早，越晚代價越大。當然，我們能看到的大多數例子是在開發的不同階段，比如需求比開發便宜，開發比測試便宜，測試比維護便宜等等。其實，在開發之中，也是如此，新鮮出爐的代碼絕對比那些陳年舊帳更容易修改，不信的話，找一段自己幾個月前寫的代碼理解一下試試。
前面那些似曾相識的場景，多半都是“急”出來的。可現實是，我們需要在后期用更大的精力為前面的“急”買單，所以，為了不給未來的自己挖坑，我們不妨慢一些：
* 仔細了解一下需求，分析需求是不是合理，而不要低著頭就開始堆代碼。
* 給出一個解決方案時，考慮一下會對已有的代碼造成怎樣的影響，打破窗戶容易，修補難。
* 多花點時間重構，代碼上的臭味越到后期顯得越刺激。
* 修改bug時，停下來想想什么才是真正的問題，治標不治本的方案只會讓人重回夢境。
* 寫測試吧！貌似的浪費會讓你在后期遇到bug時感激涕零。
……
軟件開發其實是一個跟復雜度做斗爭的過程，從某種程度來說，復雜度會一直在增長，我們所能做的就是盡可能降低復雜度增長的速度。我曾經和一些朋友說過，前期所做的一切是讓我們在后面有更大空間揮霍。慢下來，讓我們有時間思考自己的每一步是否邁得是否穩當，穩當的行進，心里才踏實。
這里的慢，實際上，還是為了快，殊途同歸。