我曾經(jīng)有一年一個(gè)人開(kāi)發(fā)一個(gè)富客戶端App，目前它已經(jīng)在盈利了。但我記得在剛開(kāi)始的時(shí)候我的技能就像生銹的鈍刀，主要是因?yàn)榇a的問(wèn)題，而這里我們僅僅討論代碼的問(wèn)題，架構(gòu)、結(jié)構(gòu)以及交互的問(wèn)題我們暫且都放一邊。

當(dāng)時(shí)我在這個(gè)項(xiàng)目上花了太多的時(shí)間，以至于很難抽出身來(lái)思考這個(gè)問(wèn)題——從另一個(gè)角度來(lái)看深埋在地下的設(shè)計(jì)缺陷。所以我的問(wèn)題就是我怎樣走出自己的局限，以新的的方式看待并讓它變得更好？我的幾個(gè)朋友給了我下面幾個(gè)建議：

一. 學(xué)習(xí)新語(yǔ)言或者程序庫(kù)

1. 找到一個(gè)有類(lèi)似技術(shù)問(wèn)題的人，然后跟他聊聊，個(gè)人開(kāi)發(fā)者團(tuán)隊(duì)用這個(gè)辦法是很有效的。
2. 先做下別的項(xiàng)目，也許一周過(guò)后你突然有了什么新點(diǎn)子。
3. 查看相似的項(xiàng)目或者產(chǎn)品，比如存在的開(kāi)源產(chǎn)品，但不要直接復(fù)制人家的代碼。
4. 學(xué)習(xí)一種新語(yǔ)言、程序庫(kù)或者框架，這些技術(shù)也許會(huì)讓你輕易洞察出你有困難的問(wèn)題，然后找到解決辦法。
5. 讀一本好的設(shè)計(jì)或者語(yǔ)言/架構(gòu)方面的書(shū)。

二. 大聲地把代碼讀出來(lái)

坐下來(lái)對(duì)一段代碼、一個(gè)模塊、一個(gè)特性自己大聲地朗讀和解讀，當(dāng)你發(fā)現(xiàn)你自己說(shuō)的聽(tīng)起來(lái)有問(wèn)題、很蠢，就把它記下來(lái)然后想辦法去解決。

三. 縮小范圍再找bug

看看你經(jīng)常修改的源代碼控制文件，哪一部分代碼是最難處理的，哪一部分代碼產(chǎn)生了最多的bug, 哪種類(lèi)型的變化會(huì)引起整個(gè)代碼的連鎖反應(yīng)，一旦縮小了范圍，你開(kāi)始尋找那里為什么會(huì)出問(wèn)題，然后可以看一些系統(tǒng)的分類(lèi)設(shè)計(jì)問(wèn)題的書(shū)，比如 Martin Fowler的Refactoring, Herb Sutter的C++ Coding Standards, Robert Martin的Clean Code 等。

當(dāng)然如果別人能幫你看下代碼更好，但總不如你自己想來(lái)的有用，因?yàn)槟惚热魏稳硕贾浪膯?wèn)題可能出現(xiàn)在哪里。

四. 跟用戶們交流一下

跟用戶們交流一下，然后看他們覺(jué)得哪里有問(wèn)題，不管是UX還是速度問(wèn)題，然后想著怎么讓這個(gè)系統(tǒng)更流暢，不管是API還是其他的測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，很多時(shí)候，你會(huì)發(fā)現(xiàn)只用把這些API放進(jìn)代碼，不用做很大的轉(zhuǎn)變。

Via arstechnica

譯文鏈接：http://www.leiphone.com/1224-keats-only-developer.html