最近，有兩位Google Maps API的初學(xué)者向我請(qǐng)教他們按照最簡單例子寫的程序?yàn)槭裁床荒苷５倪\(yùn)行。
其中一位用GTalk跟我交流，我仔細(xì)了看了他的代碼，沒看出問題，把代碼保存在本地，打開Firefox的錯(cuò)誤控制臺(tái)，用Firefox打開他的頁面。出錯(cuò)的那一行被清晰的顯示出來，我再仔細(xì)端詳那句話，原來有兩個(gè)應(yīng)該是英文逗號(hào)的地方，寫上了中文逗號(hào)。
另一位，在我的論壇跟我交流他的Google Maps API中遇到的問題，我看他代碼的時(shí)候也沒有馬上發(fā)現(xiàn)問題。然而，同樣在用Firefox打開后，問題很明顯的找到了，原來是一個(gè)方法openInfoWindow被他寫成OpenInfoWindow了。
在我?guī)椭鷦e人解決的程序調(diào)試問題中，這是非常常見的。人人都可能打出中文逗號(hào)，人人都可能把大小寫寫錯(cuò)。但是在我?guī)椭麄兘鉀Q問題以后，他們總是感慨的說，謝謝我解決了這個(gè)問題，這個(gè)問題困擾了他們幾個(gè)小時(shí)，甚至是幾天。
這其實(shí)并不是只有初學(xué)者才會(huì)遇到的問題，我還幫助過些有非常豐富經(jīng)驗(yàn)的工程師解決問題，有時(shí)候問題僅僅出自某個(gè)參數(shù)沒有傳遞進(jìn)來，或者是拼接字符串的時(shí)候少些了一個(gè)冒號(hào)，或者是拼接地址的時(shí)候漏掉了http:。我甚至幫助一些人調(diào)試一些我根本不懂的語言的程序，因?yàn)槎喟氤霈F(xiàn)的問題，都和語言特性無關(guān)，不是程序員寫錯(cuò)了字符，就是寫錯(cuò)了邏輯，或者是錯(cuò)誤理解了一個(gè)函數(shù)。
出問題是正常的，寫程序是一個(gè)復(fù)雜的邊思考邊打字的過程，筆誤和一時(shí)糊涂都是難以避免的。程序員一般把這種問題叫做低級(jí)問題，因?yàn)檫@類問題跟你的智商完全無關(guān)，任何人都可能犯。
但是，問題在于，有時(shí)候即使是很優(yōu)秀的程序員，也會(huì)被一個(gè)低級(jí)錯(cuò)誤困擾，可能會(huì)幾天都解決不了。所以，關(guān)鍵在于，如何找到問題。
遇到問題的時(shí)候：
1，不要怨天怨地。出了問題，當(dāng)然有可能是系統(tǒng)的bug，API的問題，但是那些幾率往往比你犯低級(jí)錯(cuò)誤的幾率要低多了，先從自己身上找原因，是不是自己寫錯(cuò)了。
2，要掌握工具。最低限度你要會(huì)寫Log，最好是Log和調(diào)試器結(jié)合。好 的工具可以大大的提高效率。以前有人跟我說，Dll不能調(diào)試，我發(fā)現(xiàn)可以；有人說多線程不能調(diào)試，我發(fā)現(xiàn)可以；有人說COM不能調(diào)試，我發(fā)現(xiàn)可以；有人說 IE插件不能調(diào)試，我發(fā)現(xiàn)可以；有人說OE插件不能調(diào)試，我發(fā)現(xiàn)也可以。當(dāng)然，你確實(shí)會(huì)遇到不能調(diào)試的時(shí)候，當(dāng)年我們做東芝芯片的嵌入程序，一個(gè)組都沒有 一個(gè)仿真器和調(diào)試器，但是至少可以用Log嘛，無非是麻煩點(diǎn)。
3，分析問題要有邏輯。遇到問題可以先把所有的可能性都列出來，然后一個(gè)一個(gè)分析，肯定能找到原因的。
4，要學(xué)會(huì)隔離問題。問題涉及到的代碼越多，越難以理解，問題越難以解決。遇到這樣的情況，可以利用Log或者調(diào)試器，一行代碼一行代碼的給它們洗清嫌疑，這樣很快你就可以找到出問題的地方。如果代碼特別長，程序特別復(fù)雜，可以用二分法來做，效率很高。
5，千萬不要懶惰，不要事事求別人。一次復(fù)雜的調(diào)試過程就像一部偵探劇，如果你有非常好的邏輯性，那這部劇的主角就是福爾摩斯，劇情一定非常精彩。我說這個(gè)是有巨大風(fēng)險(xiǎn)的，說真的我?guī)腿苏{(diào)東西挺上癮的，很有意思。但是我還是要告訴大家，一次高難度的調(diào)試之后，你的滿足感絕對(duì)不亞于寫了一個(gè)偉大的程序。
要想不遇到問題，寫代碼的時(shí)候：
1，要對(duì)寫出來的代碼負(fù)責(zé)。我很佩服那些寫代碼寫100行都不執(zhí)行一次的 高手，如果他們最后不被低級(jí)錯(cuò)誤困擾的話我就更加的佩服了。我寫程序幾乎是寫一行兩行就要執(zhí)行一次，每句話我都要確保執(zhí)行效果跟我的預(yù)期一致。沒錯(cuò)這樣寫的時(shí)候 可能慢一些，但是調(diào)試的時(shí)候很輕松，我可以很簡單的確定哪些代碼絕對(duì)沒有問題。所以我寫代碼整體速度比一般人高。很多人學(xué)習(xí)新東西的時(shí)候喜歡把例子抄一遍，運(yùn)行一下，改改，再運(yùn)行。我喜歡一句一句的抄例子，抄一句兩句執(zhí)行一次，這樣可以把例子透徹的理解，而且很難會(huì)遇到出現(xiàn)了問題找不到原因的時(shí)候。
2，函數(shù)體功能塊不要過長。我認(rèn)為我的智商并不高，我很難接受一個(gè)程序的一個(gè)函數(shù)體或者一個(gè)功能塊超越3屏（當(dāng)然邏輯真的有那么復(fù)雜除外，你會(huì)發(fā)現(xiàn)越是簡單的邏輯越是容易被人寫的冗長）。很多人對(duì)面向?qū)ο蠖炷茉?，?duì)封裝繼承看起來駕輕就熟。但是動(dòng)不動(dòng)就寫出來個(gè)函數(shù)體超長的程序。這就像寫本書從頭到尾不點(diǎn)句號(hào)一樣，會(huì)累死讀者的。自己看的時(shí)候，估計(jì)也會(huì)被累的喘不過來氣。這是我對(duì)基礎(chǔ)教育的微詞所在，他們連教會(huì)學(xué)生寫函數(shù)都沒教會(huì)，雖然表面上他們連面向?qū)ο筮@么高深的東西都教。
3，縮進(jìn)要對(duì)。這點(diǎn)很重要，雖然大部分語言不是像Python那樣用縮進(jìn)來決定邏輯塊的位置，但是人看到縮進(jìn)的時(shí)候，總是會(huì)以為這些縮進(jìn)位置跟邏輯相關(guān)。尤其是在有大量的ifelse或者for循環(huán)等等的嵌套邏輯的時(shí)候，如果縮進(jìn)錯(cuò)了，可能會(huì)直接讓人把程序的邏輯讀錯(cuò)。所以我拿到別人的代碼，第一件事情就是整理縮進(jìn)。我見過一些比較優(yōu)秀的頁面工程師，他們會(huì)在div結(jié)束的位置用注釋寫上這個(gè)div的id，這樣層級(jí)關(guān)系就一目了然了。
4，不斷重構(gòu)。隨著程序的不斷修改，有些部分會(huì)不斷的增長，原來看著清晰的架構(gòu)可能因?yàn)閱栴}的復(fù)雜而慢慢模糊，也可能被修正bug的權(quán)宜之計(jì)弄的面目全非。不信你找一個(gè)經(jīng)過多次修改的程序看看，是不是滿目瘡痍，是不是都很難認(rèn)出是你自己的作品了。這在多人參與的項(xiàng)目中更加嚴(yán)重，每個(gè)人有不同的代碼風(fēng)格，經(jīng)過多次雜交后，你肯定認(rèn)不出你的代碼是騾子是馬，還是四不像了。隨著程序的慢慢成長，原來有些函數(shù)體會(huì)慢慢膨脹，需要拆分；有些原來簡單的功能塊四處都需要，應(yīng)該被提煉成函數(shù)或者方法，等等。現(xiàn)在不重構(gòu)，未來等到代碼復(fù)雜到無法控制的時(shí)候，重構(gòu)的工作就會(huì)變得更加困難。我見過最強(qiáng)的案例是，一個(gè)幾千行的電子辭典配套聯(lián)機(jī)軟件，經(jīng)過無數(shù)次的改版，變成了一個(gè)幾乎無法維護(hù)的主窗體的cpp有1萬8千行的怪物。最后經(jīng)過復(fù)雜的重構(gòu)，才變成一個(gè)出新版本只需要新增一個(gè)驅(qū)動(dòng)程序的可以維護(hù)的幾千行的程序。
郝培強(qiáng)：銀杏技術(shù)咨詢創(chuàng)始合伙人，網(wǎng)名Tinyfool，技術(shù)方向是全文檢索，搜索引擎優(yōu)化，網(wǎng)站架構(gòu)設(shè)計(jì)等。 銀杏技術(shù)咨詢的主要業(yè)務(wù)是幫助客戶的網(wǎng)站改進(jìn)技術(shù)，提高網(wǎng)站性能和反應(yīng)速度，解決門檻性技術(shù)問題，從而提高用戶滿意度。
關(guān)于郝培強(qiáng)：www.yinxingtech.com/team.htm
關(guān)于銀杏技術(shù)咨詢：www.yinxingtech.com/
我就是初學(xué)者，我覺得講的很是有道理，轉(zhuǎn)到這里，大家共同看看。