1.好與快的關係
幾年前和乙個朋友聊天時，他抱怨他的上司說，要我寫得好又要寫快，那怎麼可能呢？我當時一愣，反問到，寫不好怎麼可能寫得快？他也一愣。
傳統觀點認為在功能、成本(人*時間)和質量這個鐵三角中，提高質量就意味投入更多成本或者減少一些功能。在功能不變的情況下，不可能在提高質量的同時降低開成成本(對個人來講就是縮短開發時間)。我的朋友持的正是這種傳統觀點。
而根據我的經驗來看，結論恰恰相反。每次我想以犧牲質量來加快速度的時候，結果反而花了更多時間，甚至可能到最後搞不定而放棄了。有了多次這樣的經驗之後，我決定把每一步都做好，從開發的前期來看，我花的時間比別人多一點，但從整個任務來看，我反而能以別人幾倍的速度完成任務。時間長了，我形成了這樣的觀念：只有寫得好才可能寫得快。
兩種觀點截然相反，所以我們都愣了。雖然我相信我的經驗沒有錯，但傳統的鐵三角定律是大師們總結出來的，也不可能出錯。那是怎麼回事呢？我開始到處查資料，但是沒有乙個人支援我的觀點。我又不想這樣放棄，後來我用了乙個簡單的辦法進行推理，結果證明兩個觀點都有各自的適用範圍。
這個推理過程很簡單，把兩種觀點推向極端：
先看看以犧牲質量來追求進度的例子。我以前參加過兩個大專案，其乙個專案的bug總數達到17000多個，耗時近三年後專案被取消。另乙個專案的bug總數也超過10000個，三年之後帶著很多bug發布了，結果可想而知，產品很快從市場上消失了。這兩個專案在開始階段都制定了極其可笑的專案計畫，為了趕在這個根本不可能的最後期限前，都採用了犧牲質量的方式來提高開發速度，前期進展都很「順利」，基本功能點很快就完成了，但是專案馬上陷入了無止境的debug之中，開發人員的士氣一**到谷底，管理層開始暴跳如雷。
如果這兩個專案有超過170000個bug，即使專案不取消，再做時間十年也做不完。由此可見：質量低到一定限度時，降低質量會延長專案時間，如果質量降到最低，那專案永遠也不可能完成。這和我的觀點一致：寫不好就寫不快。
再看看追求完美質量的例子。以前參與乙個手機模擬器的開發，我們很快達到88%的真實度，半年之後達到95%的真實度，客戶要98%的真實度。但是怎麼努力也達不到這個標準，花了極大的代價才達到96%多一點，到後來專案被取消了。
如果要達到99%的真實度，即使專案不取消，再做十年也做不完。由此可見：質量高到一定程度，提高質量會延長專案時間，如果質量要高到最高，那任務遠也不可能完成。這和傳統觀點一致，提高質量就要延長開發時間。
從兩個極端往中間走，我們可以找到乙個中間質量點。低於這個質量點，想以犧牲質量來趕進度，那只會適得其反，質量越低耗時越長。高於這個質量點，想提高質量就得增加成本，質量越高開發時間越長。這樣兩種觀點就統一起來了。
如果在大多數專案中，這個中間質量點是可以作為高質量接受的，那我們就找到了又快又好的最佳方法。這個質量點到底是多少？呵，我可以告訴你，那是87.5。但是誰知道怎麼去度量呢？沒有人知道，只能憑感覺和經驗了。
2.我們的時間花在**
經過這段時間的練習，大多數人都體會到敲**不是耗費時間最多的地方，乙個高效率的程式設計師，並不是打字比別人快，而他節省了別人浪費了的時間。我常說達到別人五倍的效率並不難，因為在軟體開發中，大部分人的大部分時間都浪費掉了，你只要把別人浪費的時間省下來，你的效率就提高上去了。像在優化軟體效能時採用的方法一樣，要優化程式設計師的效能，我們要找出效能的瓶頸。也就是弄清楚我們的時間花在哪些地方，然後想辦法省掉某些浪費了的時間。根據我的經驗，耗費時間最多的地方有：
o 分析
需求分析通常是spec工程師(或者所謂的系統分析員)的任務，程式設計師也會參與到這個過程中，但程式設計師的任務主要是理解需求，然後分析如何實現它們，這個分析工作也就是軟體設計。無論你是在計算機上用設計工具畫出正規的軟體架構圖，還在紙上用自然語言描述出演算法的邏輯，甚至在腦海中一閃而過的想法都是設計。設計其實就是打草稿，把你的想法進行推敲，最後得到可行的方案。設計文件只是設計的結果，是設計的表現形式，沒有寫設計文件，並不代表沒有做設計(但是寫設計文件可以加深你的思考)。
設計本身是乙個思考過程，需要耗費大量時間，對於新手來說更是如此。前面幾節中的需求並不難，理解它們只需要很少的時間，但要花不少時間去思考其實現的方法。這個時間因人而異，有的讀者到最後也沒有想出辦法，這沒有關係，沒有人天生就會的，不會的原因只是因為你暫時還不知道常用的設計方法，甚至連基本資料結構和演算法都不熟悉。
在後面的章節中，我們會一步步的深入學習各種常用設計方法，反覆練習基本資料和演算法，熟能生巧，軟體設計也一樣，在你什麼都不懂的時候，不可能做出好的設計。你要學習各種經典的設計方法，開始可能生搬硬套，多寫多練多思考，到後來就隨心所欲了，設計的時間就會大大縮短。
o測試
要寫得好自然離不開測試，初學者都有這個概念。他們忠實的使用了教科書上講的方法，用scanf輸入資料，做些操作之後，用printf列印來，這是乙個完美的輸入-處理-輸出的過程。測試也就是要保證正確的輸入能產生正確的輸出，這種方法的原理是沒有錯的，但它們確實耗費了我們大量時間。
如果測試只需要做一次，這種方法還是可取的，問題是每次修改之後都要重複這個過程，耗費的時間就更多了。這種工作單調乏味，而且很難堅持做下去，單元測試做得不全面，就有更多bug等著就除錯了。時間久了，或者換人維護了，誰也搞不清楚什麼樣輸入產生什麼樣的輸出，結果可能是連測試也省了，那就等著把大量的時間浪費在除錯上吧。總而言之，這種測試方法不好，我們需要更有效的測試方法才行。
o除錯
測試時發現程式有bug，自然要用偵錯程式了，對一些人來說，除錯是一件充滿挑戰和樂趣的事。而對大部分人來說，特別是對我這種做過兩年專職除錯的人來說，除錯是件無趣無聊無用的工作。熟練使用偵錯程式是必要的，在分析現有軟體時，偵錯程式是非常有用的工具。但在開發新軟體時，偵錯程式在浪費我們的時間。
偵錯程式是最後一招，只有迫不得已時才使用。一位敏捷方法的高手說他已經記不得上次使用偵錯程式是什麼時候了，我想這就是為什麼敏捷方法能夠提高開發速度的原因吧。因為沒有什麼比一次性寫好，不用偵錯程式更快的方法了。
知道了浪費時間的地方，接下來幾節中，我們將介紹避免浪費時間的方法。學完這些方法之後，我希望讀者也能達到普通工程師五倍的效率，呵，讀完本系列文章後之，希望你會達到更高。
系統程式設計師成長計畫 寫得又快又好的秘訣 三
作者 李先靜 閱讀法 軟體工程實踐已經證明code review是提高 質量最有效的手段之一，極限程式設計 xp 更是把code review推向極致，形成著名的結對程式設計工作方式，兩個程式設計師在一台電腦前面工作，乙個人編寫程式，另乙個review輸入每一行 寫程式人的專注 於目前細節上的工作，...
系統程式設計師成長計畫 寫得又快又好的秘訣 三
作者 李先靜 閱讀法 軟體工程實踐已經證明code review是提高 質量最有效的手段之一，極限程式設計 xp 更是把code review推向極致，形成著名的結對程式設計工作方式，兩個程式設計師在一台電腦前面工作，乙個人編寫程式，另乙個review輸入每一行 寫程式人的專注 於目前細節上的工作，...
系統程式設計師成長計畫 寫得又快又好的秘訣 二
作者 李先靜 1.好與快的關係 幾年前和乙個朋友聊天時，他抱怨他的上司說，要我寫得好又要寫快，那怎麼可能呢？我當時一愣，反問到，寫不好怎麼可能寫得快？他也一愣。傳統觀點認為在功能 成本 人 時間 和質量這個鐵三角中，提高質量就意味投入更多成本或者減少一些功能。在功能不變的情況下，不可能在提高質量的同...