高效程序員的七個習慣

軟件工程師花費大量時間經過練習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/

歡迎關注個人公衆號：程序猿DD，得到獨家整理的學習資源和平常乾貨推送。

若是您對個人專題內容感興趣，也能夠關注個人博客：didispace.com