高效程式設計師的 5 種角色

湯曉發表於2015-05-19

我認為一名高效程式設計師可以扮演5種基本角色來高效地完成他/她的工作,這些角色以某種方式組合後更符合開發團隊中的某些“人物”。你是其中的哪個(或哪些)角色?

編碼者

當我們在低層次積極參與編寫程式碼並解決問題時,我們所擔任的就是這樣一種角色。編碼者在程式設計同時致力於其他小問題,但通常專注於某一項特定任務而非整體架構。如果一個非IT人員詢問你工作,你告訴他們你是一名程式設計師,這就是他們想象中你整天所做的事。

調查者

我們想要理解一個系統需要如何工作時,我們就會擔負起這種角色。調查者不會讓事情有任何不明之處;她/他對事物的工作原理以及事物固定的行為方式的理解有著與生俱來的渴望。這種對程式碼工作原理理解的內在意願使得調研者成為優秀的捉蟲者

理論家

思考並解決抽象問題時,我們扮演這種角色。理論家善於將抽象問題分解成具體方案,並且善於構建系統架構,即使她/他不是非常善於實際用程式碼來實現這些方案和架構。

邏輯者

該角色允許我們有批判性和邏輯性地思考問題。邏輯者是這些角色中最善於分析的,他們會思考這段程式碼為何以某種方式執行,而不僅僅是程式碼如何執行。她/他能夠以同等權重來考慮所有可能的情況,並做出無偏見的決定,而不允許他/她的未經證實的觀點來影響他們的判斷。

溝通者

該角色允許我們與其他人交流並解釋複雜問題。溝通者能夠理解深奧的技術思想和策略,並向技術和非技術人員解釋清楚。她/他善於以多種方式溝通,無論是書寫(例如評論或文件),還是口頭表達(例如他/她的經理提出“這個按鈕是幹什麼的?”)。

在任何特定時間,所有的程式設計師都擔任過這五種角色,並且能夠按照意願在這些角色之間轉換。然而,在我看來能夠最大程度利用這五種角色的人非常少,實際上我們中大多數人會發現只有一種或兩種固有角色最適合我們。

例 如,你可能是一位優秀的邏輯者但卻不善溝通,正因為如此你也許能夠確定一段程式碼如何進行優化卻可能無法向你的老闆解釋為何這樣做很重要。同樣地,你也許是一位一流的編碼者但是一位糟糕的理論家,因此你在開始編寫程式碼解決問題前需要獲取該問題的詳細解釋。這裡有許多可能的組合,其中一些更為高效。

角色組合

何時可將這些基本角色組和成更加複雜的角色。也許你在職業生涯中已經遇到一個或多個扮演這些角色的人。在你的團隊中,有沒有一些這樣的人?你是這些人中的一員嗎?

編碼者 + 邏輯者 + 理論家 = 優化者

優化者是能夠快速有效提高程式碼質量的人,無論她/他是否編寫了最初的程式碼。他們是查詢哪裡存在或可能引起效能問題的專家,因為他們是一流編碼者,可能已經在一個框架或者另一個框架中實現過類似解決方案。當出現效能問題時,我們可以讓優化者來幫我們修復問題。

編碼者 + 調查者 + 溝通者 = 問題解決者

問題解決者是你在特定問題上需要幫助時可以求助的人。她擅長獲取一個給定問題並將其細分成許多組成部分使它們更易於獨立研究。問題解決者是專門幫助你修復bug和重構程式碼的人。

理論家 + 邏輯者 + 溝通者 = 架構師

架構師負責系統設計以滿足規定的要求。為完成系統設計,她能夠抽象思考並對比許多彼此不同的方案以尋得最優方案。她還要能夠向實際實現設計的程式設計師解釋她的架構。

上述角色源於一些角色的組合。我們可能還會發現一些效率低下的組合,通常是由於一個人忘記擔任一種或多種角色而導致。

理論家 + 編碼者 + 溝通者 – 邏輯者 = 空想架構師

空想架構師為解決方案設計了架構,但卻忽視了他的團隊要用程式碼來實際實現描述方案。他不能從長遠角度考慮或公正分析他的設計,他所謂的“完美”設計,一旦編寫後,往往最終陷入不可維護的混亂。

編碼者 + 邏輯者 – 溝通者 = 象牙塔開發者

象牙塔開發者善於依據自己的理解編寫程式碼。他得到一個問題後將自己鎖在象牙塔內,直到他“完善”了自己的方案時才出現,並且從為他的程式碼編寫文件。他也許很聰明,但他不能(或不願)將自己的才華與任何人分享,所以他的程式碼艱澀難懂,難以維護。

編碼者 + 理論家 – 調查者 – 邏輯者 = “我永遠沒錯”的開發者

“我永遠沒錯”的開發者不能或不願批判性地分析她自己的程式碼,因為他堅信程式碼是完美的,不需進行測試或研究。他的程式碼永遠不會出現bug,因此總是其他人的錯誤。

這些僅僅是一些我在職業生涯中遇到的組合。我見過各種不同水平的五種角色,這些角色組合深深吸引了我。你遇到哪些角色的組合?除這些外,是不是還有其他角色我遺漏了,可以加入到列表中?請在評論中告知!

相關文章