如何成為一個偉大的開發者（一）

作者簡介：peter nixey，ruby on rails程式員，前計算機視覺學者、企業家，clickpass公司ceo，yc孵化器的企業規劃導師，brojure公司cto。

作為一個開發者，最關心的不外乎提高自己的軟體開發水準。那要從何做起呢？積累技術知識（比如node或者no-sql）？死磕那些經典的算法問題（比如氣泡排序或者網址縮短）？或者是打牢基礎？

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

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

執行、完成任務然後疊代，才能實作軟體開發“簡單和高效”的目标。深植于我們腦海深處的關于創業的宗旨，就是先建構基礎，然後疊代。軟體開發亦是如此。先開發一個粗糙的版本，然後重構、修補錯誤、精簡。要得到結果，你得老老實實去寫代碼！去執行！

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

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

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

規範的函數和變量命名

難以置信，在程式設計中這是如此簡單卻又如此重要的法則。清晰的函數命名，常常伴随着清晰的邏輯實作。例如：

這樣的函數命名方式，準确反映出了函數有且僅有什麼作用。

除了“轉換文本到html”之外，可能有開發者願意實作其它功能，例如自動嵌入視訊等，但通常這是不需要的。清晰規範的函數命名不僅能讓人一眼看出 它能做什麼，也能讓人知道它不能做什麼。良好的命名規範可以提升代碼可讀性，讓代碼間關系更加清楚明白。不規範的命名，常常伴随着混亂的代碼、bug、糟 糕的邏輯。

規範變量命名也同樣重要，例如：

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

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

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

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