最近，有兩位Google Maps API的初學者向我請教他們按照最簡單例子寫的程序為什么不能正常的運行。
其中一位用GTalk跟我交流，我仔細了看了他的代碼，沒看出問題，把代碼保存在本地，打開Firefox的錯誤控制臺，用Firefox打開他的頁面。出錯的那一行被清晰的顯示出來，我再仔細端詳那句話，原來有兩個應該是英文逗號的地方，寫上了中文逗號。
另一位，在我的論壇跟我交流他的Google Maps API中遇到的問題，我看他代碼的時候也沒有馬上發現問題。然而，同樣在用Firefox打開后，問題很明顯的找到了，原來是一個方法openInfoWindow被他寫成OpenInfoWindow了。
在我幫助別人解決的程序調試問題中，這是非常常見的。人人都可能打出中文逗號，人人都可能把大小寫寫錯。但是在我幫助他們解決問題以后，他們總是感慨的說，謝謝我解決了這個問題，這個問題困擾了他們幾個小時，甚至是幾天。
這其實并不是只有初學者才會遇到的問題，我還幫助過些有非常豐富經驗的工程師解決問題，有時候問題僅僅出自某個參數沒有傳遞進來，或者是拼接字符串的時候少些了一個冒號，或者是拼接地址的時候漏掉了http:。我甚至幫助一些人調試一些我根本不懂的語言的程序，因為多半出現的問題，都和語言特性無關，不是程序員寫錯了字符，就是寫錯了邏輯，或者是錯誤理解了一個函數。
出問題是正常的，寫程序是一個復雜的邊思考邊打字的過程，筆誤和一時糊涂都是難以避免的。程序員一般把這種問題叫做低級問題，因為這類問題跟你的智商完全無關，任何人都可能犯。
但是，問題在于，有時候即使是很優秀的程序員，也會被一個低級錯誤困擾，可能會幾天都解決不了。所以，關鍵在于，如何找到問題。
遇到問題的時候：
1，不要怨天怨地。出了問題，當然有可能是系統的bug，API的問題，但是那些幾率往往比你犯低級錯誤的幾率要低多了，先從自己身上找原因，是不是自己寫錯了。
2，要掌握工具。最低限度你要會寫Log，最好是Log和調試器結合。好 的工具可以大大的提高效率。以前有人跟我說，Dll不能調試，我發現可以；有人說多線程不能調試，我發現可以；有人說COM不能調試，我發現可以；有人說 IE插件不能調試，我發現可以；有人說OE插件不能調試，我發現也可以。當然，你確實會遇到不能調試的時候，當年我們做東芝芯片的嵌入程序，一個組都沒有 一個仿真器和調試器，但是至少可以用Log嘛，無非是麻煩點。
3，分析問題要有邏輯。遇到問題可以先把所有的可能性都列出來，然后一個一個分析，肯定能找到原因的。
4，要學會隔離問題。問題涉及到的代碼越多，越難以理解，問題越難以解決。遇到這樣的情況，可以利用Log或者調試器，一行代碼一行代碼的給它們洗清嫌疑，這樣很快你就可以找到出問題的地方。如果代碼特別長，程序特別復雜，可以用二分法來做，效率很高。
5，千萬不要懶惰，不要事事求別人。一次復雜的調試過程就像一部偵探劇，如果你有非常好的邏輯性，那這部劇的主角就是福爾摩斯，劇情一定非常精彩。我說這個是有巨大風險的，說真的我幫人調東西挺上癮的，很有意思。但是我還是要告訴大家，一次高難度的調試之后，你的滿足感絕對不亞于寫了一個偉大的程序。
要想不遇到問題，寫代碼的時候：
1，要對寫出來的代碼負責。我很佩服那些寫代碼寫100行都不執行一次的 高手，如果他們最后不被低級錯誤困擾的話我就更加的佩服了。我寫程序幾乎是寫一行兩行就要執行一次，每句話我都要確保執行效果跟我的預期一致。沒錯這樣寫的時候 可能慢一些，但是調試的時候很輕松，我可以很簡單的確定哪些代碼絕對沒有問題。所以我寫代碼整體速度比一般人高。很多人學習新東西的時候喜歡把例子抄一遍，運行一下，改改，再運行。我喜歡一句一句的抄例子，抄一句兩句執行一次，這樣可以把例子透徹的理解，而且很難會遇到出現了問題找不到原因的時候。
2，函數體功能塊不要過長。我認為我的智商并不高，我很難接受一個程序的一個函數體或者一個功能塊超越3屏（當然邏輯真的有那么復雜除外，你會發現越是簡單的邏輯越是容易被人寫的冗長）。很多人對面向對象耳熟能詳，對封裝繼承看起來駕輕就熟。但是動不動就寫出來個函數體超長的程序。這就像寫本書從頭到尾不點句號一樣，會累死讀者的。自己看的時候，估計也會被累的喘不過來氣。這是我對基礎教育的微詞所在，他們連教會學生寫函數都沒教會，雖然表面上他們連面向對象這么高深的東西都教。
3，縮進要對。這點很重要，雖然大部分語言不是像Python那樣用縮進來決定邏輯塊的位置，但是人看到縮進的時候，總是會以為這些縮進位置跟邏輯相關。尤其是在有大量的ifelse或者for循環等等的嵌套邏輯的時候，如果縮進錯了，可能會直接讓人把程序的邏輯讀錯。所以我拿到別人的代碼，第一件事情就是整理縮進。我見過一些比較優秀的頁面工程師，他們會在div結束的位置用注釋寫上這個div的id，這樣層級關系就一目了然了。
4，不斷重構。隨著程序的不斷修改，有些部分會不斷的增長，原來看著清晰的架構可能因為問題的復雜而慢慢模糊，也可能被修正bug的權宜之計弄的面目全非。不信你找一個經過多次修改的程序看看，是不是滿目瘡痍，是不是都很難認出是你自己的作品了。這在多人參與的項目中更加嚴重，每個人有不同的代碼風格，經過多次雜交后，你肯定認不出你的代碼是騾子是馬，還是四不像了。隨著程序的慢慢成長，原來有些函數體會慢慢膨脹，需要拆分；有些原來簡單的功能塊四處都需要，應該被提煉成函數或者方法，等等。現在不重構，未來等到代碼復雜到無法控制的時候，重構的工作就會變得更加困難。我見過最強的案例是，一個幾千行的電子辭典配套聯機軟件，經過無數次的改版，變成了一個幾乎無法維護的主窗體的cpp有1萬8千行的怪物。最后經過復雜的重構，才變成一個出新版本只需要新增一個驅動程序的可以維護的幾千行的程序。
|