如何成爲一個偉大的開發者（轉載）

做者簡介：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說的那樣，註釋是個麻煩的東西，一旦邏輯改變，註釋也要改變。若是代碼能好的反映自身邏輯，便不須要註釋。

 

積累——先求深，再求廣

程序員在開發過程當中，經常會遇到各類各樣的問題，但不多是徹底陌生、其它團隊也沒有遇到過的。在Stack Overflow上最吸引眼球的提問，大多曾在其它地方出現過。

多數時候，程序員所用的編程語言自己就自帶了解決方案。筆者曾經調用一個封裝好的內建函數，將一段60行代碼重構到1行。

重複造車輪般的過程去實現那些編程語言內建的函數不只浪費時間，也意味着程序的代碼將更冗長，還可能引入bug，須要更多的單元測試和註釋文檔。

好好打牢本身的基礎吧！若是你是一個ruby程序員，就好好學習Ruby豐富的數組方法；若是是Node開發者，就好好去理解node.js的架構；若是是Angular程序員，就去理解其內核背後的邏輯。在動手實現以前，先仔細查閱文檔。記住，咱們都站在巨人的肩膀上。把時間花去學習那些頂尖程序員的思路和方法，要正確的多。

培養對代碼的嗅覺

不少程序員水平不錯可是遇到了平臺期，問題經常出在他們不知道如何提高本身。這也許是技術生涯裏可以遇到的最糟糕的事情了。要想知道如何提高本身，首先得知道須要在哪方面有所提高。一個優秀的象棋手，老是會花時間研究其餘優秀棋手的路數，對於一個優秀的程序員來講，也是如此。

要想提高本身，最好的辦法莫過於培養對代碼的嗅覺。哪怕不能清楚地說出緣由，也能察覺到一段代碼的問題在哪裏。什麼是代碼嗅覺？好比讀到一段很難懂的代碼，會察覺到哪裏有問題。面對一個很基礎的功能，你會以爲語言自己應該有函數封裝。要培養對代碼的嗅覺，須要培養對代碼的審美水平。代碼之美，簡單優雅！

在開發的過程當中，應該力圖將代碼寫的簡單優雅。若是隻能用複雜醜陋的方法實現，那起碼要邏輯清晰。沒有對優雅和糟糕代碼的嗅覺，技術水平將難以提高。

提高代碼可讀性

Joel Spolsky曾經說過，Stack Exchange不只造福那些提問者，也造福那些看到提問的閱讀者。爲何？由於許多人遇到的問題都是類似的，這些類似的問題均可以參考這個解決方案進行處理，效用便最大化了。

程序員寫代碼時也應採用相似的策略。也許代碼僅由你本身寫，且只寫了一次，但它會被不少人閱讀、修改。因此，在寫代碼的時候，除了完成任務之外，還應力圖不給後來人形成麻煩。在開發過程當中，除了有良好的命名規範，還須要用嚴格的單元測試來保證代碼足夠耐用，經得起考驗。種因得果，設想一下，一年以後在徹底沒有耐心，時間又緊迫的狀況下，讓你來讀如今寫下的代碼，你理解那種心情吧！

重視產品的生命週期成本

新手開發者們熱衷探索和折騰。他們熱愛那些最新最閃亮的技術，無論是No-SQL數據庫仍是高併發的移動服務器，老是巴不得把全部新工具新特性所有使用起來，但這每每給後來的開發者留下一堆爛攤子。

功能和架構的選擇會影響到建於其上的一切。潛在的抽象泄露風險，引起的後果將不堪設想。除非你有足夠的理由，不然千萬不要使用那些尚處於測試中的功能。全部主要項目的開發，都應該當心翼翼。若是非要嘗試這些新特性，最好在那些輔助項目上嘗試，這樣保險得多。爲了未來不把大量的時間都用來彌補前期捅的婁子，要謹慎使用新特性。

理解技術負債

技術負債是指那些混亂糟糕，但還能工做的代碼。好比一個本應該用面向服務的架構，卻單獨開發了的APP；或者一個重構後只須要十分之一執行時間的Cron任務腳本。

技術負載不只會累加，還會帶來複合效應。愛因斯坦說過，「世界上最強大的力量是複利」。類比到軟件開發上，技術負載的複合效應也最具備毀滅性。多數開發者遭遇過這樣的項目：哪怕是一點輕微改變，都不得不花費幾個月的時間。這種狀況下，你會失去保持代碼整潔優雅的興趣和耐心，只求不要把整個服務弄崩掉。

技術負債還有一個特色是：你不須要償還。當開發的一個功能最後發現是錯誤的、不工做的，你會直接放棄它，同時也放棄全部的優化、測試及重構。因此，若是不是真正須要的話，那就不要去開發。將效用最大化，忽略錯誤。

技術負債，就像一個蛙跳遊戲。最初的代碼都只是嘗試，只要能實現目標快速推動就好。這讓咱們有足夠的時間來提出解決方案，足夠的空間來創建基礎設施。產品的生命週期越長，投入在基礎設施上的時間就越長。有了穩固可靠的基礎設施架構，才能支撐起一個高質量的產品。

總結並分享所完成的工做

無論用什麼樣的風格來註釋文檔，無論是用郵件仍是Wiki，必定要花時間記錄開發流程以及所用到的資料，並分享給其餘團隊成員。他們和你同樣，也會遇到各類安裝和調試的問題。軟件開發中，最使人頭疼的事情就是花費大量的時間來解決bug和安裝調試。若是你用一點時間來製做文檔或者教程的話，將爲團隊省下更多的寶貴時間。