軟件工程師花費大量時間通過練習解決代碼問題和完善簡歷來獲得面試技巧。

[[273789]]

一旦他們最終在一家初創公司、谷歌、亞馬遜或其他公司找到了那份工作，他們可能會發現，他們獲得這份工作所需的技能與他們日常工作所需的技能并不匹配。

我們的團隊受到了一位前谷歌技術主管創造的七個高效程序員技能的啟發。我們想就這個話題發表我們自己的看法。下面是關于高效程序員的七種技巧。

學習如何閱讀別人的代碼

除了你，所有人的代碼都很糟糕。

這就是為什么一項具有多重好處的偉大技能是能夠遵循他人的代碼。

不管以前的工程師的代碼有多混亂或考慮得多么糟糕，您仍然需要能夠仔細閱讀它。畢竟，這是你的工作。甚至在一年前那個工程師還是你的時候。

這項技能對你有兩個好處。第一，能夠閱讀別人的代碼是一個很好的機會去了解什么是糟糕的設計。當你在瀏覽別人的代碼時，你會學到什么有用，什么沒用。更重要的是，您將了解哪些代碼類型對其他工程師來說比較容易理解，哪些代碼比較難理解。

您需要確保在閱讀其他人的代碼時盡可能多地抱怨。這樣，其他工程師就會明白你是一個多么優秀的工程師。

確保您提到了可維護代碼和良好注釋的重要性。這進一步顯示了您在編程領域的優勢。

您的代碼應該設計得非常好，不需要任何文檔。事實上，如果您是一個優秀的程序員，就不應該編寫任何代碼的文檔。這只是浪費時間，你需要把時間花在編程和開會上。

能夠閱讀其他人混亂的代碼也使得在需要時進行更新變得很容易。這有時意味著更新您缺乏經驗的代碼。例如，我們曾經遵循一個腳本，從Powershell到Python再到Perl。雖然我們在Perl方面的經驗有限，但是我們仍然有足夠的上下文來了解發生了什么，并做出所需的更改。

這來自于對所有代碼的良好理解以及能夠閱讀Perl腳本。

閱讀別人的代碼會讓你更有價值，因為即使是那些過于復雜的系統也會讓別人感到困惑。

對糟糕項目的感覺

有很多技能需要花時間去學習。我們相信有一項技能是值得知道的，那就是了解哪些項目不值得去做，哪些項目顯然是在走向死亡。

大公司總是有很多項目在進行，而這些項目可能永遠無法完成或產生影響。有一些項目可能沒有任何商業意義(至少對您來說沒有)，還有一些項目管理不善。這并不是說，當你不同意某個項目的時候，你就應該打斷它。然而，如果涉眾不能正確地解釋他們將對最終結果做什么，那么項目可能不值得做。

此外，有些項目可能過于關注技術而不是解決方案，因此從一開始就很明顯不會有太大的影響。這一技能要求在你對一個糟糕的項目真正是什么有概念之前做很多糟糕的項目。所以，不要過早地花太多時間去分辨每個項目。

在你職業生涯的某個時候，你會有一個很好的直覺。

避免會議

無論您是軟件工程師還是數據科學家，會議都是必要的，因為您需要能夠與項目經理、最終用戶和客戶保持一致。然而，會議也有突然占據你整個日程的趨勢。這就是為什么學習如何避免不必要的會議很重要。

也許用“管理”這個詞比“避免”更好。這里的目標是確保你把時間花在會議上，以推動決策并幫助你的團隊前進。

最常見的方法就是每天留出兩個小時的時間，那就是經常開會。通常，大多數人會在他們認為有益的時候安排一次經常性的會議。他們將利用這段時間來趕上他們的開發工作。

另一種避免開會的方法是比其他人早到，這樣你就能完成工作。就我個人而言，我們喜歡早到，因為總的來說，辦公室比較安靜。大多數早起的人和你一樣，只是想把工作做完，這樣就不會有人打擾你了。

這對個人貢獻者來說很重要，因為我們的工作需要我們專注的時間，我們不需要和其他人交談。有時候你可能想和別人一起解決問題。但是一旦您解決了阻塞問題，您只需要編寫代碼。它是關于進入一個區域，在這個區域里，你的頭腦中不斷地持有許多關于你正在做的工作的復雜想法。如果你不停地停下來，你就很難從停止的地方繼續。

Git

一些CS專業的學生從出生那天就開始使用Git。他們能夠理解每一個命令和參數，并且能夠圍繞專業人員運行。

其他人則是在第一份工作中第一次接觸到GitHub。對他們來說，Github是一個混亂的命令和進程的地獄。他們從不100%確定自己在做什么(備忘單受歡迎是有原因的)。

無論您的公司使用哪種存儲庫系統，如果正確使用該系統，那么該系統都是有用的;如果使用不當，則會成為障礙。一個簡單的推動或承諾并不會讓你花費很多時間去理清由多個分支和叉組成的大雜燴。此外，如果您經常忘記提取存儲庫的最新版本，那么您還將處理從未有過樂趣的合并沖突。

如果需要保存Git命令備忘單，那么就這么做。只要能讓你的生活更簡單。

編寫簡單的可維護代碼

年輕工程師可能有一種傾向，就是試圖將他們所知道的所有東西都實現到一個解決方案中。人們希望理解面向對象編程、數據結構、設計模式和新技術，并在編寫的每一段代碼中使用所有這些知識。您創建了不必要的復雜性，因為很容易過度依賴于過去使用的解決方案或設計模式。

復雜的設計概念和簡單的代碼之間存在一種平衡。設計模式和面向對象的設計應該從整體上簡化代碼。然而，一個過程被抽象、封裝和黑盒化的越多，調試就越困難。

學會說“不”，分清輕重緩急

這適用于任何角色，無論是金融分析師還是軟件工程師。但尤其值得一提的是，技術角色似乎讓每個人都需要從中得到一些東西。如果您是一名數據工程師，您可能會被要求做的不僅僅是開發管道。一些團隊將需要數據提取，其他團隊將需要儀表板，其他團隊將需要為數據科學家提供新的管道。

現在，分清輕重緩急和說“不”可能真的是兩種不同的技能，但它們緊密地交織在一起。優先級意味著你只花對公司有重大影響的時間。然而，有時候說“不”只是意味著逃避應該由另一個團隊來處理的工作。對于所有的角色，它們常常是同時發生的。

這是一項很難掌握的技能，因為你很容易接受別人提出的每一個要求。尤其是如果你剛大學畢業。你想要避免讓任何人失望，你總是被提供了大量的工作。

在大公司里，總是有無窮無盡的工作要做。關鍵在于承擔能做的事情。

有很多技能在面試中沒有經過測試，甚至在大學里也沒有教授過。通常，這更多的是環境的限制，而不是缺乏讓學生接觸真實開發環境中存在的問題的愿望。

操作設計思考

有一項技能是很難在面試中測試的，當你在大學里上課時也很難復制的，那就是思考最終用戶可能會如何錯誤地使用你的軟件。我們通常將此引用為通過操作場景進行思考。

不過，這只是一種禮貌的說法，表示您正在嘗試偽證明代碼。

例如，由于大多數編程都是維護，所以它通常意味著更改與其他代碼高度混亂的代碼。即使是簡單的更改也需要跟蹤對象、方法和/或API的所有可能引用。否則，很容易意外地破壞附加的模塊。即使只是更改數據庫中的數據類型。

它還包括在進行開發之前考慮邊緣案例和整個高層設計。

對于開發新模塊或微服務的更復雜的情況，重要的是要花時間考慮正在構建的操作場景。考慮未來的用戶可能需要如何使用您的新模塊，他們可能如何不正確地使用它，可能需要哪些參數，以及未來的程序員可能需要您的代碼的方式是否不同。

簡單的編碼和編程只是問題的一部分。在你的電腦上很容易創建出運行良好的軟件。但是有很多方法會導致部署代碼出錯。一旦投入生產，就很難說代碼將如何使用，以及哪些其他代碼將附加到原始代碼中。五年后，未來的程序員可能會對代碼的限制感到沮喪。