高效程式設計師的七個習慣

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