"高效"程序員擁有的7個技能！

譯者：萬佳，公衆號：技術最TOP

受 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