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

[[273326]]

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

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

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

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

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

在閱讀其他人的代碼時，盡可能地對其評價。這樣，其他工程師才會知道眼前的工程師多么的不簡單。

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

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

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

這都歸功于我們對所有代碼有一定的認識，以及閱讀Perl腳本的能力。

閱讀別人代碼這個技能可提升個人價值，因為就算是別人望而卻步的過度工程化的系統也難不倒你。

2. 感知爛項目

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

大企業總是有很多進行中的項目，而其中可完成或有作用的卻不多。有些項目也許沒有任何商業意義(至少對你來說)，也有一些項目就是沒管理好。這并不意味著當你對某個項目有異議時就直接拒絕。但是，如果股東們無法清楚解釋項目用途時，那這個項目很可能不值得去做。

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

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

3. 避開會議

無論軟件工程師還是數據科學家，都必須參與會議，以確保能與項目經理、終端用戶和客戶達成共識。然而，參與太多會議反而會占據一整天的工作時間。所以學會避免不必要參與的會議是很重要的。或者，“管理”一詞比“避免”會更好聽一些。這里的目標是確保時間能用于參與推動決策的會議上，并且能幫助團隊前進。

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

另一種為了完成工作而避開會議的方法就是比其他人早報到。筆者們認為，我們喜歡早到的原因是因為，總的來說，辦公室會比較清靜。多數早到的人也一樣，都想把工作做完，這樣就不會有人打擾了。

這對獨自工作者來說很重要，因為我們的工作有一段時間需要極度專注，而不和其他人交談。當然，有些時候也許得和別人合作來解決問題。但是一旦越過了障礙，剩下的只需編程。這時候就得進入狀態，在腦中不斷地思考有關手上項目的種種復雜想法。如果不停地被打斷，那就很難恢復狀態。

4. Github

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

其他人則是在第一份工作后第一次接觸到GitHub。對他們來說，GitHub是個充滿令人困惑的指令和程序的地獄。他們從不100%確定自己在做什么(這也就是為什么cheat sheet如此的受歡迎)。

不管公司用的是哪種存儲庫系統，該系統只有在正確使用時才有用;反之，則會成為阻礙。一個簡單的push或者commit，和花數小時嘗試梳理亂成一團的分支，其實只有一線之差。除此之外，如果經常忘記提取存儲庫的最新版本，那也將面臨處理合并沖突的難題。

如果有需要保存GitHub的指令cheat sheet，那就保存起來。只要有幫助即可。

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

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

復雜的設計概念和簡單的代碼之間存在著一種平衡。整體上來說，設計模式和面向對象的設計應該將代碼簡化。然而，當一個程序越被抽象化、概括化、和黑箱化，則越難偵錯。

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

這個技巧其實適用于任何職位，無論金融分析師還是軟件工程師。但尤其值得一提的是，每個人似乎都會因為某種原因找技術性人員。如果你是數據工程師，處理開發管道外還可能會被要求做其他東西。一些團隊也許需要數據提取，其他則需要控制面板，更有一些需要新管道給他們的數據科學家。

其實，分輕重緩急和拒絕可能是兩種不同的技能，但他們是緊密交織在一起的。前者意味著只把時間花在對公司有重大影響的事情上。后者則意味著避免處理本應屬于其他團隊的工作。這兩個技能的需求在所有職位中都是相互存在的。

這是一項很難掌握的技能，因為有時候面對別人請求的時候，會很難拒絕他們。尤其是剛畢業的大學生，都會想盡量滿足所有人，手上也都是可完成的工作量。

在大企業里，總是會有窮無止盡的工作要完成。關鍵在于扛下可完成的任務。

事實上很多技能都沒有在面試測試到，甚至在大學里也沒有教過。通常，這更多是環境的限制，而不是沒意愿讓學生接觸真實開發環境下存在的問題。

7. 操作性設計思維

有一項技能，面試中難以測試，大學課程里又難以復制的，就是想透終端用戶使用軟件時會出錯的地方。我們通常將此稱為操作性場景思考。

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

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

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

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

純粹的代碼和編程只是問題的一部分。創造一個可以在你電腦完好運行的軟件并不難。但利用代碼時可以出錯的地方卻很多。一旦投入生產，就很難說代碼將如何被使用，以及其他代碼中哪些將會附加到原始代碼中。五年后，一個未來的程序員也許會因為你代碼的限制而感到煩躁也說不定呢。