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

        英文原文：How to be a great software developer

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

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

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

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

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

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

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

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

        規范的函數和變量命名

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

def process_text string

…

end

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

def safe_convert_to_html string

……

end

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

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

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

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

&& !u2.tkn

……

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

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 說的那樣，注釋是個麻煩的東西，一旦邏輯改變，注釋也要改變。如果代碼能好的反映自身邏輯，便不需要注釋。

                    <span id="shareA4" class="fl">                          </span> 

</div>