受 TechLead 高效程序員的七項技能啓發，我們團隊想就這個話題發表自己的看法。
下面是我們總結的高效程序員的七項技能。
1. 學會如何閱讀他人的代碼
除了你，所有人寫的代碼都很糟糕。
這就是爲什麼能夠追蹤他人的代碼是一項具有多重好處的偉大技能。
不管之前工程師的代碼有多麼混亂或欠考慮，你仍然需要仔細閱讀它。畢竟，這是你的工作。甚至一年前的那個工程師也是你。
這項技能對你有兩個好處。第一，能閱讀別人的代碼讓你有一個很好的機會去了解什麼是糟糕的設計。當你在瀏覽別人的代碼時，你會了解到什麼有用什麼沒用。更重要的是，你還會了解到，對其他工程師來說，哪種類型的代碼比較容易理解哪種代碼比較難理解。
在閱讀其他人的代碼時，你可以盡情地地抱怨。這樣，其他工程師就會明白你有多麼優秀。
務必要提一下可維護代碼和良好註釋的重要性。這可以進一步顯示出你在編程領域的優勢。
你的代碼應該設計得非常好，以至於不需要任何文檔。事實上，如果你是一名優秀的程序員，就不應該編寫任何代碼的文檔。這只是浪費時間，你需要把時間花在編程和會議上。
能閱讀他人編寫的混亂代碼也使得在需要時更新變得更容易。這有時意味着更新你不瞭解的代碼。例如，我們曾經追蹤一個腳本，從 Powershell 到 Python 再到 Perl 。雖然我們在 Perl 方面的經驗有限，但我們仍然有足夠的上下文來了解發生了什麼，並做出所需的更改。
這源於我們很好地理解了所有代碼並且能夠閱讀 Perl 腳本。
閱讀別人的代碼會提升你的價值，因爲你可以追蹤那些因爲過於複雜而讓他人感到困惑的系統。
2. 能夠感知糟糕的項目
有很多技能需要花時間去學習。我們相信有一項技能是有必要了解的，那就是知道哪些項目不值得做，哪些項目必然失敗。
大公司總是有很多正在進行中的項目，而有些項目可能永遠無法完成或產生影響。有一些項目可能沒有任何商業意義（至少對你來說沒有），還有一些項目管理不善。這並不是說，當你不贊成某個項目的時候，你就應該打斷別人的想法。不過，如果涉衆不能適當地解釋他們將利用最終結果做什麼，那麼這個項目可能不值得做。
此外，有些項目可能過於關注技術而不是解決方案，因此從一開始就很清楚它不會帶來太大的影響。對於這項技能，你需要在做過很多糟糕的項目之後，才能懂得什麼樣的項目是糟糕項目。所以，不要過早地花太多時間去辨別每個項目。
在你職業生涯的某個時候，你就會有一個很好的直覺了。
3. 少開會
無論你是軟件工程師還是數據科學家，會議都是必要的，因爲你需要能夠與項目經理、最終用戶和客戶保持一致。然而，會議有時會突然佔滿你的日程表。這就是爲什麼懂得如何避免不必要的會議很重要。也許用“管理”這個詞比“避免”更好。這裏的目標是確保你花在會議上的時間是爲了推動決策並幫助你的團隊前進。
最常見的方法就是在經常開會的日子裏留出兩個小時的時間。通常，大多數人會在他們認爲有益的時候安排定期會議。他們將利用這段時間來趕上他們的開發工作。
另一種少開會的方法是比其他人早到，這樣你就能完成工作。就我個人而言，我喜歡早到，因爲總的來說，辦公室比較安靜。大多數早到的人都和你一樣，只是想把工作做完，這樣就不會有人打擾你了。
這對個人貢獻者來說很重要，因爲我們的工作需要我們有時間可以保持專注，不和其他人交談。是的，有時候你可能想和別人一起解決問題。但是一旦你解決了阻礙你前進的問題，你就只需要編碼了。就是說，你需要進入一種狀態，你的頭腦中不斷地保持着許多關於你正在做的工作的複雜想法。如果你不斷地停下來，你就很難從停止的地方繼續。
4. Github
一些計算機專業的學生從出生那天起就開始使用 GitHub。他們能夠理解每一個命令和參數，並且遠遠超過了專業人士。
有些人則是在第一份工作中首次接觸到 GitHub 。對他們來說，Github 令人困惑的命令和流程猶如夢魘。他們從來都無法 100% 確定自己在做什麼（這就是速查表受歡迎的原因）。
無論你的公司使用哪種存儲庫系統，如果使用得當，那麼該系統就有幫助；如果使用不當，那麼它就會成爲障礙。一個不費多少時間的簡單推送或提交就可以讓你花費幾個小時去理清多個分支和復刻（fork）。此外，如果你經常忘記拉取存儲庫的最新版本，那麼你還將處理並不好玩的合併衝突。
如果你需要保存一份 Github 命令速查表，那麼這樣做就好。只要能讓你的生活變得更簡單。
5. 編寫簡潔可維護的代碼
年輕工程師可能會傾向於將他們知道的所有東西都在一個解決方案中實現。這種願望讓你把自己對面向對象編程、數據結構、設計模式和新技術的理解全部都用在了每一段代碼的編寫中。這增加了不必要的複雜性，因爲很容易過度依賴於你過去使用過的解決方案或設計模式。
複雜的設計概念和簡單的代碼之間存在一種平衡。設計模式和麪向對象的設計應該從整體上簡化代碼。不過，一個過程如果抽象、封裝和黑盒化程度越高，調試就越困難。
6. 學會說“不”，分清輕重緩急
這適用於任何角色，無論是金融分析師還是軟件工程師。但尤其值得一提的是，似乎每個人都需要技術角色提供一些東西。如果你是一名數據工程師，那麼你需要做的可能不僅僅是開發管道。一些團隊需要數據提取，一些團隊則需要儀表板，還有一些團隊需要你爲他們的數據科學家提供新的管道。
分清輕重緩急和說“不”可能真的是兩種不同的技能，但它們緊密地交織在一起。分清輕重緩急意味着你只把時間花在對公司有重大影響的事情上。而說“不”有時候只是意味着避開應該由另一個團隊來處理的工作。不管對於什麼角色，它們都常常是同時發生的。
這是一項很難掌握的技能，因爲你很容易接受別人提出的每一個要求，尤其是如果你剛大學畢業。你想要避免讓任何人失望，你總是會獲得大量的工作。
在大公司裏，總是有無窮無盡的工作要做。關鍵在於只承擔能完成的工作。
有很多技巧沒有經過面試檢驗，甚至在大學裏也沒有教授過。通常，這更多的是環境限制，而不是不想讓學生接觸真實開發環境中存在的問題。
7. 面向操作的設計思維
有一項技能在面試中很難檢驗，在大學裏上課時也很難學到，那就是思考最終用戶在使用你的軟件時可能會犯什麼錯。我們通常把這個叫做通過操作場景進行思考。
不過，這只是一種禮貌的說法，意思是“你正在設法實現蠢人也不會搞砸的代碼”。
例如，由於大多數編程都是維護，所以這通常意味着修改與其他代碼混在一起的代碼。即使是簡單的修改也需要跟蹤對象、方法和 / 或 API 的所有可能引用。否則，很容易意外破壞相關的模塊。即使只是修改數據庫中的數據類型。
這還包括在開發之前考慮邊緣情況和整個高層設計。
對於開發新模塊或微服務這種更復雜的情況，花時間考慮正在構建的軟件的操作場景很重要。考慮未來的用戶可能需要如何使用你的新模塊，他們在使用它時可能會犯什麼錯，可能需要哪些參數，以及未來的程序員可能要以不同的方式使用你的代碼。
簡單的編碼和編程只是問題的一部分。創建可以在你的電腦上正常運行的軟件很容易。但部署代碼出錯的方式很多。一旦投入生產，就很難說代碼將被如何使用，以及其他哪些代碼將附加到原來的代碼中。五年後，未來的程序員可能會對代碼的限制感到沮喪。
英文原文：https://medium.com/better-programming/7-habits-of-highly-effective-programmers-563ee3b63f33
建議收藏，不然刷着刷着就可能找不到了。
有什麼前端的問題歡迎私信我~期待你的到來。
學習是一個艱苦的過程，當然如果能把技術學成，最後也一定可以獲得高薪工作。掌握一個好的學習方法，跟對一個學習的人非常重要。今後要是大家有啥問題，可以隨時來問我，能幫助別人學習解決問題，對於自己也是一個提升的過程。自己整理了一份2019最全面前端學習資料，從最基礎的HTML+CSS+JS到HTML5的項目實戰的學習資料都有整理這是我的前端技術交流羣518672693有問題隨時在裏面問我，能給大家提出很多寶貴建議。
