如何成為一個偉大的開發者(一)

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

SONY DSC

作為一個開發者,最關心的不外乎提高自己的軟件開發水平。那要從何做起呢?積累技術知識(比如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說的那樣,註釋是個麻煩的東西,一旦邏輯改變,註釋也要改變。如果代碼能好的反映自身邏輯,便不需要註釋。

via peter nixey

相關:

今日鋒評:90分的創業者

Comments are closed.