原文作者 Peter Nixey 為 Ruby on Rails 開發者，前計算機視覺學者、企業家，Clickpass 公司 CEO，YC 孵化器的企業規劃導師，新創公司 Brojure CTO。以下文字以作者第一人稱撰寫。
作為一個開發者，最關心的不外乎提高自己的軟體開發水平。那要從何做起呢？積累技術知識（比如 Node 或者 No-SQL）？死磕那些經典的算法問題（比如氣泡排序或者網址縮短）？或者是打牢基礎？
作為一個程式設計師，你的價值不是由你知道什麼來衡量的，而是由你能做出什麼來衡量的。
兩者看起來相似，但有著天壤之別。你的價值在於如何將項目不斷向前推進，並帶領團隊一起進步。15 年的開發生涯中，我從未需要去實現一個氣泡排序算法或是網址縮短程序。
我要做的是花成千上萬個小時來編寫和重構賬戶管理工具、郵件系統，編輯套件、測試套件，整理業務邏輯，部署腳本、JS 層，進行架構分析以及文檔管理等等。這些才是真正有意義的東西，完成了這些我們才能邁上新台階。
開發這些組件，就像搭建項目的一磚一瓦，需要花費幾百上千小時的努力來琢磨。它們組成了複雜的系統，但它們本身卻保持簡單。軟體之美就是「簡單」。
- 偉大的產品不會靠吹噓而來，公司要依靠的是那些踏實 Coding 的人
這些年的經驗讓我悟出的道理是，把時間花在編碼和重構上，這比純粹靠「才華」和空想更能實現目標。
執行、完成任務然後迭代，才能實現軟體開發「簡單和高效」的目標。深植於我們腦海深處的關於創業的宗旨，就是先構建基礎，然後迭代。軟體開發亦是如此。先開發一個粗糙的版本，然後重構、修補錯誤、精簡。要得到結果，你得老老實實去寫 Code！去執行！
一些聰明的懶人，總是炫耀自己的才華，讓同齡人為之驚嘆。但一個公司這樣做是不能成功的，偉大的產品不會靠吹噓而來。公司要依靠的是那些早起、團結協作、踏實 Coding 的人。吹噓容易，實幹不易，且行且珍惜。
業界一直存在這樣的誤解：一個商業公司要完成偉大的產品，需要靠那些小圈子的名人怪咖。
可在現實生活中，這樣恃才傲物的一小部分人雖然在感興趣的方面有著驚人的才華，但與團隊相處很不融洽，工作起來也很不沉穩。他們不僅沒有實際成果，自以為是的優越感還會影響團隊的氛圍。他們總認為自己天賦異禀，想幹才幹，愛幹才幹，但他們影響了團隊，還會扭曲其他人的價值觀。
要成為真正偉大的開發者，應該從實幹做起，遵循以下準則。
- 規範的函數和變量命名
難以置信，在編程中這是如此簡單卻又如此重要的法則。清晰的函數命名，常常伴隨著清晰的邏輯實現。例如：
def process_text string
…
end
這樣的函數命名方式完全不能傳達出來函數的功能是什麼。而：
def safe_convert_to_html string
……
end
這樣的函數命名方式，準確反映出了函數有且僅有什麼作用。
除了「轉換文本到 HTML」之外，可能有開發者願意實現其它功能，例如自動嵌入視頻等，但通常這是不需要的。
清晰規範的函數命名不僅能讓人一眼看出它能做什麼，也能讓人知道它不能做什麼。良好的命名規範可以提升 Code 可讀性，讓 Code 間關係更加清楚明白。不規範的命名，常常伴隨著混亂的代碼、BUG、糟糕的邏輯。
規範變量命名也同樣重要，例如：
if (u2.made < 10.minutes.ago)
&& !u2.tkn
……
這樣的命名方式很難讓人讀懂，即便讀懂了，也很難保證完全了解的作者的意圖。
這個變量命名很糟糕，不能傳達任何訊息。而且「並且不（&& !)」這樣的語句本來就非常晦澀難懂，更別說在語句後面還跟著一個名詞了。如果有人要重構這段 Code 的話，恐怕需要先費盡腦子搞清楚原作者是在幹什麼。如果將變量命名規範化，情況會很不一樣。
if (new_user.created_at < 10.minutes.ago)
&& !new_user.invitation_token……
當然，變量命名太過畫蛇添足也不行。例如我們將這段 Code，進一步註釋成這樣：
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 說的那樣，註釋是個麻煩的東西，一旦邏輯改變，註釋也要改變。如果 Code 能好的反映自身邏輯，便不需要註釋。
- 積累 —— 先求深，再求廣
程式設計師在開發過程中，常常會遇到各種各樣的問題，但很少是完全陌生、其它團隊也沒有遇到過的。在 Stack Overflow 上最吸引目光的提問，大多曾在其它地方出現過。
多數時候，開發者所用的程式語言本身就自帶了解決方案。筆者曾經調用一個封裝好的內建函數，將一段 60 行 Code 重構到 1 行。
重複造車輪般的過程去實現那些程式語言內建的函數不僅浪費時間，也意味著程式的 Code 將更冗長，還可能引入 bug，需要更多的單元測試和註釋文檔。
好好打牢自己的基礎吧！如果你是一個 Ruby 程序員，就好好學習 Ruby 豐富的數組方法；如果是 Node 開發者，就好好去理解 node.js 的架構；如果是 Angular 程式設計師，就去理解其內核背後的邏輯。
在動手實現之前，先仔細查閱文檔。記住，我們都站在巨人的肩膀上。把時間花去學習那些頂尖程式設計師的思路和方法，要正確的多。
- 培養對 Code 的嗅覺
很多程式設計水平不錯但是遇到了平台期，問題常常出在他們不知道如何提升自己。這也許是技術生涯裡能夠遇到的最糟糕的事情了。要想知道如何提升自己，首先得知道需要在哪方面有所提升。一個優秀的象棋手，總是會花時間研究其他優秀棋手的路數，對於一個優秀的程式設計來說，也是如此。
要想提升自己，最好的辦法莫過於培養對 Code 的嗅覺。哪怕不能清楚地說出原因，也能察覺到一段 Code 的問題在哪裡。什麼是 Code 嗅覺？
比如讀到一段很難懂的 Code ，會察覺到哪裡有問題。面對一個很基礎的功能，你會覺得語言本身應該有函數封裝。要培養對 Code 的嗅覺，需要培養對 Code 的審美水平。 Code 之美，簡單優雅！
在開發的過程中，應該力圖將 Code 寫的簡單優雅。如果只能用複雜醜陋的方法實現，那起碼要邏輯清晰。沒有對優雅和糟糕 Code 的嗅覺，技術水平將難以提升。
- 提升 Code 可讀性
Joel Spolsky 曾經說過，Stack Exchange 不僅造福那些提問者，也造福那些看到提問的閱讀者。為什麼？因為許多人遇到的問題都是相似的，這些相似的問題都可以參考這個解決方案進行處理，效用便最大化了。
程式設計師 寫 Code 時也應採用類似的策略。
也許 Code 僅由你自己，且只寫了一次，但它會被很多人閱讀、修改。所以，在寫 Code 的時候，除了完成任務以外，還應力圖不給後來人造成麻煩。在開發過程中，除了有良好的命名規範，還需要用嚴格的單元測試來保證 Code 足夠耐用，經得起考驗。
種因得果，設想一下，一年之後在完全沒有耐心，時間又緊迫的情況下，讓你來讀現在寫下的 Code，你理解那種心情吧！
-
重視產品的生命週期成本
新手開發者們熱衷探索和折騰。他們熱愛那些最新最閃亮的技術，不管是 No-SQL 數據庫還是高並發的移動服務器，總是恨不得把所有新工具新特性全部使用起來，但這往往給後來的開發者留下一堆爛攤子。
功能和架構的選擇會影響到建於其上的一切。
潛在的抽象洩露風險，引發的後果將不堪設想。除非你有足夠的理由，否則千萬不要使用那些尚處於測試中的功能。所有主要項目的開發，都應該小心翼翼。如果非要嘗試這些新特性，最好在那些輔助項目上嘗試，這樣保險得多。為了將來不把大量的時間都用來彌補前期捅的婁子，要謹慎使用新特性。
- 理解「技術負債」
技術負債是指那些混亂糟糕，但還能工作的 Code。比如一個本應該用面向服務的架構，卻單獨開發了的 APP；或者一個重構後只需要十分之一執行時間的 Cron 任務腳本。
技術負載不僅會累加，還會帶來複合效應。
愛因斯坦說過，「世界上最強大的力量是複利」。類比到軟體開發上，技術負載的複合效應也最具有毀滅性。多數開發者遭遇過這樣的項目：哪怕是一點輕微改變，都不得不花費幾個月的時間。這種情況下，你會失去保持 Code 整潔優雅的興趣和耐心，只求不要把整個服務弄崩掉。
技術負債還有一個特點是：你不需要償還。當開發的一個功能最後發現是錯誤的、不工作的，你會直接放棄它，同時也放棄所有的優化、測試及重構。所以，如果不是真正需要的話，那就不要去開發。將效用最大化，忽略錯誤。
技術負債，就像一個蛙跳遊戲。最初的 Code 都只是嘗試，只要能實現目標快速推進就好。這讓我們有足夠的時間來提出解決方案，足夠的空間來建立基礎設施。產品的生命週期越長，投入在基礎設施上的時間就越長。有了穩固可靠的基礎設施架構，才能支撐起一個高質量的產品。
- 總結並分享所完成的工作
不管用什麼樣的風格來註釋文檔，不管是用郵件還是 Wiki，一定要花時間記錄開發流程以及所用到的資料，並分享給其他團隊成員。他們和你一樣，也會遇到各種安裝和調試的問題。
軟體開發中，最令人頭疼的事情就是花費大量的時間來解決 bug 和安裝調試。如果你用一點時間來製作文檔或者教程的話，將為團隊省下更多的寶貴時間。
- 把握好測試的平衡
軟體開發中的測試活動是強有力的工具，它能讓你為產品發布做好準備。走過測試流程，新版本的發布對你來說應該是件信心滿滿的事，不會感到恐慌，新版本的發布也會進展的更快。經過的測試流程太少，有可能會出大亂子。當然，如果測試流程過頭了，你會變得束手束腳。
至於進行多少量的測試，沒有直接的答案。每個項目需要的測試總量和測試點都不同。在開發的過程中，我們應該下點功夫理解什麼部分是真正需要測試的，什麼時候測試才會產生價值。不要害怕進行測試，也不要害怕不進行測試，只要找到其中的平衡點就好。
- 讓團隊進步
你的存在，是讓你的團隊變得更好了？還是拖了團隊的後腿？你的 Coding 質量、文檔和技術水平，是不是幫助周圍的人有所提升？你有沒有啟發和鼓舞隊友，讓他們變得更好？或者，你是那個 Bug 製造者，浪費時間爭論無意義的架構問題，到最後沒有實際產出的人？
一個偉大的開發者，應該影響他周圍的人，讓團隊一起進步。
- 成果最重要
「你是誰並不重要，重要的是你做了什麼」，電影《蝙蝠俠》裡這句台詞能很好的用在軟體開發者身上。
作為一個開發者，你有多聰明，了解多少技術知識並不能衡量你的能力。你的簡歷上，會寫你會什麼語言、在哪裡上的大學、在哪家公司工作過等等，這些只能顯示出你會什麼，能做什麼。
但真正衡量你作為一個開發者的價值的是，你做了什麼，項目和團隊因你而改變了什麼！
延伸閱讀：
【台灣工程師的矽谷故事】同工不同酬，年薪 50 萬美金的工程師到底有什麼神本事？
是什麼讓一位只有高中文憑的人，也能進 Google 當工程師？
（轉載自合作媒體《雷鋒網》）
Source: techorange.com
