高效程序員的七個習慣

很多程序員花費大量時間通過練習面試問題和完善簡歷來獲得更好的工作機會，一旦最終被實力強勁的名企錄用，很多人可能會發現：過去用來得到這份工作的技能與日常工作中需要的技能并不匹配。

受到這個現象的啟發，小編有幾個獨到的看法，以下是我們總結的高效程序員的七項技能。

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

除了你，每個人寫的代碼都是垃圾？實際上，能夠在別人的代碼之上繼續工作是一項有多重好處的偉大技能。不管以前工程師的代碼是多么混亂或者考慮不周，你仍然需要能夠擴展它。畢竟，這是你的工作。

這項技能在兩個方面對你有益。第一，能夠閱讀他人的代碼是一個了解什么是糟糕設計的好機會。當你瀏覽別人的代碼時，你會知道什么是有效的，什么是無效的。更重要的是您可以了解什么類型的代碼對于其他工程師來說是容易擴展的，以及什么類型的代碼難以擴展。

能夠閱讀別人亂七八糟的代碼，也使得在需要更新的時候變得容易。這有時意味著更新您缺乏經驗的代碼。例如，我們曾經將一個腳本從 Powershell 更新到 Python 再到 Perl。我們在Perl方面的經驗有限，但我們仍然有足夠的背景知識來弄清楚這段腳本到底做了什么，并做出必要的改變。

這一切都來自于對所有代碼的良好理解以及能夠閱讀以往的代碼。閱讀別人的代碼會讓你變得有價值，因為這項技能甚至可以讓你接手那些讓別人難堪的過度工程化的系統。

2. 對壞項目的感覺

有許多技能需要花時間去學習。我們認為值得了解的技能之一是理解什么項目不值得做，什么項目顯然是行尸走肉。

大公司總是有非常非常多的項目在進行（老板自己都不知道有多少），其中有些項目可能永遠都不會完成，即時完成了，可能對公司也沒有什么有利的影響。有些可能本身就沒有任何商業意義(至少對你來說不是) ，還有一些項目可能存在管理不善的問題。這并不是說當你不認可一個項目時，你應該立即拒絕這個項目。最嗨還是看看項目干系人是如何看待這個項目的，如果他們自己都不能正確地解釋他們對這個項目的最終成果會怎么樣的，那么可能這個項目就不值得做。

此外，有些項目可能過于專注于技術而不是解決方案，以至于從一開始就很清楚不會有太多的影響。這個技能需要你在知道一個糟糕的項目到底是什么之前做很多糟糕的項目。所以，不要過早地花費太多時間試圖辨別每個項目。

在你職業生涯的某個時刻，你會擁有良好的直覺與意識。

3. 避免不必要的會議

無論您是軟件工程師還是數據科學家，會議都是必不可少的，因為您需要能夠與項目經理、最終用戶和客戶達成共識。然而，也有一種傾向，會議會突然接管你的整個時間表。這就是為什么學會如何避免不必要的會議是很重要的。

也許一個更好的詞是管理，而不是避免。這里的目標是確保你把時間花在能夠推動決策和幫助你的團隊前進的會議上。

最常見的方法就是每天抽出兩個小時的時間，這是一個持續不斷的會議。通常，大多數人會在他們認為有益的時候定期召開會議。他們會利用這段時間來趕上他們的開發工作。

另一個避免開會以便完成工作的方法是在別人之前出現。就我個人而言，我們喜歡早到，因為一般來說，辦公室比較安靜。大多數早到的人和你一樣，只是想把工作做完，這樣就不會有人打擾你了。

這對個人貢獻者來說很重要，因為我們的工作需要我們集中注意力的時間，而且我們不會和其他人交談。 是的，有時候你可能需要解決問題，你可能想和其他人一起工作。但是一旦你解決了阻塞問題，你只需要編碼。它是關于進入那個區域，在那里你不斷地在你的頭腦中有許多關于你正在做的工作的復雜的想法。 如果你總是停下來，很難從中斷的地方重新開始。

4. 使用Git

一些計算機專業的學生在他們出道的那天就開始使用 Git 了。他們不需要專業人士指導就可以理解每一個命令和參數。其他人在他們的第一份工作中第一次體驗到 GitHub。 對他們來說，Github 是一個地獄般的地方，充斥著混亂的命令和進程。他們永遠都不是100%的確定自己在做什么(備忘錄之所以流行是有原因的)。

無論您的公司使用什么倉庫系統，如果您正確使用它，該系統都是有用的，如果使用不當，則是一個障礙。一個簡單的commit或push就可以讓你花上幾個小時來理清一些由多個分支合并組成的大雜燴。此外，如果您經常忘記使用倉庫的最新版本，那么您還將處理不那么好玩的合并沖突。

如果您需要一個 Git 命令備忘單，那么就做吧。只要能讓你的生活更簡單。

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

年輕的工程師可能會有一種傾向，那就是試圖將他們所知道的一切都實現到一個解決方案中。有一種愿望，那就是把你對面向對象程序設計、數據結構、設計模式和新技術的理解用到你編寫的每一個代碼中。然后，你就很有可能創建了一個不必要的復雜性，因為它很容易過度依附于您過去使用過的解決方案或設計模式。

在復雜的設計概念和簡單的代碼之間取得平衡。設計模式和面向對象設計應該盡可能的去簡化宏觀計劃中的代碼。進程越是被抽象、封裝和黑盒化，就越難以調試和維護。

6. 學會說不，分清主次

這一條適用于團隊中的任何角色，不管你是財務分析師還是軟件工程師。但對于技術角色似乎每個人都更需要學會這一條。如果您是一名數據工程師，您可能會被要求做更多類似開發方向的事情。一些團隊需要數據提取，其他團隊需要儀表盤，其他團隊又需要新的數據分析對接。

區分事情的優先順序和說不，是兩種不同的技能，但它們緊密地交織在一起。優先級區分意味著你只花時間在對公司有很大影響的事情上。然而，說不有時只是意味著回避應該由其他團隊來處理的工作。對于所有角色而言，它們經常同時出現。

這可能是一個很難獲得的技能，因為你總是希望用自己的方式去滿足每一個請求。尤其是你剛從大學畢業。你想避免讓任何人失望，而且你總是能得到大量的工作。但是，在大公司里總是有無窮無盡的工作量，所以一定要抓住關鍵：只承擔能做的事情。

有很多技能在面試中是沒有辦法測試和驗證的，甚至在大學里都沒有教過。通常情況下，這更多的是環境的限制，而不是缺乏讓學生暴露在真實環境中發展成長的愿望。

7. 場景化思維

有一種技能在面試中很難測試，在大學學習時也很難復制，那就是思考最終用戶可能會如何錯誤地使用你的軟件。我們通常將其稱為場景化操作思維。

由于大部分編程都是維護性的，因此它通常意味著更改與其他代碼高度耦合的代碼。即使是簡單的更改也需要跟蹤對象、方法和 API的每一個可能存在引用的地方。否則，很容易意外地打破你沒有意識到的模塊連接。即使您只是更改數據庫中的數據類型。

它還包括在進入開發之前通過邊緣案例和整體化的高級設計進行思考。

對于開發新模塊或者微服務的場景就更加復雜，花時間去考慮所構建的操作場景非常重要。想想未來的用戶可能需要如何使用您的新模塊，他們可能會如何不正確地使用它，可能需要什么參數，以及未來的程序員是否會以不同的方式需要您的代碼。

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

編輯：石家莊新華電腦學校