作者簡介：Peter Nixey，Ruby on Rails程序員，前計算機視覺學者、企業(yè)家，Clickpass公司CEO，YC孵化器的企業(yè)規(guī)劃導師，Brojure公司CTO。

作為一個開發(fā)者，最關心的不外乎提高自己的軟件開發(fā)水平。那要從何做起呢？積累技術知識（比如Node或者No-SQL）？死磕那些經(jīng)典的算法問題（比如氣泡排序或者網(wǎng)址縮短）？或者是打牢基礎？

作為一個程序員你的價值不是由你知道什么來衡量的，而是由你能做出什么來衡量的。兩者看起來相似，但有著天壤之別。你的價值在于如何將項目不斷向前推進，并帶領團隊一起進步。15年的開發(fā)生涯中，我從未需要去實現(xiàn)一個氣泡排序算法或是網(wǎng)址縮短程序。我要做的是花成千上萬個小時來編寫和重構賬戶管理工具、郵件系統(tǒng)，編輯套件、測試套件，整理業(yè)務邏輯，部署腳本、JS層，進行架構分析以及文檔管理等等。這些才是真正有意義的東西，完成了這些我們才能邁上新臺階。

開發(fā)這些組件，就像搭建項目的一磚一瓦，需要花費幾百上千小時的努力來琢磨。它們組成了復雜的系統(tǒng)，但它們本身卻保持簡單。軟件之美就是“簡單”。這些年的經(jīng)驗讓我悟出的道理是，把時間花在編碼和重構上，這比純粹靠“才華”和空想更能實現(xiàn)目標。

執(zhí)行、完成任務然后迭代，才能實現(xiàn)軟件開發(fā)“簡單和高效”的目標。深植于我們腦海深處的關于創(chuàng)業(yè)的宗旨，就是先構建基礎，然后迭代。軟件開發(fā)亦是如此。先開發(fā)一個粗糙的版本，然后重構、修補錯誤、精簡。要得到結果，你得老老實實去寫代碼！去執(zhí)行！

一些聰明的懶人，總是炫耀自己的才華，讓同齡人為之驚嘆。但一個公司這樣做是不能成功的，偉大的產品不會靠吹噓而來。公司要依靠的是那些起早貪黑、團結協(xié)作、踏實編碼的人。吹噓容易，實干不易，且行且珍惜。

業(yè)界一直存在這樣的誤解：一個商業(yè)公司要完成偉大的產品，需要靠那些小圈子的名人怪咖?？稍诂F(xiàn)實生活中，這樣恃才傲物的一小部分人雖然在感興趣的方面有著驚人的才華，但與團隊相處很不融洽，工作起來也很不沉穩(wěn)。他們不僅沒有實際成果，自以為是的優(yōu)越感還會影響團隊的氛圍。他們總認為自己天賦異稟，想干才干，愛干才干，但他們影響了團隊，還會扭曲其他人的價值觀。

要成為真正偉大的開發(fā)者，應該從實干做起，遵循以下準則。

規(guī)范的函數(shù)和變量命名

難以置信，在編程中這是如此簡單卻又如此重要的法則。清晰的函數(shù)命名，常常伴隨著清晰的邏輯實現(xiàn)。例如：

def process_text string

…

end

這樣的函數(shù)命名方式完全不能傳達出來函數(shù)的功能是什么。而：

def safe_convert_to_html string

……

end

這樣的函數(shù)命名方式，準確反映出了函數(shù)有且僅有什么作用。

除了“轉換文本到HTML”之外，可能有開發(fā)者愿意實現(xiàn)其它功能，例如自動嵌入視頻等，但通常這是不需要的。清晰規(guī)范的函數(shù)命名不僅能讓人一眼看出它能做什么，也能讓人知道它不能做什么。良好的命名規(guī)范可以提升代碼可讀性，讓代碼間關系更加清楚明白。不規(guī)范的命名，常常伴隨著混亂的代碼、BUG、糟糕的邏輯。

規(guī)范變量命名也同樣重要，例如：

if (u2.made < 10.minutes.ago)

&& !u2.tkn

……

這樣的命名方式很難讓人讀懂，即便讀懂了，也很難保證完全了解的作者的意圖。這個變量命名很糟糕，不能傳達任何信息。而且“并且不（&& !)”這樣的語句本來就非常晦澀難懂，更別說在語句后面還跟著一個名詞了。如果有人要重構這段代碼的話，恐怕需要先費盡腦子搞清楚原作者是在干什么。如果將變量命名規(guī)范化，情況會很不一樣。

if (new_user.created_at < 10.minutes.ago)

&& !new_user.invitation_token

……

當然，變量命名太過畫蛇添足也不行。例如我們將這段代碼，進一步注釋成這樣：

user_is_recently_created = user.created_at < 10.minutes.ago

invitation_is_unsent = !user.invitation_token

if user_is_recently_created

&& invitation_is_unsent

…

user_recently_created，這個變量命名實在是浪費時間來解釋顯而易見的東西。

就像DHH說的那樣，注釋是個麻煩的東西，一旦邏輯改變，注釋也要改變。如果代碼能好的反映自身邏輯，便不需要注釋。

積累——先求深，再求廣

程序員在開發(fā)過程中，常常會遇到各種各樣的問題，但很少是完全陌生、其它團隊也沒有遇到過的。在Stack Overflow上最吸引眼球的提問，大多曾在其它地方出現(xiàn)過。

多數(shù)時候，程序員所用的編程語言本身就自帶了解決方案。筆者曾經(jīng)調用一個封裝好的內建函數(shù)，將一段60行代碼重構到1行。

重復造車輪般的過程去實現(xiàn)那些編程語言內建的函數(shù)不僅浪費時間，也意味著程序的代碼將更冗長，還可能引入bug，需要更多的單元測試和注釋文檔。

好好打牢自己的基礎吧！如果你是一個ruby程序員，就好好學習Ruby豐富的數(shù)組方法；如果是Node開發(fā)者，就好好去理解node.js的架構；如果是Angular程序員，就去理解其內核背后的邏輯。在動手實現(xiàn)之前，先仔細查閱文檔。記住，我們都站在巨人的肩膀上。把時間花去學習那些頂尖程序員的思路和方法，要正確的多。

培養(yǎng)對代碼的嗅覺

很多程序員水平不錯但是遇到了平臺期，問題常常出在他們不知道如何提升自己。這也許是技術生涯里能夠遇到的最糟糕的事情了。要想知道如何提升自己，首先得知道需要在哪方面有所提升。一個優(yōu)秀的象棋手，總是會花時間研究其他優(yōu)秀棋手的路數(shù)，對于一個優(yōu)秀的程序員來說，也是如此。

要想提升自己，最好的辦法莫過于培養(yǎng)對代碼的嗅覺。哪怕不能清楚地說出原因，也能察覺到一段代碼的問題在哪里。什么是代碼嗅覺？比如讀到一段很難懂的代碼，會察覺到哪里有問題。面對一個很基礎的功能，你會覺得語言本身應該有函數(shù)封裝。要培養(yǎng)對代碼的嗅覺，需要培養(yǎng)對代碼的審美水平。代碼之美，簡單優(yōu)雅！

在開發(fā)的過程中，應該力圖將代碼寫的簡單優(yōu)雅。如果只能用復雜丑陋的方法實現(xiàn)，那起碼要邏輯清晰。沒有對優(yōu)雅和糟糕代碼的嗅覺，技術水平將難以提升。

提升代碼可讀性

Joel Spolsky曾經(jīng)說過，Stack Exchange不僅造福那些提問者，也造福那些看到提問的閱讀者。為什么？因為許多人遇到的問題都是相似的，這些相似的問題都可以參考這個解決方案進行處理，效用便最大化了。

程序員寫代碼時也應采用類似的策略。也許代碼僅由你自己寫，且只寫了一次，但它會被很多人閱讀、修改。所以，在寫代碼的時候，除了完成任務以外，還應力圖不給后來人造成麻煩。在開發(fā)過程中，除了有良好的命名規(guī)范，還需要用嚴格的單元測試來保證代碼足夠耐用，經(jīng)得起考驗。種因得果，設想一下，一年之后在完全沒有耐心，時間又緊迫的情況下，讓你來讀現(xiàn)在寫下的代碼，你理解那種心情吧！

重視產品的生命周期成本

新手開發(fā)者們熱衷探索和折騰。他們熱愛那些最新最閃亮的技術，不管是No-SQL數(shù)據(jù)庫還是高并發(fā)的移動服務器，總是恨不得把所有新工具新特性全部使用起來，但這往往給后來的開發(fā)者留下一堆爛攤子。

功能和架構的選擇會影響到建于其上的一切。潛在的抽象泄露風險，引發(fā)的后果將不堪設想。除非你有足夠的理由，否則千萬不要使用那些尚處于測試中的功能。所有主要項目的開發(fā)，都應該小心翼翼。如果非要嘗試這些新特性，最好在那些輔助項目上嘗試，這樣保險得多。為了將來不把大量的時間都用來彌補前期捅的婁子，要謹慎使用新特性。

理解技術負債

技術負債是指那些混亂糟糕，但還能工作的代碼。比如一個本應該用面向服務的架構，卻單獨開發(fā)了的APP；或者一個重構后只需要十分之一執(zhí)行時間的Cron任務腳本。

技術負載不僅會累加，還會帶來復合效應。愛因斯坦說過，“世界上最強大的力量是復利”。類比到軟件開發(fā)上，技術負載的復合效應也最具有毀滅性。多數(shù)開發(fā)者遭遇過這樣的項目：哪怕是一點輕微改變，都不得不花費幾個月的時間。這種情況下，你會失去保持代碼整潔優(yōu)雅的興趣和耐心，只求不要把整個服務弄崩掉。

技術負債還有一個特點是：你不需要償還。當開發(fā)的一個功能最后發(fā)現(xiàn)是錯誤的、不工作的，你會直接放棄它，同時也放棄所有的優(yōu)化、測試及重構。所以，如果不是真正需要的話，那就不要去開發(fā)。將效用最大化，忽略錯誤。

技術負債，就像一個蛙跳游戲。最初的代碼都只是嘗試，只要能實現(xiàn)目標快速推進就好。這讓我們有足夠的時間來提出解決方案，足夠的空間來建立基礎設施。產品的生命周期越長，投入在基礎設施上的時間就越長。有了穩(wěn)固可靠的基礎設施架構，才能支撐起一個高質量的產品。

總結并分享所完成的工作

不管用什么樣的風格來注釋文檔，不管是用郵件還是Wiki，一定要花時間記錄開發(fā)流程以及所用到的資料，并分享給其他團隊成員。他們和你一樣，也會遇到各種安裝和調試的問題。軟件開發(fā)中，最令人頭疼的事情就是花費大量的時間來解決bug和安裝調試。如果你用一點時間來制作文檔或者教程的話，將為團隊省下更多的寶貴時間。