軟件工程師花費大量時間通過練習leet code問題和完善簡歷來獲得更好的面試通過可能。一旦他們最終被谷歌、亞馬遜或其他公司錄用，他們可能會發現：過去用來得到這份工作的技能與他們日常工作中需要的技能並不匹配。
我們的團隊受到 TechLead 創建的高效程序員七項技能的啟發。我們想提供我們自己對這個話題的看法。以下是我們總結的高效程序員的七項技能。
1. 學習如何閱讀別人的代碼
除了你，每個人寫的代碼都是垃圾？實際上，能夠在別人的代碼之上繼續工作是一項有多重好處的偉大技能。
不管以前工程師的代碼是多麼混亂或者考慮不周，您仍然需要能夠擴展它。畢竟，這是你的工作。同時，這個“以前的工程師”也可能是一年前的你。
這項技能在兩個方面對你有益。第一，能夠閱讀他人的代碼是一個瞭解什麼是糟糕設計的好機會。當你瀏覽別人的代碼時，你會知道什麼是有效的，什麼是無效的。更重要的是，您可以瞭解什麼類型的代碼對於其他工程師來說是容易擴展的，以及什麼類型的代碼難以擴展。
你需要確保在閱讀他人代碼時儘可能多地找出問題所在。這樣，其他的工程師就會知道你是一個多麼優秀的工程師。確保您提出了關於可維護代碼和良好註釋的重要性觀點。這進一步顯示了你在編程領域的優勢。
您的代碼應該設計得非常好，不需要任何文檔。事實上，如果你是一個好的程序員，你不需要任何文檔來說明你的任何代碼。這只是浪費時間，更需要你花時間的是編碼和開會。
能夠閱讀別人亂七八糟的代碼的話，也使得在需要更新的時候變得容易。這有時意味著更新您缺乏經驗的代碼。例如，我們曾經將一個腳本從 Powershell 更新到 Python 再到 Perl。我們在Perl方面的經驗有限，但我們仍然有足夠的背景知識來弄清楚這段腳本到底做了什麼，並做出必要的改變。
這一切都來自於對所有代碼的良好理解以及能夠閱讀以往的代碼。閱讀別人的代碼會讓你變得有價值，因為這項技能甚至可以讓你接手那些讓別人難堪的過度工程化的系統。
2. 對壞項目的感覺
有許多技能需要花時間去學習。我們認為值得了解的技能之一是理解什麼項目不值得做，什麼項目顯然是行屍走肉。
大公司總是有非常非常多的項目在進行（老闆自己都不知道有多少），其中有些項目可能永遠都不會完成，即使完成了，可能對公司也沒有什麼有利的影響。有些可能本身就沒有任何商業意義(至少對你來說不是) ，還有一些項目可能存在管理不善的問題。這並不是說當你不認可一個項目時，你應該立即拒絕這個項目。最嗨還是看看項目干係人是如何看待這個項目的，如果他們自己都不能正確地解釋他們對這個項目的最終成果會怎麼樣的，那麼可能這個項目就不值得做。
此外，有些項目可能過於專注於技術而不是解決方案，以至於從一開始就很清楚不會有太多的影響。這個技能需要你在知道一個糟糕的項目到底是什麼之前做很多糟糕的項目。所以，不要過早地花費太多時間試圖辨別每個項目。
在你職業生涯的某個時刻，你會擁有良好的直覺與意識。
3. 避免不必要的會議
無論您是軟件工程師還是數據科學家，會議都是必不可少的，因為您需要能夠與項目經理、最終用戶和客戶達成共識。然而，也有一種傾向，會議會突然接管你的整個時間表。這就是為什麼學會如何避免不必要的會議是很重要的。
也許一個更好的詞是管理，而不是避免。這裡的目標是確保你把時間花在能夠推動決策和幫助你的團隊前進的會議上。
最常見的方法就是每天抽出兩個小時的時間，這是一個持續不斷的會議。通常，大多數人會在他們認為有益的時候定期召開會議。他們會利用這段時間來趕上他們的開發工作。
另一個避免開會以便完成工作的方法是在別人之前出現。就我個人而言，我們喜歡早到，因為一般來說，辦公室比較安靜。大多數早到的人和你一樣，只是想把工作做完，這樣就不會有人打擾你了。
這對個人貢獻者來說很重要，因為我們的工作需要我們集中注意力的時間，而且我們不會和其他人交談。 是的，有時候你可能需要解決問題，你可能想和其他人一起工作。但是一旦你解決了阻塞問題，你只需要編碼。它是關於進入那個區域，在那裡你不斷地在你的頭腦中有許多關於你正在做的工作的複雜的想法。 如果你總是停下來，很難從中斷的地方重新開始。
4. 使用Git
一些計算機專業的學生在他們出道的那天就開始使用 Git 了。他們不需要專業人士指導就可以理解每一個命令和參數。其他人在他們的第一份工作中第一次體驗到 GitHub。 對他們來說，Github 是一個地獄般的地方，充斥著混亂的命令和進程。他們永遠都不是100%的確定自己在做什麼(備忘錄之所以流行是有原因的)。
無論您的公司使用什麼倉庫系統，如果您正確使用它，該系統都是有用的，如果使用不當，則是一個障礙。一個簡單的commit或push就可以讓你花上幾個小時來理清一些由多個分支合併組成的大雜燴。此外，如果您經常忘記使用倉庫的最新版本，那麼您還將處理不那麼好玩的合併衝突。
如果您需要一個 Git 命令備忘單，那麼就做吧。只要能讓你的生活更簡單。
5. 編寫簡單可維護的代碼
年輕的工程師可能會有一種傾向，那就是試圖將他們所知道的一切都實現到一個解決方案中。有一種願望，那就是把你對面向對象程序設計、數據結構、設計模式和新技術的理解用到你編寫的每一個代碼中。然後，你就很有可能創建了一個不必要的複雜性，因為它很容易過度依附於您過去使用過的解決方案或設計模式。
在複雜的設計概念和簡單的代碼之間取得平衡。設計模式和麵向對象設計應該儘可能的去簡化宏觀計劃中的代碼。進程越是被抽象、封裝和黑盒化，就越難以調試和維護。
6. 學會說不，分清主次
這一條適用於團隊中的任何角色，不管你是財務分析師還是軟件工程師。但對於技術角色似乎每個人都更需要學會這一條。如果您是一名數據工程師，您可能會被要求做更多類似開發方向的事情。一些團隊需要數據提取，其他團隊需要儀表盤，其他團隊又需要新的數據分析對接。
區分事情的優先順序和說不，是兩種不同的技能，但它們緊密地交織在一起。優先級區分意味著你只花時間在對公司有很大影響的事情上。然而，說不有時只是意味著迴避應該由其他團隊來處理的工作。對於所有角色而言，它們經常同時出現。
這可能是一個很難獲得的技能，因為你總是希望用自己的方式去滿足每一個請求。尤其是你剛從大學畢業。你想避免讓任何人失望，而且你總是能得到大量的工作。但是，在大公司裡總是有無窮無盡的工作量，所以一定要抓住關鍵：只承擔能做的事情。
有很多技能在面試中是沒有辦法測試和驗證的，甚至在大學裡都沒有教過。通常情況下，這更多的是環境的限制，而不是缺乏讓學生暴露在真實環境中發展成長的願望。
7. 場景化思維
有一種技能在面試中很難測試，在大學學習時也很難複製，那就是思考最終用戶可能會如何錯誤地使用你的軟件。我們通常將其稱為場景化操作思維。
由於大部分編程都是維護性的，因此它通常意味著更改與其他代碼高度耦合的代碼。即使是簡單的更改也需要跟蹤對象、方法和 API的每一個可能存在引用的地方。否則，很容易意外地打破你沒有意識到的模塊連接。即使您只是更改數據庫中的數據類型。
它還包括在進入開發之前通過邊緣案例和整體化的高級設計進行思考。
對於開發新模塊或者微服務的場景就更加複雜，花時間去考慮所構建的操作場景非常重要。想想未來的用戶可能需要如何使用您的新模塊，他們可能會如何不正確地使用它，可能需要什麼參數，以及未來的程序員是否會以不同的方式需要您的代碼。
簡單的編碼和編程只是問題的一部分。創建一個在你的電腦上運行良好的軟件是很容易的。但是部署代碼可能出錯的方式就會有很多。一旦進入生產環境，就很難說代碼將如何使用，以及哪些其他代碼將附加到原始代碼中。五年後，未來的程序員可能會對你的代碼侷限性感到沮喪。
原創:http://blog.didispace.com/7-habits-of-highly-effective-programmers/
閱讀更多 IT知識課堂 的文章
