如何成為一個傑出的開發者

「你是誰並不重要,重要的是你做了什麼」,電影《蝙蝠俠》裡這句台詞很適合用在軟體開發者身上。
評論
評論

本文轉自合作媒體雷鋒網 〈 如何成為一個偉大的開發者 〉,原文來自 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 說的那樣,註釋是個麻煩的東西,一旦邏輯改變,註釋也要改變。如果程式能好的反映自身邏輯,便不需要註釋。

累積——先求深,再求廣

工程師在開發過程中,常常會遇到各種各樣的問題,但很少是完全陌生、其它團隊也沒有遇到過的。在 Stack Overflow 上最吸睛的提問,大多曾在其它地方出現過。

多數時候,工程師所用的程式語言本身就帶有解決方案。筆者曾經調用一個封裝好的內建函數,將一段 60 行程式重構到 1 行。

重複造車輪般的過程去實踐那些程式語言內建的函數不僅浪費時間,也意味著程式將更冗長,還可能引入 bug,需要更多的單元測試和註釋文檔。

好好穩固自己的基礎吧!如果你是一個 ruby 工程師,就好好學習 Ruby 豐富的數組方法;如果是 Node 開發者,就好好去理解 node.js 的架構;如果是 Angular 工程師,就去理解其內核背後的邏輯。在動手實現之前,先仔細查閱文檔。記住,我們都站在巨人的肩膀上。把時間花去學習那些頂尖工程師的思路和方法,要正確的多。

培養對程式的嗅覺

很多工程師水準不錯但是遇到了撞牆期,問題常常出在他們不知道如何提升自己。這也許是技術生涯裡能夠遇到的最糟糕的事情了。要想知道如何提升自己,首先得知道需要在哪方面有所提升。一個優秀的象棋手,總是會花時間研究其他優秀棋手的路數,對於一個優秀的工程師來說,也是如此。

要想提升自己,最好的辦法莫過於培養對程式的嗅覺。哪怕不能清楚地說出原因,也能察覺到一段程式的問題在哪裡。什麼是程式嗅覺?比如讀到一段很難懂的程式,會察覺到哪裡有問題。面對一個很基礎的功能,你會覺得語言本身應該有函數封裝。要培養對程式的嗅覺,需要培養對程式的審美水準。程式之美,簡單優雅!

在開發的過程中,應該力圖將程式寫的簡單優雅。如果只能用複雜醜陋的方法實現,那起碼要邏輯清晰。沒有對優雅和糟糕程式的嗅覺,技術水準將難以提升。

提升程式可讀性

Joel Spolsky 曾經說過,Stack Exchange 不僅造福那些提問者,也造福那些看到提問的閱讀者。為什麼?因為許多人遇到的問題都是相似的,這些相似的問題都可以參考這個解決方案進行處理,效用便最大化了。

工程師寫程式時也應採用類似的策略。也許程式僅由你自己寫,且只寫了一次,但它會被很多人閱讀、修改。所以,在寫程式的時候,除了完成任務以外,還應力圖不給後來人造成麻煩。在開發過程中,除了有良好的命名規範,還需要用嚴格的單元測試來保證程式足夠耐用,經得起考驗。種因得果,設想一下,一年之後在完全沒有耐心,時間又緊迫的情況下,讓你來讀現在寫下的程式,你理解那種心情吧!

重視產品的生命週期成本

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

功能和架構的選擇會影響到建於其上的一切。潛在的抽象洩露風險,引發的後果將不堪設想。除非你有足夠的理由,否則千萬不要使用那些尚處於測試中的功能。所有主要專案的開發,都應該小心翼翼。如果非要嘗試這些新特性,最好在那些輔助專案上嘗試,這樣保險得多。為了將來不把大量的時間都用來彌補前期捅的婁子,要謹慎使用新特性。

理解技術負債

技術負債是指那些混亂糟糕,但還能工作的程式。比如一個本應該用面向服務的架構,卻單獨開發了的 APP;或者一個重構後只需要十分之一執行時間的 Cron 任務腳本。

技術負載不僅會累加,還會帶來複合效應。愛因斯坦說過,「世界上最強大的力量是複利」。類比到軟體開發上,技術負載的複合效應也最具有毀滅性。多數開發者遭遇過這樣的專案:哪怕是一點輕微改變,都不得不花費幾個月的時間。這種情況下,你會失去保持程式整潔優雅的興趣和耐心,只求不要搞壞整個服務。

技術負債還有一個特點是:你不需要償還。當開發的一個功能最後發現是錯誤的、不工作的,你會直接放棄它,同時也放棄所有的優化、測試及重構。所以,如果不是真正需要的話,那就不要去開發。將效用最大化,忽略錯誤。

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

總結並分享所完成的工作

不管用什麼樣的風格來註釋文檔,不管是用郵件還是 Wiki,一定要花時間記錄開發流程以及所用到的資料,並分享給其他團隊成員。他們和你一樣,也會遇到各種安裝和調試的

問題。軟體開發中,最令人頭疼的事情就是花費大量的時間來解決 bug 和安裝調試。如果你用一點時間來製作文檔或者教程的話,將為團隊省下更多的寶貴時間。

把握好測試的平衡

軟體開發中的測試活動是強有力的工具,它能讓你為產品發布做好準備。走過測試流程,新版本的發布對你來說應該是件信心滿滿的事,不會感到恐慌,新版本的發布也會進展的更快。經過的測試流程太少,有可能會出大亂子。當然,如果測試流程過頭了,你會變得綁手綁腳。

至於進行多少量的測試,沒有直接的答案。每個專案需要的測試總量和測試點都不同。在開發的過程中,我們應該下點功夫理解什麼部分是真正需要測試的,什麼時候測試才會產生價值。不要害怕進行測試,也不要害怕不進行測試,只要找到其中的平衡點就好。

讓團隊進步

你的存在,是讓你的團隊變得更好了?還是拖了團隊的後腿?你的程式品質、文檔和技術水平,是不是幫助周圍的人有所提升?你有沒有啟發和

鼓舞隊友,讓他們變得更好?或者,你是那個 Bug 製造者,浪費時間爭論無意義的架構問題,到最後沒有實際產出的人?

一個傑出的開發者,應該影響他周圍的人,讓團隊一起進步。

成果最重要

「你是誰並不重要,重要的是你做了什麼」,電影《蝙蝠俠》裡這句台詞很適合用在軟體開發者身上。

作為一個開發者,你有多聰明,了解多少技術知識並不能衡量你的能力。你的簡歷上,會寫你會什麼語言、在哪裡上的大學、在哪家公司工作過等等,這些只能顯示出你會什麼,能做什麼。但真正衡量你作為一個開發者的價值的是,你做了什麼,專案和團隊因你而改變了什麼!

via peter nixey


精選熱門好工作

客服消費爭議專員

樂購蝦皮股份有限公司
臺北市.台灣

獎勵 NT$20,000

Server Developer

PicCollage 拼貼趣
臺北市.台灣

獎勵 NT$20,000

PopDaily 資料分析師 –【行銷部】

數果網路股份有限公司
臺北市.台灣

獎勵 NT$20,000

評論