對照檢查！高效程序員幾乎都有這七項技能

全文共 3037字，預計學習時長 6分鐘

圖片來源：pexels.com/@anastasiya-gepp-654466

軟件工程師們老是花費許多時間磨練面試技巧，如練習力扣題(leet code)和完善各自的簡歷。而一旦他們在一家新創企業、谷歌、亞馬遜、或其餘公司獲得了工做，也許就會發現，其實平常工做中用不到當初爲了獲得這份工做所得到的技能。

谷歌的TechLead提出了高效程序員該有的七項技能。本文受到啓發，提出高效程序員該有的七項技能。

1. 學習如何閱讀別人的代碼

可以閱讀其餘人的代碼是一個很厲害的技能，且能帶來許多好處。

無論上一個工程師的代碼有多亂有多糟，你仍是得讀懂它。這畢竟是你的工做。就算那些爛代碼是你一年前寫的。

這個技能有兩個好處。第一，學會如何閱讀其餘人的代碼可幫助你更瞭解什麼是糟糕的設計。在看過其餘人的代碼時，能夠學會看出代碼可不可用。更重要的是，也可從中得知哪些代碼更易被其餘工程師理解或否。

在閱讀其餘人的代碼時，儘量地對其評價。這樣，其餘工程師纔會知道眼前的工程師多麼的不簡單。

做出評價時，記得提起可維護代碼和清楚註釋的重要性。這將給編程領域裏的優點加分。

你自己的代碼應該設計得好，好到無需註釋。事實上，一個優秀的程序員本就不該該給本身代碼進行註釋。那只是在浪費時間，而寶貴的時間應該用在編碼和開會上。

學會閱讀其餘人雜亂的代碼也有助於必要時對其進行更新。這有時意味着更新你可能不那麼熟悉的代碼。舉個例子，咱們曾沿着一個腳本語言，編程語言從PowerShell換到Python，再改爲Perl。雖然咱們對Perl的經驗有限，可是任然有足夠的上下文來搞懂其中的代碼，並作出所需的更改。

這都歸功於咱們對全部代碼有必定的認識，以及閱讀Perl腳本的能力。

閱讀別人代碼這個技能可提高我的價值，由於就算是別人望而卻步的過分工程化的系統也難不倒你。

2. 感知爛項目

圖片來源：Chris Ried, Unsplash

許多技能都需花費時間來學習。其中一項技能是值得去獲取的，那就是知道哪些項目不值得去作，哪些項目顯然註定死路一條。

大企業是有不少進行中的項目，而其中可完成或有做用的卻很少。有些項目也許沒有任何商業意義（至少對你來講），也有一些項目就是沒管理好。這並不意味着當你對某個項目有異議時就直接拒絕。可是，若是股東們沒法清楚解釋項目用途時，那這個項目極可能不值得去作。

此外，一些項目也許過於專一在技術方面而忽略了尋找解決方案。所以，從一開始就可顯然看出不會有太大的做用。只有在接觸過不少爛項目後，方能獲得感知它們的技能。因此剛開始時不須要花太多時間去識別每一個項目。

在你職業生涯的某個階段，天然就會練就一種直覺。

3. 避開會議

不管軟件工程師仍是數據科學家，都必須參與會議，以確保能與項目經理、終端用戶和客戶達成共識。然而，參與太多會議反而會佔據一成天的工做時間。因此學會避免沒必要要參與的會議是很重要的。或者，「管理」一詞比「避免」會更好聽一些。這裏的目標是確保時間能用於參與推進決策的會議上，而且能幫助團隊前進。

最多見的方法就是天天留出兩個小時的時間，用來進行按期開會。一般多數人會在他們最方便的時候安排例常會議。這段時間即可用來了解所負責開發項目的最新狀況。

另外一種爲了完成工做而避開會議的方法就是比其餘人早報到。筆者們認爲，咱們喜歡早到的緣由是由於，總的來講，辦公室會比較清靜。多數早到的人也同樣，都想把工做作完，這樣就不會有人打擾了。

這對獨自工做者來講很重要，由於咱們的工做有一段時間須要極度專一，而不和其餘人交談。固然，有些時候也許得和別人合做來解決問題。可是一旦越過了障礙，剩下的只需編程。這時候就得進入狀態，在腦中不斷地思考有關手上項目的種種複雜想法。若是不停地被打斷，那就很難恢復狀態。

4. Github

有些計算機科學專業的學生從出生那天起就開始使用GitHub。他們可以理解每個指令和參數，能力甚至超越了教授們。

其餘人則是在第一份工做後第一次接觸到GitHub。對他們來講，GitHub是個充滿使人困惑的指令和程序的地獄。他們從不100%肯定本身在作什麼（這也就是爲何cheat sheet如此的受歡迎）。

無論公司用的是哪一種存儲庫系統，該系統只有在正確使用時纔有用；反之，則會成爲阻礙。一個簡單的push或者commit，和花數小時嘗試梳理亂成一團的分支，其實只有一線之差。除此以外，若是常常忘記提取存儲庫的最新版本，那也將面臨處理合並衝突的難題。

若是有須要保存GitHub的指令cheat sheet，那就保存起來。只要有幫助便可。

5. 編寫簡單且可維護的代碼

一般出現於資歷較淺工程師的一個問題就是，他們總試圖將全部所知的東西放到一個解決方案中。他們有一種渴望，想把所學到的面向對象編程、數據結構、設計模式和新技術通通用於所編寫的每一段代碼中。這反而造成了沒必要要的複雜性，由於你很容易過分依賴過去使用的解決方案或設計模式。

複雜的設計概念和簡單的代碼之間存在着一種平衡。總體上來講，設計模式和麪向對象的設計應該將代碼簡化。然而，當一個程序越被抽象化、歸納化、和黑箱化，則越難偵錯。

6. 懂得拒絕，學會分輕重緩急

這個技巧其實適用於任何職位，不管金融分析師仍是軟件工程師。但尤爲值得一提的是，每一個人彷佛都會由於某種緣由找技術性人員。若是你是數據工程師，處理開發管道外還可能會被要求作其餘東西。一些團隊也許須要數據提取，其餘則須要控制面板，更有一些須要新管道給他們的數據科學家。

其實，分輕重緩急和拒絕多是兩種不一樣的技能，但他們是緊密交織在一塊兒的。前者意味着只把時間花在對公司有重大影響的事情上。後者則意味着避免處理本應屬於其餘團隊的工做。這兩個技能的需求在全部職位中都是相互存在的。

這是一項很難掌握的技能，由於有時候面對別人請求的時候，會很難拒絕他們。尤爲是剛畢業的大學生，都會想盡可能知足全部人，手上也都是可完成的工做量。

在大企業裏，老是會有窮無止盡的工做要完成。關鍵在於扛下可完成的任務。

事實上不少技能都沒有在面試測試到，甚至在大學裏也沒有教過。一般，這更可能是環境的限制，而不是沒意願讓學生接觸真實開發環境下存在的問題。

7. 操做性設計思惟

有一項技能，面試中難以測試，大學課程裏又難以複製的，就是想透終端用戶使用軟件時會出錯的地方。咱們一般將此稱爲操做性場景思考。

然而，這其實只是一個較好聽的說法。事實上你只是在確保你的代碼連白癡也可使用。

例如，既然編碼大多都是在進行維護，這一般表明改編互相極度纏結的代碼。就連一個簡單的調整，都須要追蹤對象、方法、和/或API的全部可能關聯。不然，很容易意外地破壞以前沒注意到附加着的模塊。就算只是更改數據庫中的數據類型也是。

這也包括在進入開發階段前想透邊角案例和總體的高層設計。

而對於開發新模塊或微服務的更復雜案例，重要的是花點時間思考一下你手中任務的操做性場景。想想將來用戶將如何須要用到你的新模塊，他們將如何錯誤使用，什麼參數將被須要，以及是否有其餘時候將來程序員將會用到你的代碼。

純粹的代碼和編程只是問題的一部分。創造一個能夠在你電腦無缺運行的軟件並不難。但利用代碼時能夠出錯的地方卻不少。一旦投入生產，就很難說代碼將如何被使用，以及其餘代碼中哪些將會附加到原始代碼中。五年後，一個將來的程序員也許會由於你代碼的限制而感到煩躁也說不定呢。

留言 點贊 關注

咱們一塊兒分享AI學習與發展的乾貨
歡迎關注全平臺AI垂類自媒體 「讀芯術」

（添加小編微信：dxsxbb，加入讀者圈，一塊兒討論最新鮮的人工智能科技哦～）