關于本系列文字的來源,初衷和內容定位可以參考第一篇的開頭部分，鏈接地址如下： http://blog.csdn.net/binarytreeex/article/details/8174445 http://www.cnblogs.com/WideUnion/archive/2012/11/12/2766397.html 這里就不再重復了。本文的前一篇是講程序員學習方面的話題，感興趣的可以訪問下面的連接： http://blog.csdn.net/binarytreeex/article/details/8174445 http://www.cnblogs.com/WideUnion/archive/2012/11/12/2766397.html 問題解決篇主要討論的是，在實際工作中解決問題的方法和心得。在我讀大學的時候，我的老師曾說過工程師的責任就是解決問題。無論一個開發者的能力有多強，工作態度有多好，如果不能解決問題的話那么就什么都不是。所以能夠解決實際問題是一個軟件工程師的核心價值所在。本文分享內容的定位和第一篇中的一樣依然不談經典或者范例的東西，我相信這和大部分或者相當一部分的教科書，培訓課程中的內容會有所區別。我想和同行們分享的仍然是我在實踐中的體會與心得。這些內容主要側重在解決問題的方法和思維技巧方面，所以本文不能解決某一個很具體的問題。比如，你不能在本文中找到如何實現分頁查詢的答案；如何給線程傳參數的實現方法，等等。另外常規的一些所謂的解決問題的方法在本文中也是不討論的，比如：論壇發帖，google或者百度，qq群提問，向老手提問，等等。當然這些方法也是有用甚至是最常用的，不討論是定位的原因，不是我想否定這些方法的作用和價值。由于本文介紹的內容來自個人的實踐，對于解決問題這樣一個宏大的話題和全體開發者這樣一個寬泛的群體來說，局限性和片面性是在所難免的。所以請同行們自行取舍，同時也要根據自己的經驗，實際應用場合做出適當的變化，這樣才能更好的應用本文介紹的內容。如果分享的內容可以為同行們解決實際工作中的問題起到積極作用的話，那么我的目的就達到了。當然如果能夠達到庖丁解牛那樣游刃有余的境界那是最好的。 作為問題解決篇的上半部分主要是針對新手來說的。我想討論一下幾個影響新手解決實際問題的因素，這些因素是我在實際工作中觀察發現的。總體來說新手遇到的問題是比較簡單的，因為一般情況下是不會把一個有難度的問題交給新手來解決的。因此新手的問題通常不應該被稱作問題。我當然沒有任何輕視新手的意思，只是針對問題本身而言的。基于這個前提新手注意改善一下自己的工作方法，從最終結果看是可以提高甚至顯著提高解決實際問題的能力的。這些因素主要是以下三個： 1.不清楚或者不知道自己在做什么 2.實現功能不到位 3.程序調試不通 下面開始依次討論這三個問題 **一．不清楚或者不知道自己在做什么** 能力差的一個表現是花了時間解決問題，但是最終沒有解決。造成這一結果的原因當然是多種多樣的，其中有一部分是新手選擇了完全錯誤的方法或方向來解決問題。對于選擇的方法或方向不能解決問題這一點來說，新手往往完全沒有任何感覺，給人的第一印象是對于自己當下在做的事情意味著什么，往往不清楚甚至完全不明白。對需要解決的問題本身的理解應該也是一個原因。如果是這樣的話那么這個解決方法還是相對很簡單的，那就是每次接到任務或者準備解決問題時，需要確認自己是否理解清楚了。但是更多的情況卻不是由于對問題本身的理解引起的，那么這個時候怎么辦呢？ 首先需要確立一個信念：上級安排給新手的問題一般來說都是簡單的，容易解決的。所以不要慌張，要有必勝的信心。其次，在動手前先思考一下我將打算如何解決這個問題。當然由于經驗的匱乏和各人能力的差異，這種思考在相當的情況下很有可能是效果不太理想的，但是我還是建議堅持這么做，次數多了能力就慢慢來了。第三點需要確認自己解決問題所需要的信息都了解清楚了。新手工作時間不長接觸的東西都是以前沒有了解的。特別是涉及到具體于項目相關的內容更是如此。而解決一個實際問題不可能就是一個孤立的問題，需要解決的問題往往會和其它已存在的內容是有聯系的。而這些有聯系的內容往往是新手不了解的。所以新手需要確認這些內容自己已經了解了，否則就需要向上手詢問了，這個是合情合理的提問。 我舉一個簡單例子來說明一下。我有一次面試被要求直接修改一個界面上的功能，是在真實的項目中修改。當打開solution后發現里面有很多工程和N多的窗體，于是第一個面對的問題就是需要修改的位置在哪里？我見到過的新手很可能會有以下一些做法： 1.在整個solution中慢慢找，而且找了N個小時后也不懷疑自己是否可以找到。 2.執行程序，找到主窗體（這多少是一個進步），然后在主窗體中改。至于是不是應該在主窗體中改就不考慮了。如果沒有在主窗體中找到需要改的內容，那么自己就加進去然后實現這個功能。 3.沒有做什么實際事情，可能是在發呆，可能是想了一會又開一會小差，如此不斷交替。 4.從自己看到的第一行代碼開始讀代碼，然后試圖了解其中的邏輯，其思路是不讀懂代碼如何修改呢？ 5.… 第一點就是方法選擇錯誤。其錯誤不是在于找那個窗體，而是找了N個小時后還在找。假設給你一封信，上面沒有地址，只是告訴你內容然后要求你去給某一個和信的內容匹配的人。那么你會從一個城市的第一條街道的第一個門牌開始依次把整個城市遍歷一遍么？另一個問題是沒有從自己嘗試的實踐活動中得到的反饋來修改自己的行為或者決策。給人的印象就是不知道自己做的事情意味著什么，對能不能完成任務一點感覺也沒有。第二點是屬于不動腦經的作法，要求是改程序而不是新實現一個功能。并且加入代碼的位置是否正確也不考慮，這是對自己所做的事情完全沒有感覺。第三點是比較糟糕的，應該盡快改變。第四點方法和思路都有問題。新手不妨評估一下自己的讀程能力，如果認為自己足夠強那還可以不妨一試，否則就不應該這么做。可以說這種新人對自己能力的認識都有問題。實際上，有足夠讀程能力的人一般是不會那么盲目的就開始讀程的。敢這么做的基本上都是讀程能力比較差的。 我說一下自己的作法，當然我不是說這個就是標準答案，只是介紹一個可供選擇的方法以供參考。修改功能的第一步是需要知道在哪一個窗體中修改，而面對那么多的窗體最佳的選擇就是提問，請熟悉項目的人告訴我那個窗體在哪里。原因如下： 1.我不了解項目，我是在一無所知的情況下開始的，這樣的提問是合情合理的。當然我是大致看了那些窗體的，但是發現自己找出來大有難度。 2.我當時狀態是在上機筆試，我不能把有限的時間花費在找窗體上。 第二個理由就我的例子來說更強一些。當然實際工作的情況會有所不同，所以大家需要根據自己的具體情況選擇不同的作法。但是一條原則是把主要的精力和時間用在解決主要矛盾上，不要被次要或者支流問題分散了注意力。我通過詢問就將解決問題需要的相關信息獲取了，這是能夠解決問題的基礎。第二步是打開那個正確的窗體根據要求修改代碼，那么這時又有一個問題，需要修改的代碼在哪里，或者說應該在哪里改代碼？那么這時是不是仍然可以使用上面的兩個理由再次提問呢？就我的情況來說就不能再提問了，理由如下： 窗體中的代碼不太復雜，應該可以獨立解決。這個事實是在讀了代碼以后才知道的。所以新手可以嘗試去實踐一下，關鍵是要根據實踐得到的反饋結果及時修改自己的方法，采取最佳途徑解決問題。如果當時我基于上述的兩個理由不去讀代碼而直接再次提問，那么面試你的人是知道那些代碼的復雜程度的，所以他就很有可能會認為我的能力有問題了。因此提問要注意分寸和度。新人可以以這個例子作為參考，當然自己具體遇到場合會有所不同，所以要結合自己的具體情況作判斷。這里順便提醒新手，不要在自己不理解的情況下在真實項目中擅自修改別人寫的代碼，這是很不明智的作法。如果實在要改，那么在改的地方調用一個方法，自己想寫的代碼寫在那個方法中，然后給那個方法和調用該方法的地方寫上注釋和日期。對于我遇到的這個問題來說，邏輯不是很復雜，看一下代碼也就能夠確認位置了。那時我是一個有工作經驗的程序員，但是作為上機測試題目還是給出了一個不太難的問題，這說明一般來說不會給新手太難的問題，所以應該要有信心。然后我就在相關的位置修改代碼，實現要求的功能。 接著又來一個新的問題，面對那么多的工程，如何執行程序？執行后如何操作才能執行到我需要調試的代碼呢？這也是解決問題需要的相關信息。沒有這些信息，程序無法調試，那么問題也就無法解決。改完代碼只是改完，調試通過才能算是解決問題。這個問題的處理原則上面提到了，這里可以再給一個量化的尺度，以便實踐中執行。假設修改代碼花費了30分鐘，這是解決主要矛盾花費的時間。那么解決次要問題的時間原則上應該小于這個時間，或者遠小于這個時間。具體我的例子來說，如果嘗試執行程序花費了30分鐘還沒解決，那就是方法選擇有問題了。 所以不要花費過多的時間在次要矛盾上，不要無謂的浪費時間。自己找可能需要一小時，了解的人告訴你只需要幾秒鐘。另外需要注意，在類似的這些場合新人要習慣提問，敢于提問，但是問了之后需要記住，同樣的或者同類型的問題最好不要重復提問。對于這個上機筆試問題我的解決過程是這樣的：我看了一下那個窗體所在的工程，發現不是默認啟動執行的工程。所以就將這個項目設置為默認啟動。新手注意，這時修改了solution的設置，最好記住原來的啟動工程是哪一個，以便改回來。然后就是執行那個工程。結果是程序拋異常無法執行，說是初始化失敗。 這是遇到的第四個問題，現在是應該嘗試解決這個問題還是直接提問？就我的例子來說是直接提問，理由如下： 1.解決初始化失敗這個問題超出了筆試題考查的范圍 2.我對那個工程不了解，初始化中的邏輯有多復雜不確定，所以是否可以在筆試規定的時間內（實際上時間沒有明確規定，但是一般主觀上會有一個可接受的范圍）完成沒有把握 3.退一步講，我能找到初始化失敗的原因；再退一步講，我還有能力和時間解決初始化拋異常的問題，那么我真就去fix那個bug么？我的回答是：不。因為我不是該公司的員工，我不應隨便修改那些沒有要求我改的代碼。 第三條理由在這個場合是最強的。新人可以結合自己的在公司中遇到具體情況靈活的確定自己的決策。于是我就將默認啟動工程改回來，然后提問要求告知如何操作才能執行到自己修改的代碼。在獲得這些與解決問題相關的信息后，這個調試工作很快就完了，上機筆試題也就順利做完了。由于是在真實項目中修改的，所以一個細節是臨走時告知相關人員我修改的代碼的位置和新增的方法。 新手可以體會一下，什么時候提問什么樣的問題，以及什么事情自己可以去嘗試解決，嘗試的度的把握；什么事情自己不要求嘗試解決。我相信這一點上部分有工作年份的開發者或多或少也會有的。如果把這個問題擴展一下，其應用的場合可以擴展到對問題的主要矛盾的辨識上，進而可以應用在解決更復雜的問題上。 **2.功能實現不到位** 經驗的不足，業務知識的匱乏是我觀察到的新手實現功能不到位的主要原因。當然出現這種問題也是正常的，而且也不是什么嚴重的問題或者過錯，簡單提一下在工作中注意避免就可以了。下面列舉一下幾種不到位的情況： a.如果要求實現用戶注冊功能，并且沒有給出具體需求，那么一個細節是：要求用戶重復輸入一遍密碼是應該實現的。以目前的使用習慣沒有明確告知做或者不做，而程序員事實上沒有做出來就可以理解為功能實現不到位。 b.窗體界面上控件的大小，顏色，字體是否和已存在的控件一致。比如窗體上已有按鈕控件的大小都是一樣的，那你新加的按鈕大了點或者小了一點，那就要注意了。 c.操作習慣是否一致。比如，控件內容填充是否聯動；鼠標移動到控件上面是否有選中效果；錯誤信息顯示位置等等。 d.編碼風格，注釋書寫格式是否一致等等。 再舉一個我在實際工作上遇到的一個例子。一個新手實現完成了一個用戶登錄界面及其中的邏輯。但是如果由于忘記密碼或者其它原因導致無法登錄成功時，登錄界面無法關閉，用戶無法完成其它操作，比如退出軟件。這是一個真實案例，而且在我提出不完善的地方后，那個新人還拒絕修改。我最后是用一起玩過的暗黑登錄戰網的例子才讓他明白功能上的缺陷。主體上登錄功能是實現的，也測試通過了，這個沒有問題。但是遺留一個無法退出登錄操作問題，這就是功能實現不到位，或者說不完整。在真實開發中，這和沒有完成功能基本上是等價的。 另外一個造成實現功能不到位的原因是缺乏質量意識和產品意識。這個錯誤我是犯過的，在一個外包公司工作時就有這個問題。那是第一次開發有用戶可以直接操作的界面的軟件產品。之前的想法總是關注在功能是否實現上，而忽略了上面提到的那些注意點，所以我開發的模塊沒有通過測試。注意，當時我是有六年開發經驗，還有高程證書的，絕對不是一個新手。這里強調一下，希望新手注意。 **三．程序調試不通** 從整體上來說，調通程序對新手是一個坎。能夠順利的調通程序是開發者可以獨立工作的一個重要考察標志。回想自己學習C語言的時候，還是吃了點苦頭才走過來的。先談一下編譯錯誤，主要是兩個：語法錯誤和鏈接錯誤。 對于編譯中的語法錯誤，可以選擇出現在前面的錯誤先解決。這是因為編譯器在檢查代碼的語法錯誤時，有可能前面的語法錯誤導致后面的錯誤。這時先嘗試解決后面的語法錯誤，就不太明智，難度相對就會大點。所以建議解決語法錯誤時從第一個或者靠前面的開始。另一個策略是先解決容易的語法錯誤。有時候出現語法錯誤很多，看著是比較煩的，這時可以先把簡單的明顯的錯誤解決掉。比如，看到書上的一段代碼，想試一下，于是將代碼敲進去然后編譯。這時出現語法錯誤就比較多了，那么可以將類似標識符未定義（產生這個錯誤的原因可能是敲代碼時的手誤）之類的錯誤先解決掉。這樣就可以逐步減少錯誤的數量，從而可以讓我們的注意力能更好的集中在難度大的錯誤上。從總體上來說，語法錯誤的排查解決應該算是一個比較容易處理的問題。以當前流行的開發工具來說，對語法錯誤的排查提供了越來越好的支持，所以即便是新手我還是建議能夠靠自己的能力完全排查掉語法錯誤。 相對于語法錯的簡單而言，排查編譯時的鏈接錯誤的難度就會大一點了。在C或者C++這類編譯器中，沒有將必要的庫文件引用到項目中是產生鏈接錯誤的一個頻率很高的原因。當出現鏈接錯誤時，可以先肯定一點，源代碼本身已經沒有問題了。因為代碼只有在通過詞法和語法檢查才會編譯生成代碼，所以產生鏈接錯誤時，代碼本身的出問題的可能性就不大了。這個線索可以告訴我們解決問題方向就不要在源代碼本身去找了。需要注意一點，對于編譯時的錯誤，一定要看清錯誤的信息，明確錯誤信息說的是什么然后再去排查錯誤，切記。因為很多的情況下錯誤信息就直接給出了答案的。舉一個我在開發EntityModelStudio時自己遇到的問題。我在一個工程里引用了另一個工程的dll，但是由于操作問題，實際引用的dll是另一個位置的不同版本的同名dll文件。產生的后果是dll工程調試什么問題都沒有，但是引用后調試時怎么做都是錯的。新手可以體會一下實際問題是不太按規矩出牌的。 除了編譯錯誤，另外一類就是所謂的邏輯錯誤了。這才是開發者調試程序的重點。實際上在很多場合兩，三個小時排除幾百，上千的語法錯誤都不算什么，所以排除實現不了指定功能的邏輯錯誤才是核心問題。邏輯錯誤的具體表現是程序執行的結果達不到預期的結果，或者只是部分達到要求而不是完全符合要求。造成這個結果的原因當然是各種各樣的，可能是選擇算法有問題，調用的方法不正確，等等。對于這個問題我給出的建議是請掌握調試程序的基本技巧，就是斷點設置和變量值的查看。 斷點的設置可以從發現出錯位置的方法的開始處設置，或者某一個肯定在出錯位置前面的地方，當程序停在斷點后按F10（Step Over的意思）逐步跟蹤代碼。當發現執行某一行代碼執行完時結果不對，那么就要查看這行代碼了。如果是單一的代碼那么根據錯誤的結果修改代碼，如果是方法調用，那么就要進入到這個方法的內部（按F11，Step Into意思），使用相同的辦法繼續跟蹤。用這個辦法可以逐步逼近錯誤的位置。有時為了能提高跟蹤代碼的效率，在自己對錯誤和代碼比較熟悉的情況下，可以在某些關鍵點設置斷點，查看程序的執行情況。這個事情聽上去比較簡單，但是遇到一些新手卻會犯這么一個錯誤。F10和F11的功能是清楚的，但是在看到方法調用后結果不對時，卻不知道要進入該方法的內部繼續跟蹤代碼。這里提醒新手，F10和F11就是這么交替使用的，直至定位到最終出錯的位置。如果僅僅使用這樣的方法就可以定位并排除錯誤，那么這樣的錯誤還是比較容易的，有可能是最容易的情況。下面介紹稍微有一點難度的情況。 有時候我們可能需要寫一點代碼（這些代碼還不能算是測試代碼），為使用斷點設置這個調試手段起到輔助的作用。比如，錯誤的位置是在一個循環體內。如果我們直接簡單的在循環體內設置斷點，那么循環執行的第一次就停在斷點處，然后開始單步跟蹤。這時就會有一個問題，這個循環要跟蹤多少次，才能等到出現錯誤的那次循環呢？如果是第一次，或者前幾次那還好，如果是100次，200次或者更多次那就麻煩了。對于這樣的場合就需要寫點代碼來輔助調試了。假設循環是for循環，那么在循環體內的恰當位置寫下類似下面的代碼： ~~~ for (int i = 0; ...; i++) { ? ? // 這些是需要調試的代碼，已經存在的，假設有若干行 ? ? ...? ? ? // 這個if語句是需要加入的調試代碼 ? ? if (i == 100) ? ? { ? ? ? ? ?int a = 10; ? ? ?// 斷點設置在這行代碼上 ? ? } ? ? // 這些是需要調試的代碼，已經存在的，假設有若干行 ? ? ...? } ~~~ 調試代碼起到的效果是，在循環到第101次時程序就會停在斷點處了。這可以顯著提高調試的效率。還有一些場合我們調試的程序和Windows的消息有關，這個時候斷點的設置位置和時機就會比較麻煩。比如，當需要把斷點設置在鼠標事件中時或者OnPaint事件時，就會這樣。因為直接設置的話，那么每次鼠標事件或者OnPaint事件觸發時都會導致程序停下來。而這時還遠遠沒到錯誤出現的時候。這時可以考慮先不設置斷點，等到最后一步操作前再設置斷點。比如，需要將用戶輸入的數據在OnPaint事件中顯示在客戶區。那么可以考慮在恰當的位置執行一行刷新客戶區的代碼（對于C#的窗體是Invalidate，對于MFC還可以考慮發消息），斷點先設置在那行刷新的代碼上。等程序執行停在那行代碼時，再在OnPaint方法中設置斷點，然后按F5，這樣就可以讓OnPaint中斷點直接停在我們需要的時刻上。再給出一個可供選擇的方案是，如果可能，將OnPaint中的代碼拿出來，放到按鈕的點擊事件中，這樣調試就可以避開原來的麻煩了。更一般的思路是，在程序中加入調試代碼，一般是一個if語句。該語句的條件表示了你希望程序停下來單步跟蹤的時刻，然后將斷點設置在這個if語句內部的代碼上就可以了。 有些場合可以考慮使用控制臺輸出信息的辦法。當然也可以選擇寫文件，作用是一樣的，但是對于Visual Studio開發環境來說控制臺輸出對調試程序更為方便些。在程序的特定位置寫入一些輸出信息到控制臺的代碼，C#中我用Console類的WriteLine方法，或者Debug類的同名方法。這樣程序的執行不會被打斷，同時又能看到必要的信息。這是一個很不錯的優點。在調試的時候，如果覺得有困難，錯誤位置無法確定，那么我建議可以采取逐步解決的辦法。先實現最簡單的情況，然后調試通過，接著再實現下一個情況，然后再調試通過。如果可能這里我想強調一下，這里分步依次實現的情況最好能夠做到獨立。比如，代碼可以用明顯的if else語句或者switch語句的分支隔開，或者代碼放在不同的方法中。這樣在調試程序時可以讓我們每次只關注在一個情況上，并且處理不同情況的代碼至少在視覺上沒有相互干擾，這對我們解決問題是有幫助的。這個方法在很多場合是很有效的，用好的話還是簡化問題的方法。在開發EntityModelStudio的時序圖時我采用的就是這個方法，所不同的是時序圖的各種操作行為的分類計數對新手來說是一個有點難度的問題。 **四．兩個有用的技巧** 再介紹兩個個人認為很有用的技巧，那就是對比法和關鍵點查找，這是我在工作第一年維修家電時積累的經驗，實踐發現在軟件開發中也是有用的。所謂對比法就是手上有一份代碼（或者例子）可以實現要求功能，而我們現在需要實現相同的功能，那么我們就可以對照著例子改，直至實現需要的功能。聽上去很簡單，事實上這個方法的表述也確實很簡單，也許會有人覺得這和google或者百度后的copy/paste有區別么？應該說都會用到copy/paste，這點相同，但是思路上不同，這是區別。我用前幾天在CSDN上看到的一個帖子作為例子來說明。 帖子中的有如下的代碼（不是原文，但是意思相同）： ~~~ public class MyClass { ? ?int Age {get; set;} } ~~~ 帖子的問題是：給MyClass對象的Age屬性賦值，提示出錯。這當然是一個很新手的初級問題，直接加上public修飾符就可以解決問題。下面試一下用對比法來解決。 問題的現象是不能通過對象訪問屬性，而事實是應該可以訪問，那么就要試圖去找一個例子，而那個例子是可以通過對象訪問屬性的。這樣的例子上網很容易找，然后對比差異，應該很快發現差一個public，加上就可以了。這個和copy/paste還是接近的。但是有的時候找不到這個例子怎么辦？那么我們可以通過對比別的內容來嘗試解決問題。比如，現在問題是通過對象訪問不了屬性，那么可以通過對象訪問方法么？如果找到通過對象可以訪問方法的例子，那么就可以考慮通過調用方法的例子來修改屬性。這個就是思維技巧的差異了，要靈活應用方法。在加大一點難度，那么上不了網怎么辦？這時可以考慮通過現有工程中已有的代碼作為例子。這個問題的難度應該說不大，但是思考的步驟對于新手來說應該是有點挑戰的。從解決問題的思考技巧來說，如果一個新手自己就可以有這樣的思路，那我就認為這個新手是有才的。希望新手可以體會一下。不同的技巧使用對比法可以在更為復雜的情況下解決難得多的問題，這部分在下篇討論了。 從我個人的經驗來說，新手在學習開發或者一個開發者開始一個新的開發方向的時候，典型的就是使用一門新的語言，會遇到一些無法用常理可以解釋的問題。比如我自己的第一個Windows程序。我用了很短時間將30行左右的代碼敲入計算機，但是卻用了幾乎整整八天的時間才調試通過。這個Hello World級別的程序，最終查出的原因是工程名不對。我用的是abc，改成aaa就可以了。這類問題在此后的開發經歷中也遇到過，但是總體是越來越少，解決問題所耗費的時間越來越短。但是其共同的特征是無法用常理解釋或者莫名其妙的自己消失了。遇到這類問題時，首先確保當前的工程足夠簡單。如果沒有足夠簡單的工程，可以考慮新建一個。然后可以嘗試逐步注釋代碼找出問題原因。或者先構造一個足夠簡單并可以通過調試的程序，然后一步一步的修改朝目標逼近。在這一過程中哪一步修改出了問題，那么問題就在那一步上。當然最好每逼近一步就做一次備份。總體上來說這個方法也是屬于對比法的范疇。 所謂關鍵點查找是指程序執行在時間上是順序的，由此總體上實際的代碼也是順序執行的。那么一旦程序出現問題，我們就可以把程序在出問題的點上分成兩部分，出問題之前的和出問題之后的。如果我們看到的結果是正確的，那么問題點應該在當前時間點后執行的代碼中，注意我說的是時間點的先后，不是源代碼物理位置上的先后。所以我們應該在那些代碼中去查找，并在恰當的位置設置斷點。前面提到的F10和F11也是這個意思的具體表現。這里再次強調這個思路的意思是，希望新手在遇到問題而困惑時這個思考的技巧可以幫助自己理順思路，而不是僅僅把F10和F11的作用看成是兩個按鍵對應的功能。 **四．給新手的建議** 好了，這篇博文大致就寫到這里，感覺談的內容對新手來說可能有點多了。這些方法和技巧在使用中我相信會對新手是有幫助的。但是任何方法的應用都需要一個逐步熟練的過程，就像人的成長一樣。所以新手也不能抱著一口吃成一個胖子的心理。務實的做好自己的工作，在實踐中逐步提高和進步才是正確的作法。另外也要對自己有信心。其實新手還是有不少優勢的，比如學習速度快，適應能力強，什么事情都有熱情去做或者愿意做，面對困難有沖擊力，這些都是長處。所以面對經驗缺乏，能力相對較差的（較差這個詞可能用得不好）情況用不著著急或者影響心情。總之盡力而為了就可以了，今天比昨天好，這次比上次好就行了。 **五．提問解答** 最后我解釋一下學習篇中被提問到的一個問題。學習篇中我提到讀一本書最好是用20到40分鐘能過一遍。有人提問做起來有困難，那么在此解釋一下。首先我知道的快速閱讀技巧有兩個。第一個是正統的快速閱讀法，據說斯大林用這個方法可以在四個小時內看完一本五百頁的書。通常的閱讀方法是用視力最清楚的那個點一次看一個字，快速閱讀方式是要求讀者用眼睛一次看一段字，比如：三個，七個之類的。這樣就會比通常的閱讀方法快三倍或者七倍。這個方法是需要練習才能掌握的。第二個方法實際上是一個技巧。那就是只閱讀每一段的第一句話和最后一句話，這個方法據說可以用10%的時間獲得50%的信息量。這個技巧我沒有試過，效果如何就不清楚了。其次，在讀計算機書時，可以用視線掃描文字，這個不是快速閱讀，這比快速閱讀還要快很多。然后用視線濾出敏感的詞匯，發現是重點的，感興趣的或者不懂的就停下來看一下。另外已有的開發經驗也至關重要。比如，閱讀ADO開發數據庫的書，我就直接用視線掃面書上的例子代碼，ADO的初始化也看了一下，然后關注使用的步驟和其中的方法名。其原因是在這之前我有用C++使用ODBC的開發經驗。另外需要注意這個方法對新手可能不太適用，因為新手經驗少，調試程序的能力有限。新手看懂代碼不等于能調通程序，所以新手一定要上機敲代碼試一下才算會。但是老手就不用了，足夠的開發經驗可以保證這類入門級的例子，看懂就能調通。所以開發經驗在讀書時也是有用的。另外一個需要澄清的問題是本系列的文字與任何培訓機構沒有任何關系。如果還有別的問題或者愿意交流的可以加入我的群：231233168。 下一篇還是討論解決問題的方面的內容，但是難度會增加很多，題目應該是問題解決篇（下）。這是針對有一定開發經驗的開發者的。