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

[[273326]]

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

1. 學(xué)習(xí)如何閱讀別人的代碼

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

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

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

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

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

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

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

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

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

2. 感知爛項目

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

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

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

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

3. 避開會議

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

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

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

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

4. Github

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

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

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

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

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

通常出現(xiàn)于資歷較淺工程師的一個問題就是，他們總試圖將所有所知的東西放到一個解決方案中。他們有一種渴望，想把所學(xué)到的面向?qū)ο缶幊?、?shù)據(jù)結(jié)構(gòu)、設(shè)計模式和新技術(shù)統(tǒng)統(tǒng)用于所編寫的每一段代碼中。這反而形成了不必要的復(fù)雜性，因為你很容易過度依賴過去使用的解決方案或設(shè)計模式。

復(fù)雜的設(shè)計概念和簡單的代碼之間存在著一種平衡。整體上來說，設(shè)計模式和面向?qū)ο蟮脑O(shè)計應(yīng)該將代碼簡化。然而，當(dāng)一個程序越被抽象化、概括化、和黑箱化，則越難偵錯。

6. 懂得拒絕，學(xué)會分輕重緩急

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

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

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

在大企業(yè)里，總是會有窮無止盡的工作要完成。關(guān)鍵在于扛下可完成的任務(wù)。

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

7. 操作性設(shè)計思維

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

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

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

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

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

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