拿vs來說，有個外掛，可以在編寫程式碼的時候輸入程式碼關鍵字，自動索引你需要的程式碼。這些都不是重點，重點是要有良好的邏輯思維，分析能力，再加上組織能力，還有良好的編寫習慣。才能快速寫出高質量程式碼。

對我來說，答案是測試驅動開發（TDD），並用小型可測試單元編寫應用程式。我知道這樣的觀點貌似不大合理，因為這意味著要編寫更多的程式碼，而不是把測試部分跳過去。而敲擊鍵盤的次數越多=花費的時間越多。但是，我認為如果返回去修復錯誤，花的時間會更長。

當我在沒有測試的情況下程式設計，我總是會犯錯，然後要花費好幾個小時來修復它們，因為這些錯誤是無法預測的。我當然可以毫不費力的一直碼下去，但是，可能突然間就會因為個小錯誤害我三個小時白乾。

這種情況通常會發生在“哈哈，再編完這一點兒我就全搞定了”的階段。我會打電話給我妻子：“嗨親愛的，我收拾下東西就能走了，咱們晚飯吃點兒啥？”而接下來的情形是：已經凌晨兩點了，我還在辦公室裡抓瞎……

令我驚訝的是，當我切換到TDD時，我的速度反而加快了。並不是立即變快的那種哈，因為我必須要透過TDD學習曲線。不過一旦我這麼做了，程式設計就會變得更容易，壓力更小了，速度也更快了。

現在，我為一個函式編寫一個測試程式，然後執行測試，顯示其測試失敗（因為這個函式還不存在），接下來編寫函式，以便能透過測試。當測試通過後，我就可以繼續下一步的工作了。當我採用這樣的開發方式時，我發現我所開發的程式碼出現錯誤的情況變得非常少了。

1．如果一個函式的長度超過了8行，我就會產生懷疑。

2．如果函式中有一個以上的分段縮排，我就會產生懷疑。換句話說，條件是ok的，但條件內的條件是值得懷疑的。

3.如果一個函式要帶3個以上的引數，我就會產生懷疑。

4．如果我需要通篇檢視所有的檔案，我就會產生懷疑。

當然，有時候我們的確需要編寫長而複雜的函式或檔案，這就是為什麼我只是懷疑，而不是禁止執行。複雜性可以被看作是一種程式碼形式，這樣的程式碼並不意味著就肯定不好。只不過，我會著重觀察下的。

還有一個竅門哈:我會不斷的研究哪個任務最容易實現。比方說，我正在為“吃豆人”程式設計，我不知道遊戲裡的幽靈要怎麼編寫AI。我的策略是直接忽略這個問題。我只碼我知道的東西。

在吃豆人這款遊戲裡，或許，我不知道迷宮該怎麼表示；我不知道怎麼才能讓吃豆人動起來；我不知道怎麼才能讓吃豆人吃豆豆……

這都沒關係，因為至少我知道如何編寫一個可以把點數加到分數里的函式。即便我不知道分數如何顯示，但我知道如何新增點數，所以我會利用TDD把它寫出來。寫完以後，我就開始研究下一個最容易實現的任務，也許是在螢幕上顯示出一個個的豆豆……同樣的道理，我會一直這樣按部就班的做下去，直到完成所有的任務。

這讓我的速度有所提高，顯然，先為簡單的問題找到小的解決方案，也就相應的為更難些的問題提供瞭解決方法。如果你連怎麼繪製幽靈、迷宮、或是如何將幽靈和迷宮作為資料結構表示出來都不知道，又怎麼可能會知道如何編寫幽靈的AI呢？所以，我會從小處著眼，在我已經做好的相對簡單的事物上逐步累積。萬丈高樓平地起嘛。

所以，我的速度反而更快了，因為我不會傻呆呆的盯著螢幕，琢磨“我特麼到底該怎麼做?”

有時候，當我最終攻克了難題，回過頭來我才意識到它們其實並不存在。我並沒有刻意而為之，而是循序漸進，聚沙成塔。無程式碼程式設計是最快的程式設計方式。