這是乙個急三火四的年代，人們很不得一口吃下乙個胖子，做軟體開發的恨不得一下子就完成乙個軟體，然後就在家裡數鈔票。
心急火燎的結果呢？下面的情景是否會讓你有種似曾相識的感覺：
* 費了半天努力修改的bug，仔細想來，其實已經在需求明明白白寫好了，只是開發時未曾注意到。
* 好容易寫好的一段**，還沒來得及向別人炫耀，卻發現原來乙個好好的功能出了問題，更糟糕的是，根本看不出這兩段**有什麼聯絡。
* 這個bug讓你想罵人，因為它居然是其他人修改另乙個bug引入的。
* 這個地方有人改過，不過，修改的**解決的根本不是真正的問題。
* 客戶要的是乙個小功能，但是對我們來說，加入它無異於重寫整個系統。
……已經有無數人用無數的事實告訴我們，在軟體開發中，要付出就趁早，越晚代價越大。當然，我們能看到的大多數例子是在開發的不同階段，比如需求比開發便宜，開發比測試便宜，測試比維護便宜等等。其實，在開發之中，也是如此，新鮮出爐的**絕對比那些陳年舊帳更容易修改，不信的話，找一段自己幾個月前寫的**理解一下試試。
前面那些似曾相識的場景，多半都是「急」出來的。可現實是，我們需要在後期用更大的精力為前面的「急」買單，所以，為了不給未來的自己挖坑，我們不妨慢一些：
* 仔細了解一下需求，分析需求是不是合理，而不要低著頭就開始堆**。
* 給出乙個解決方案時，考慮一下會對已有的**造成怎樣的影響，打破窗戶容易，修補難。
* 多花點時間重構，**上的臭味越到後期顯得越刺激。
* 修改bug時，停下來想想什麼才是真正的問題，治標不治本的方案只會讓人重回夢境。
* 寫測試吧！貌似的浪費會讓你在後期遇到bug時感激涕零。
……軟體開發其實是乙個跟複雜度做鬥爭的過程，從某種程度來說，複雜度會一直在增長，我們所能做的就是盡可能降低複雜度增長的速度。我曾經和一些朋友說過，前期所做的一切是讓我們在後面有更大空間揮霍。慢下來，讓我們有時間思考自己的每一步是否邁得是否穩當，穩當的行進，心裡才踏實。
這裡的慢，實際上，還是為了快，殊途同歸。
ZZ 39條更好的軟體開發方法
1.重構是程式設計師的主力技能。2.工作日誌能提公升腦容量。3.先用profiler調查，才有臉談優化。4.注釋貴精不貴多。杜絕大姨媽般的 例注 漫山遍野的碎碎念注釋，實際就是背景噪音。5.普通程式設計師 google 超級程式設計師。6.單元測試總是合算的。7.不要先寫框架再寫實現。最好反過來，從...
python軟體開發目錄 軟體開發目錄規範
為了提高程式的可讀性與可維護性，我們應該為軟體設計良好的目錄結構，這與規範的編碼風格同等重要。軟體的目錄規範並無硬性標準，只要清晰可讀即可，假設你的軟體名為foo，筆者推薦目錄結構如下 foo core 存放業務邏輯相關 core.py api 存放介面檔案，介面主要用於為業務邏輯提供資料操作。ap...
迭代軟體開發
迭代軟體開發 整理 一 迭代軟體開發介紹 在迭代式開發方法中，整個開發工作被組織為一系列的短小的 固定長度 如 3周 的小專案，被稱為一系列的迭代。每一次迭代都包括了需求分 析 設計 實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發...