作者簡介：Peter Nixey，Ruby on Rails程序員，前計算機視覺學者、企業(yè)家，Clickpass公司CEO，YC孵化器的企業(yè)規(guī)劃導師，Brojure公司CTO。
作為一個開發(fā)者，最關(guān)心的不外乎提高自己的軟件開發(fā)水平。那要從何做起呢？積累技術(shù)知識（比如Node或者No-SQL）？死磕那些經(jīng)典的算法問題（比如氣泡排序或者網(wǎng)址縮短）？或者是打牢基礎(chǔ)？0
作為一個程序員你的價值不是由你知道什么來衡量的，而是由你能做出什么來衡量的。兩者看起來相似，但有著天壤之別。你的價值在于如何將項目不斷向前推進，并帶領(lǐng)團隊一起進步。15年的開發(fā)生涯中，我從未需要去實現(xiàn)一個氣泡排序算法或是網(wǎng)址縮短程序。我要做的是花成千上萬個小時來編寫和重構(gòu)賬戶管理工具、郵件系統(tǒng)，編輯套件、測試套件，整理業(yè)務(wù)邏輯，部署腳本、JS層，進行架構(gòu)分析以及文檔管理等等。這些才是真正有意義的東西，完成了這些我們才能邁上新臺階。
開發(fā)這些組件，就像搭建項目的一磚一瓦，需要花費幾百上千小時的努力來琢磨。它們組成了復雜的系統(tǒng)，但它們本身卻保持簡單。軟件之美就是“簡單”。這些年的經(jīng)驗讓我悟出的道理是，把時間花在編碼和重構(gòu)上，這比純粹靠“才華”和空想更能實現(xiàn)目標。
執(zhí)行、完成任務(wù)然后迭代，才能實現(xiàn)軟件開發(fā)“簡單和高效”的目標。深植于我們腦海深處的關(guān)于創(chuàng)業(yè)的宗旨，就是先構(gòu)建基礎(chǔ)，然后迭代。軟件開發(fā)亦是如此。先開發(fā)一個粗糙的版本，然后重構(gòu)、修補錯誤、精簡。要得到結(jié)果，你得老老實實去寫代碼！去執(zhí)行！
一些聰明的懶人，總是炫耀自己的才華，讓同齡人為之驚嘆。但一個公司這樣做是不能成功的，偉大的產(chǎn)品不會靠吹噓而來。公司要依靠的是那些起早貪黑、團結(jié)協(xié)作、踏實編碼的人。吹噓容易，實干不易，且行且珍惜。0
業(yè)界一直存在這樣的誤解：一個商業(yè)公司要完成偉大的產(chǎn)品，需要靠那些小圈子的名人怪咖?？稍诂F(xiàn)實生活中，這樣恃才傲物的一小部分人雖然在感興趣的方面有著驚人的才華，但與團隊相處很不融洽，工作起來也很不沉穩(wěn)。他們不僅沒有實際成果，自以為是的優(yōu)越感還會影響團隊的氛圍。他們總認為自己天賦異稟，想干才干，愛干才干，但他們影響了團隊，還會扭曲其他人的價值觀。
要成為真正偉大的開發(fā)者，應(yīng)該從實干做起，遵循以下準則。0
難以置信，在編程中這是如此簡單卻又如此重要的法則。清晰的函數(shù)命名，常常伴隨著清晰的邏輯實現(xiàn)。例如：
def process_text string
…
end
這樣的函數(shù)命名方式完全不能傳達出來函數(shù)的功能是什么。而：
def safe_convert_to_html string
……
end
這樣的函數(shù)命名方式，準確反映出了函數(shù)有且僅有什么作用。
除了“轉(zhuǎn)換文本到HTML”之外，可能有開發(fā)者愿意實現(xiàn)其它功能，例如自動嵌入視頻等，但通常這是不需要的。清晰規(guī)范的函數(shù)命名不僅能讓人一眼看出它能做什么，也能讓人知道它不能做什么。良好的命名規(guī)范可以提升代碼可讀性，讓代碼間關(guān)系更加清楚明白。不規(guī)范的命名，常常伴隨著混亂的代碼、BUG、糟糕的邏輯。
規(guī)范變量命名也同樣重要，例如：
if (u2.made < 10.minutes.ago)
&& !u2.tkn
……
這樣的命名方式很難讓人讀懂，即便讀懂了，也很難保證完全了解的作者的意圖。這個變量命名很糟糕，不能傳達任何信息。而且“并且不（&& !)”這樣的語句本來就非?；逎y懂，更別說在語句后面還跟著一個名詞了。如果有人要重構(gòu)這段代碼的話，恐怕需要先費盡腦子搞清楚原作者是在干什么。如果將變量命名規(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_tokenif user_is_recently_created
&& invitation_is_unsent
...
user_recently_created，這個變量命名實在是浪費時間來解釋顯而易見的東西。
就像DHH說的那樣，注釋是個麻煩的東西，一旦邏輯改變，注釋也要改變。如果代碼能好的反映自身邏輯，便不需要注釋。
via peter nixey
相關(guān)：
