首頁»程序人生»Redis之父:10x程序員應該具備哪些素質

Redis之父:10x程序員應該具備哪些素質

來源:infoq 發布時間:2017-04-05 閱讀次數:

  Fred Brooks(《人月神話》的作者)最早在他的論文“沒有銀彈——軟件工程的本質和偶然性(No Silver Bullet - Essence and Accidents of Software Engineering)”中提出了“10x程序員”的概念。技術社區對于這個概念呈現出兩級分化的觀點。Redis之父Salvatore Sanfilippo(antirez)列出了9種特質,他認為,如果一個程序員同時具備了這9種特質,那么就可以說他是一個10x程序員。以下內容已獲得antirez的翻譯授權,查看英文原文The mythical 10x programmer

  一個10x程序員,在相同條件下,可以完成十倍于普通程序員的工作。這里所說的“普通程序員”,是指那些能夠勝任自己工作的程序員,只是他們不具備10x程序員的神奇能力。普通程序員代表了這個領域所有專業程序員的平均水準。

  對于是否存在10x程序員這種“神獸”,編程社區的觀點呈現出兩級分化:有人認為根本不存在所謂的10x程序員,有人則認為不僅存在10x程序員,如果找對了門路,甚至能找到100x的程序員。

  如果說編程是一項“線性”的工作,那么很明顯,10x程序員是不可能存在的。一個跑步運動員怎么可能跑得比另一個快上十倍?在相同時間內,一個建筑工人建造的東西怎么可能是其他人的十倍?不過,編程是一項很特別的設計工作。雖然程序員可能不會參與程序的架構設計,但程序的實現仍然涉及到一些設計工作,而這部分需要程序員去完成。

  如果說程序的設計和實現不是線性的,那么在我看來,經驗、編碼能力、知識和去偽存真的能力就不僅僅是線性的優勢,它們在編程過程中相互交織,成倍地發揮效能。當然,如果程序員能夠同時勝任設計和實現工作,那么這種現象就尤為明顯。任務越是具有目標導向性,程序員就越是能夠以更少的付出達成相同的目標,從而體現10x程序員的潛在能力。如果手頭的工作很死板,而且限定了可使用的工具和實現方式,那么10x程序員事半功倍的能力就會大打折扣。不過,在不改變大前提的情況下,程序員仍然可能通過局部的設計優化來改進工作,包括在項目的某些部分不按常理出牌。所以,他們可以少付出很多卻能達成幾乎相同的目標。

  在我的二十年程序員生涯中,我與其他程序員一起工作,作為同事,或者由我指導他們達成目標,為Redis和其他項目貢獻代碼補丁。在工作過程中,我仔細觀察他們。與此同時,有很多人說我是一個高能的程序員。不過我不認為自己是一個工作狂,我只是編碼速度比較快而已。

  下面列出了我認為可以用于區分程序員生產力高低的重要特質。

  編程裸技能:完成子任務

  從處理編程子任務可以看出一個程序員的短板和長處,比如實現一個函數或者一個算法。但從我的經驗來看,擅于應用基本的編程技能來高效完成任務的程序員并非如人們所想得那樣普遍存在。有時候,團隊里有些不是很稱職的程序員,他們甚至不知道該怎么寫一個簡單的排序算法,但比起那些看似稱職卻缺乏實戰經驗的程序員,這些不稱職的程序員卻能完成更多的工作。

  經驗:模式匹配

  我認為,經驗就是一系列解決方案,它們已經被證實可以用于處理一些重復性的任務。經驗老道的程序員知道該如何處理各種子任務,這樣不但省掉了很多設計工作,而且避免了很多設計錯誤,而設計錯誤是簡潔性最大的敵人。

  專注:實際時間和假設時間

  花在編碼上的時間不僅要看數量,也要看質量。造成注意力不集中的因素既有內部的,也有外部的。內部的因素包括拖延、對手頭的項目不感興趣(一個人總是做不好自己不喜歡的事情)、缺乏練習、缺乏睡眠。外部因素包括頻繁的會議、不固定的工作環境、同事的打擾,等等。集中注意力和避免被打擾對于提高編程效率來說是至關重要的。有時候,為了集中注意力,需要采取一些極端的手段。例如,我會時不時地查看郵件,但大部分郵件先不做回復。

  設計權衡:用5%換取90%

  項目的非根本性目標在很大程度上導致了設計的復雜性,或者導致無法達成其他更重要的目標,因為根本性功能和非根本性功能在設計上存在競爭關系。如果意識不到這點,復雜性就會隨之而來。實現全面的設計并不是件輕而易舉的事,付出與回報之間不能通過簡單的比例來衡量。對于設計者來說,意識到這一點是很重要的。如果項目要最大化產出,那么就要把精力集中在重要的事情上,并在合理的時間內完成。例如,在設計Disque(一個分布式消息隊列)時,我發現對消息進行排序之后,項目的其他方面就會得到實質性的改進:可用性、查詢和客戶端交互、簡潔性和性能。

  簡潔性

  簡潔性是成敗之間最為明顯的分界點。理解復雜性的產生過程有助于理解什么是簡潔性。我認為,不愿意做出設計權衡和設計錯誤的累積是導致復雜性的兩個主要因素。

  在設計過程中,每次走錯一條道,就離最優的方案越來越遠。一個初始的設計錯誤,如果沒能被糾正過來,那么可能導致一條道走到黑,最終得到的是一個復雜的系統,而不是對原先系統的重新設計。項目會因此變得更加復雜和低效。

  程序員可以在腦子里進行“概念驗證”,從大量簡單的設計想法中選擇可行性最高且最直接的方案,從而達成簡潔性。在后續的改進工作中,個人的經驗和設計能力開始發揮作用,為子任務找到更加明智的解決方案。

  不過,如果系統復雜性不可避免,那么在放棄掙扎之前也要盡量想辦法降低系統復雜性,甚至嘗試采取完全相反的設計。

  完美主義(為了偏袒設計而放棄生產力)

  完美主義可以分為兩種:一種是追求程序極致性能的工程文化,另一種是個人特質。不管是哪一種完美主義,它們都會對程序員實現快速交付造成阻礙。完美主義和對外部評判的恐懼會導致設計上的偏袒,程序員根據主觀的心理因素和無關緊要的衡量參數做出設計決策,卻忽略了健壯性、簡潔性和及時交付。

  知識:理論有益

  在處理復雜任務時,具備一些理論方面的知識會對設計產生重要影響,比如數據結構方面的知識、了解計算能力的局限性和一些重要的算法。我們沒有必要成為無所不知的超級專家,但至少要知道一些問題的潛在解決方案。例如,在給一個給定流統計單一元素的個數時,我們可以在設計上做出權衡(接受一定程度的錯誤),并結合概率集合的基數估計(cardinality estimation)算法,避免設計出復雜、緩慢、低內存效能的解決方案。

  底層:理解機器原理

  程序的很多問題都是源于對計算機工作原理的誤解,即使是使用高級語言開發的程序也不外乎如此。這種情況可能導致一個項目需要重新設計和實現,因為項目所使用的工具和算法出現了根本性的錯誤。精通C語言,知道CPU的工作原理,了解系統內核的行為以及系統調用的實現原理,做到這幾點可以挽救你于危難之中。

  調試技能

  查找和解決bug經常會占用我們大量的時間。查找引起bug的問題根源,在合理的步驟內修復bug,以簡單的方式編寫包含較少bug的代碼,對于程序員來說,做到這幾點可以顯著提升效率。

  一個程序員如果具備了上述幾點特質,那么他們的產出將會有10倍的提升,對此我一點也不感到驚訝。綜合這些特質,從一個可行的模型開始,實現更簡單更好的設計。我認為簡潔性就是一種“投機取巧的編程”。簡而言之,就是在開發的每個階段選擇性地實現一些功能,以最小化的付出為用戶帶來最大化的影響。

QQ群:WEB開發者官方群(515171538),驗證消息:10000
微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
網友評論(共0條評論) 正在載入評論......
理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
登錄會員中心
6十1选号器