我們應該建立一個總體計劃，最大限度地發揚長避短，然後把這個總體計劃應用於自己必須解決的每個問題中。

在多年的教學生涯中，我看到過很多能力不同的學生。我不能簡單地說有些程式設計師比其他程式設計師更有能力，雖然事實可能確實如此。即使是在相同能力水平的程式設計師之間，也存在很大的區別。我經常不可思議地看到以前學習得很掙扎的學生很快精通了某種特定的技巧，或者在其他領域天賦卓然的學生在一個新領域卻暴露出明顯的弱點。就像不存在兩個完全相同的指紋一樣，沒有兩個大腦是完全相同的，對於一個人來說非常容易的一堂課對於另一個人來說可能非常困難。

假設讀者是一位美式足球教練，正在制訂下一場比賽的進攻計劃。由於傷病的原因，無法確定兩名四分衛誰能夠首發登場。這兩名四分衛都具有高度的職業素養，但是和所有人一樣，他們也有各自的優點和缺點。為一位四分衛所制訂的完美比賽計劃套用於另一位四分衛身上卻可能帶來糟糕的結果。

在建立總體計劃時，教練需要根據隊中的四分衛進行排兵佈陣。為了實現最大的獲勝機率，需要制訂一個計劃，既要認識到自己的優勢，也要明白自己的弱點。

揚長避短

在制訂自己的總體計劃時，關鍵的步驟是認識到自己的優勢和弱點。這並不困難，但它需要花費精力並且需要一個公平的自我評估。為了從錯誤中獲益，不僅需要在程式中所出現的地方修正它們，還必須對它們進行關注，至少是在大腦裡，最好是記錄在文件中。通過這種方式，可以發現在其他情況下可能錯失的行為模式。

下面將描述兩種不同型別的弱點：編碼弱點和設計弱點。編碼弱點是指在實際編寫程式碼時可能反覆犯錯的領域。例如，許多程式設計師在編寫迴圈的時候，經常會出現迭代次數多1次或少1次的情況。這個錯誤稱為柵欄柱錯誤，它取材於一個古老的難題，就是建造一條總長50m的柵欄並且每根柵柱之間相隔10英尺，一共需要幾根柱子？大多數人的第一反應是5，但是如果仔細考慮，答案應該是6，如圖8.1所示。

大多數編碼弱點出現在由於程式設計師編寫程式碼過於迅速或者缺乏充分準備而導致語義錯誤的情況下。反之，設計弱點在問題的解決或設計階段經常出現。例如，我們可能不知道該怎麼入手或者不知道怎麼把以前所編寫的子程式整合到一個完整的解決方案中。

圖　柵欄難題

儘管這兩種型別的弱點存在一些重疊，但它們會導致不同型別的問題，因此必須按照不同的方式予以解決。

* 針對編碼弱點的計劃*

在編寫程式的時候，最令人氣惱的事情莫過於花了幾個小時的時間追蹤一處語義錯誤，結果卻發現只是一個非常簡單而且很容易修正的錯誤。沒有任何東西是完美的，因此沒有辦法完全消除這樣的情況，但是優秀的程式設計師將會盡他所能避免相同的錯誤再次發生。

有一位程式設計師已經厭倦了C++程式設計中可能最為常見的語義錯誤：誤用賦值操作符（=）代替了相等操作符（==）。由於C++的條件表示式的結果是整數，而不是嚴格的布林值，因此下面這樣的語句在語法上是合法的：

在這種情況下，整數值1被賦值給number，然後1這個值成為了條件語句的結果，C++把它當作true處理。顯然，程式設計師的意圖其實是：

被這類錯誤的屢次發生搞得心煩氣躁之後，這位程式設計師告誡自己用另一種方式來編寫相等性測試，讓數字值出現在左邊。例如：

通過這種做法，如果他不小心再次犯了上面這個錯誤，1 = number這個表示式將不再是合法的C++表示式，因此會產生語法錯誤，會在編譯時被捕捉。原來的錯誤在語法上是合法的，因此它只是個語義錯誤，在編譯時可能會被捕捉，但也可能根本不會被捕捉。由於我自己也曾經多次犯過這個錯誤（有時候在查詢這個錯誤時會急得發瘋），因此也採用了這種方法，把數字值放在相等操作符的左邊。採用這種做法之後，我發現了一些奇怪的事情。由於它與我平時所使用的風格相悖，因此在編寫條件語句時把數字值放在左邊會讓我的思維暫時停頓。我會這麼思考：“我需要記住把數字值放在左邊，這樣在誤用了賦值符時就能發現這種情況”。正如讀者所料，把這種想法在腦子裡過一遍之後，絕不會再錯誤地使用賦值操作符，而是能夠正確地使用相等操作符。現在，我不再把數字值放在相等操作符的左邊，但在編寫條件表示式時仍然會習慣性地停頓一下，使上面這個想法再過過腦子，這樣就不會再犯這種錯誤了。

通過這個事情，我所得到的一個經驗就是：首先要意識到自己在編碼層次上的弱點，然後才能有效地避免它們。這是好訊息，壞訊息是我們必須通過實踐才能認識到自己的編碼弱點。關鍵的技巧是讓自己知道為什麼會犯某個特定的錯誤，而不僅僅是修正這個錯誤並繼續下一步工作。這可以幫助我們確認自己有沒有遵循的某個基本原則。例如，我們編寫了下面這個函式，計算一個整數陣列中所有正數的平均值：

初看上去，這個函式並沒有什麼問題。但是經過仔細觀察，還是可以看到它存在一個問題。如果陣列中沒有任何正數，當迴圈結束時positiveCount的值將是0，這將導致在函式結束時執行除零運算。由於這是浮點除法，因此程式可能不會實際崩潰，而是產生某種奇怪的行為，這具體取決於這個函式的返回值在整體程式中是怎樣被使用的。

如果我們很快就設法運行了這段程式碼，並且發現了這個問題，可能會新增一些程式碼，處理positiveCount為零的情況，並繼續下一步工作。但是，如果想完善自己的程式設計能力，就應該問問自己犯了什麼錯誤。當然，這個特定的問題是沒有考慮到除零的可能性。但是，如果分析只是到此為止，並不會對未來提供多大的幫助。顯然，此時應該考慮分母可能為零的其他情況，但這也不算一種非常常見的情況。反之，我們應該問問自己是否違背了什麼基本原則。答案是：我們要堅持尋找那些可能導致程式碼失敗的特殊情況。

考慮到這個基本原則之後，就很容易看到我們所犯錯誤的模式，因此在將來很容易捕捉到這類錯誤。問自己“這裡是不是存在除零錯誤的可能性”遠不如問自己“這個資料存在什麼特殊情況”更為有用。提出作用面更寬的問題，除了能夠想到不要出現除零運算之外，還會迫使自己考慮空資料集、超出預期範圍的資料等問題。

針對設計弱點的計劃

設計弱點需要一種不同的方法才能克服。但是，第一個步驟仍然是一樣的，就是要認識到自己的弱點所在。很多人在這個步驟上存在問題，因為他們並不願意對自己採取批評態度。人們總會想方設法隱瞞自己的失敗。就像接受工作面試時，當一位面試官問你最大的弱點是什麼時，你很可能會回答一些不會對面試結果產生影響的弱點，而不是坦率地承認自己的真正缺點。但是，就像超人也受制於氪星石一樣，就算是最優秀的程式設計師也存在真正的弱點。

下面是程式設計師弱點的一個示例列表（當然並不完整），讀者可以看看自己是否符合其中的幾條。

過於複雜的設計

存在這個弱點的程式設計師所建立的程式常常具有過多的組成部分，或者具有過多的步驟。雖然程式能夠完成任務，但它們無法讓自己充滿信心，就像穿上去的衣服一扯線頭就會全部散架一樣。很顯然，它們是非常低效的。

不知如何著手

這種型別的程式設計師具有高度的惰性。也許是由於在解決問題上缺乏信心，也可能生來就是慢性子，這類程式設計師花費了太多時間考慮怎麼開始解決問題。

疏於測試

這類程式設計師不喜歡對自己的程式碼進行正式的測試。這樣的程式碼在一般情況常常能夠很好地完成任務，但是面對特殊情況時常常會導致失敗。還有一些情況下，這樣的程式碼能夠順利地完成任務，但是對於程式設計師沒有進行測試的大型問題，它就難以表現出應有的適應能力。

過分自信

自信是件好事，本書的目標之一就是培養讀者的自信心。但是，過分自信和不夠自信一樣並非好事。過分自信會通過各種方式表現出來。過分自信的程式設計師可能會嘗試一種超出需要的更復雜解決方案，或者在非常短的時間內就匆匆完成一個專案，導致粗率、缺陷叢生的程式產生。

脆弱領域

這種型別的弱點可謂五花八門。有些程式設計師一直在順利地工作，但在遇到了某些概念後突然變得不知所措。以本書前面各章所討論的話題為例，大多數程式設計師在面對某個領域時，就算完成了所有的習題，他們在這個領域的信心也要比在其他領域弱得多。例如，有些程式設計師會迷失於指標程式中；或者遞迴的概念會把有些程式設計師的腦子搞混。有些程式設計師在設計詳盡的類時會遇到困難。這並不是說這些程式設計師就沒有辦法應付這些問題，但對他們而言這些是非常艱鉅的任務，就像在泥地裡開車一樣。

我們可以通過不同的方法暴露自己的主要弱點。一旦認識到自己的弱點之後，就很容易針對它們制訂計劃。例如，對於經常忽略測試的程式設計師，在制訂每個模組的編寫計劃時，可以明確地把測試作為必須完成的部分，在完成測試之前不能開始下一個模組的設計。或者，也可以考慮一種稱為“測試驅動的開發”的設計用法。在這種慣用法中，首先編寫測試程式碼，再編寫填充這些測試的其他程式碼。對那些遲遲不能入手的程式設計師，可以採用問題的分治或削減原則，一旦他覺得可以就開始編寫程式碼，當然還要知道將來可能需要對這些程式碼進行重寫。對於那些常常設計得過於複雜的程式設計師，可以在總體計劃中增加一個明確的重構步驟。關鍵在於，不管程式設計師的主要弱點是什麼，它們只不過是專案成功完成的道路上的絆腳石而已。

根據自己的優點制訂計劃

根據弱點制訂計劃在很大程度上是為了避免錯誤。但是，良好的計劃並不僅僅是為了避免錯誤。它還涉及到根據自己的當前能力以及可能受到的約束，儘可能實現最佳結果。這意味著我們還必須根據自己的優點制訂總體計劃。

讀者可能覺得本節的內容不適合自己，至少目前為止還不適合。不管怎樣，如果讀者已經開始閱讀本書，就有可能成為一名程式設計師。讀者可能覺得自己在當前階段還談不上有任何優點，但事實上還是有的，即使自己並沒有意識到它們。下面是一些常見的程式設計師優點的列表，當然並不完整。我對每個優點提供了描述和提示，以幫助讀者判斷自己是否具有這些優點：

細心

這種型別的程式設計師能夠預料到特殊情況，在潛在的效能問題出現之前就預感到它們，而且絕不會讓整體情況掩蓋那些必須精心處理的細節，而這些細節又往往是實現完整和準確的解決方案所必需的。具有這個優點的程式設計師傾向於在編寫程式碼之前先在紙上測試他們的計劃，他們會小心細緻地編寫程式碼，並且經常進行測試。

快速學習能力

具有快速學習能力的程式設計師能夠很快學會新的技巧，無論是一種已經熟悉的語言中的一項新技巧還是學習一個新的應用程式框架。這種型別的程式設計師享受學習新事物的挑戰，可能會根據這個喜好來選擇專案。

快速編碼能力

具有快速編碼能力的程式設計師無需很長時間就可以根據一本參考書搗鼓出一個函式。到了開始打字的時間，不需要特別地費勁，程式碼就會從指尖迅速湧出，並且其中很少出現語法錯誤。

永不放棄

對於有些程式設計師而言，討厭的程式缺陷就像無法迴避的個人遭遇一樣。如同程式戴著皮革手套扇了程式設計師一個巴掌，然後輪到程式設計師對此做出迴應。這類程式設計師始終頭腦冷靜、意志堅定，不會被挫折所擊倒。他們堅信只要付出足夠的努力，必將取得最後的勝利。

超級問題解決專家

假如讀者在閱讀本書時還不是一位超級問題解決專家，但是在瞭解了一些指導方針之後，覺得做所有的事情時都變得得心應手。那麼，具有這種能力的程式設計師在剛剛接觸一個問題的時候就會開始思考潛在的解決方案。

完美主義者

對於這類程式設計師而言，一個工作程式就像一件精妙的玩具。完美主義者絕不會喪失讓計算機按照他的命令列事的激情，並且喜歡想方設法找點事情讓計算機去做。在某種意義上，完美主義意味著不斷向工作程式新增更多的功能，這種症狀稱為爬行功能主義。在他們眼裡，也許可以對程式進行重構以提高效能，也許可以讓程式在程式設計師或使用者面前顯得更精巧。

很少有程式設計師能夠同時擁有上面所說的多個優點。事實上，有些優點會相互抵銷。但是，每個程式設計師都有自己的優點。如果讀者覺得自己不符合上面所說的任何一條，也只是意味著對自己還不夠了解，或者其優點並不屬於上面所提到的這幾種型別。

一旦確認了自己的優點，就需要在總體計劃中利用它們。假設讀者具有快速編碼能力，很顯然它可以使任何專案更快地到達終點。但是，怎樣才能以系統的方式利用這個優點呢？在正式的軟體工程中，有一種方法稱為快速原型法，就是在一開始編寫一個程式的時候並沒有深入的計劃，需要通過連續的迭代予以完善，直到最終的結果能夠滿足問題需求。作為快速編碼者，可以嘗試採用這種方法：有了一個基本的思路之後就可以開始編寫程式碼，用粗略的原型來指導最終程式程式碼的設計和開發。

如果讀者具有快速學習能力，在每個專案開始的時候應該尋訪新的資源或技巧來解決當前問題。如果既不具備快速學習能力，但也不會輕易被挫折所擊垮，那麼在專案開始的時候可以從最困難的部分入手，給自己最多的時間來處理它們。

因此，不管自己擁有何種優點，要保證在程式設計時利用它們。設計自己的總體計劃，儘可能地把時間留給自己最擅長的事情。通過這種方式，讀者在程式設計時不僅能夠產生最好的結果，還將體會到最多的樂趣。

制訂總體計劃

讓我們觀察建立總體計劃的一個例項。這個計劃的組成部分包括自己已經掌握的所有問題解決技巧，再加上對自身的優點和弱點的分析。我將使用自己的優點和弱點作為例子。

在問題解決技巧方面，我用了本書所討論的所有技巧，但尤其鍾愛“削減問題”技巧，因為這種技巧能夠讓我感覺到自己向最終的目標不斷邁出堅實的步伐。如果目前還無法編寫滿足完整規範的程式碼，可以先忽略部分規範，直到有信心完成剩餘的內容為止。

我最大的編碼弱點是過於認真。我喜歡程式設計，因為喜歡看到計算機按照自己的命令列事。有時候，應該分析自己所編寫的東西的正確性時，我會考慮：“直接讓它執行吧，看看會發生什麼。”這種做法的危險在於程式可能會失敗。雖然程式看上去似乎很成功，但是它並沒有覆蓋所有的特殊情況。或者它雖然成功，但並不是我應該編寫的最佳解決方案。

我喜歡優雅的程式設計，希望程式能夠很方便地被擴充套件和複用。當我編寫大型專案時，常常花費大量的時間開發其他途徑的設計方案。總體而言，它是一個良好的能力，但有時這會導致我把過多的時間花在設計階段，沒有留下太多的時間實現最終所選擇的設計。另外，這也會導致解決方案的過度設計。也就是說，有時候設計的解決方案會比實際所需要的解決方案更優雅、更容易擴充套件並且更健壯。由於每個專案的時間和金錢都是有限的，因此最佳的解決方案必須同時兼顧程式的質量和資源的節約。

我覺得自己最大的程式設計優點就是能夠很快領會新概念並且熱愛學習。雖然有些程式設計師喜歡一直使用相同的技巧，但我喜歡在專案完成時能夠學到新東西，並且總是很樂於接受這類挑戰。

有了這些思路之後，下面是我對一個新專案的總體計劃。

為了彌補我的主要弱點，我嚴格地控制自己在設計階段所花費的時間，或者說控制了在設計階段所考慮的不同設計方案的數量。對於某些讀者而言，這好像是種危險的想法。在進入編碼階段之前，難道不應該儘可能地多花點時間在設計階段嗎？大多數專案失敗的原因難道不是因為在前期所花的時間太少從而導致後期的一連串妥協嗎？這些顧慮當然是對的，但是我現在並不是為軟體開發建立一條通用的指導方針，而是為自己制訂處理程式設計問題的總體計劃。我的弱點是過度設計而不是設計不足，因此控制設計時間這個規則對我而言是合理的。對於其他程式設計師而言，這樣的規則很可能是災難。有些程式設計師可能需要一個規則迫使他們把更多的時間花在設計上。

完成最初的分析之後，我就開始考慮這個專案是否有機會讓自己學習新的技巧、庫等知識。如果答案是肯定的，我就打算編寫一個小型的測驗臺程式，對這些新技巧進行試驗，然後再把它們吸收到自己所開發的解決方案中。為了克服過於認真這個弱點，在完成每個模式的編碼時，可以新增一個簡單的程式碼回顧步驟。但是，這並不是我的意願所在。當我完成每個模組時，希望繼續前進並讓它實際執行。單純地希望我在這個時候能夠停下來就像在一個肚子餓得咕咕叫的人身邊放上一袋開啟的薯片，然後驚奇地發現這袋薯片被吃光了。在制訂克服程式設計師弱點的計劃時，不要讓程式設計師跟自己的直覺做鬥爭。如果我建立了兩個版本的專案：一個是原始的任由我處理的版本，另一個是經過優化的準備發行的版本。如果允許我對第一個版本按照自己的意願行事，但是在經過完全的驗證之前，不要把它的程式碼吸收到另一個優化的版本中，這樣無疑更容易克服自己的弱點。

本文摘自《像程式設計師一樣思考（修訂版）》