作者 | SeattleDataGuy
譯者 | 彎月，責編 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下爲譯文：
在爲面試做準備的時候，很多軟件工程師都花費了大量時間做編程題和完善簡歷。
最終在找到一份工作後，無論是在創業公司、Google、亞馬遜或是其他地方工作，他們會發現之前爲這份工作而學習的技能其實在日常工作中根本用不上。
在本文中，我們將根據自身的心得呈上高效程序員的七大技能。
學習如何閱讀他人的代碼
只要不是自己編寫的代碼看起來都不順眼。
所以說，能夠理解他人的代碼是一項偉大的技能，而且你可以從中受益良多。
不論前一位工程師的代碼多麼雜亂或思慮不夠周全，你仍然需要仔細閱讀所有的代碼。畢竟，這是你的工作。何況那位工程師可能就是一年前的你。
這項技能有兩種好處。第一，能夠閱讀別人的代碼，這是瞭解什麼是不良設計的絕佳機會。在瀏覽其他人的代碼時，你可以瞭解哪些代碼有效，而哪些無效。更重要的是，你將瞭解哪類的代碼方便其他工程師理解，而哪類的代碼很難理解。
你需要儘可能多地閱讀別人的代碼。如此一來，其他工程師就會知曉你是一名高級工程師。
同時在閱讀時，你需要指出有關代碼可維護性以及良好註釋的重要性。這可以進一步彰顯你在編程領域的主導地位。
你的代碼應該設計得井井有條，不需要任何文檔。實際上，如果你是一名優秀的程序員，則應該不需要編寫有關代碼的任何文檔。編寫文檔很浪費時間，你應該把時間花在編程和參加會議上。
能夠讀懂他人凌亂的代碼也可以方便你在必要的時候進行修改。有時這意味着你需要修改並不熟悉的代碼。例如，我們曾將腳本從Powershell轉換到Python，再轉換到Perl。我們的Perl經驗很有限，但是我們仍然有足夠的背景信息來弄清楚該如何編寫腳本並進行必要的改動。
這是因爲我們很瞭解現有的代碼，而且還能夠閱讀Perl腳本。
閱讀他人的代碼能夠提升自身的價值，因爲你遵循的都是精心設計的系統，而其他人可能不太理解。
感知不良項目
有很多技能需要付出大量的時間才能學會。我們認爲值得學習的技能之一就是了解哪些項目不值得做，以及哪些項目顯然是死路一條。
大公司的項目往往更有可能順利完成，而且影響力也更大。有些項目可能沒有任何業務意義（至少對你而言沒有意義），有些項目則管理不善。但並不是說如果你不同意就可以否認項目。然而，如果利益相關者自己都解釋不了項目的最終結果，那麼該項目可能就不值得做。
此外，有些項目可能過於關注技術而不是解決方案，因此從一開始就很明顯不會產生太大影響。在真正能夠理解什麼是不良項目之前，你需要經歷很多不良項目，才能培養起這種技能。因此，不要花費太多時間在甄別每個項目上。
等到職業生涯達到某個點時，你自然而然就能擁有良好的直覺。
避免會議
無論你是軟件工程師還是數據科學家，會議都是不可避免的，因爲你需要與項目經理、最終用戶和客戶互通有無。但是，會議常常會塞滿你的整個日程。因此我們要學會如何避免不必要的會議。或許這裏使用“管理”比“避免”更爲妥帖。目標是確保你花在會議上的時間能夠推動決策並幫助團隊前進。
最常見的方法是，在每天的日程安排上留出兩小時的固定會議。很多人都會在他們認爲合適的時間段設置例會，然後利用這段時間來抓緊時間趕開發工作。
還有一種避免會議的方法是提前到公司。就個人而言，我們喜歡早到公司，因爲通常這個時段辦公室比較安靜。大多數早到的人都和你一樣，只想完成工作，所以沒有人會打擾你。
對於獨立工作的人來說這很重要，因爲我們的工作需要專注，而且不需要與其他人交談。雖然有時候你需要與他人合作來解決問題，但一旦問題得到解決後，你只需要編寫代碼。在精神高度集中的時候，你的大腦高速運轉，處理當前工作的各種複雜想法。如果你經常被打斷，那麼就很難拾取被打斷的記憶重新開始。
Github…說起Git就頭疼？
有些計算機科學專業的學生一生下來就開始使用Git。他們瞭解每一個命令和參數，甚至超越了一些專業人士。
而有些人則在第一份工作中才開始嘗試Git。對於他們來說，Git是一堆非常費解的命令和進程。他們從未百分百確定自己的做法是否正確（因此Git命令大全非常受歡迎）。
無論你的公司使用哪種代碼存儲系統，只要使用正確都會很有幫助，但如果使用不當則會成爲阻礙。看似只是一次簡單的推送或提交，但不經意期間就很有可能會演變成一場多個分支和分叉的混戰。此外，如果你經常忘記拉取最新的版本，那麼還需要爲處理合並衝突而頭痛不已。
如果有必要的話，還是保留一份Git命令大全吧，或者其他能夠減輕你負擔的資源。
編寫易於維護的代碼
https://xkcd.com/974/
年輕的工程師常常希望在一個解決方案中實現他們所學的一切。在這種願望的驅使下，你學習了面向對象編程、數據結構、設計模式以及所有新技術，並希望在你編寫的每一段代碼中使用所有這些技術。這種思想會導致不必要的複雜性，因爲這很容易在過去使用的解決方案或設計模式之上畫蛇添足。
你需要尋求複雜的設計概念和簡單的代碼之間的平衡。設計模式和麪向對象的設計理應簡化總體方案中的代碼。但是，隨着越來越多的流程被抽象化、封裝和黑盒化，調試的難度則越來越加劇。
學會說不和排列優先順序
無論你是財務分析師還是軟件工程師，所有工作崗位的人員都需要學會說“不”和排列優先順序。尤其是技術崗位，因爲似乎每個人都需要他們提供幫助。如果你是一名數據工程師，則可能需要承擔開發數據流水線之外的工作。有些團隊需要數據提取，有些需要負責儀表板，而有些則需要爲數據科學家提供新的流水線。
雖說排列優先順序和說“不”可能是兩種不同的技能，但是二者緊密地交織在一起。排列優先順序意味着你需要將時間花費在對公司有重大影響的工作上，而說“不”則意味着避免應該由其他團隊處理的工作。對於所有崗位而言，二者都是同時發生的。
做到這一點很難，因爲我們都希望處理好每個請求。尤其是剛剛畢業的大學生。你不希望讓任何人失望，而且希望手頭有大量的工作。
在大公司，工作似乎沒有盡頭。關鍵在於只接受能夠完成的工作。
很多技能在實際的面試中根本不會被問及，甚至大學也不會教。大學生未能接觸實際開發環境中的問題往往是因爲受到了環境的限制，而不是說他們沒有這種慾望。
運營設計思維
在大學學習期間，有一項技能很難在面試中體現和複製成功，那就是思考最終用戶會如何錯誤地使用你的軟件。通常我們稱之爲運營設計思維。
然而，這個詞的背後含義是你要編寫怎麼用都不會出問題的代碼。
例如，由於許多編程都屬於維護工作，因此常常需要修改與其他代碼高度糾纏的代碼。即使是簡單的更改也需要調查對象、方法和/或API可能會被引用到的所有地方。否則，就很容易導致意外的模塊被破壞。即使你只是修改了數據庫中的某個數據類型也是如此。
此外，你還需要在開發之前仔細考慮邊緣情況，以及整個高層設計。
在開發新模塊或微服務時，情況就更復雜了，重要的是你需要花時間仔細考慮所構建內容的運營場景。考慮一下將來用戶可能會如何使用新模塊，他們可能會通過哪些錯誤的方式使用新模塊，可能需要哪些參數，以及將來程序員是否可能通過其他方式使用你的代碼。
保持代碼的簡單性只是問題的一部分。創建能夠在你自己的計算機上良好運行的軟件很容易。但是部署代碼會出現各種錯誤。一旦投入生產，就很難確保代碼的使用方式以及原始的代碼中會添加哪些代碼。從現在開始的五年後，程序員可能會對這段代碼的侷限感到失望。
原文：https://medium.com/better-programming/7-habits-of-highly-effective-programmers-563ee3b63f33
本文爲 CSDN 翻譯，轉載請註明來源出處。
更多精彩推薦
☞13 大論壇同開播！數百專家帶你從機器學習技術與工程實踐，聊到開源生態 | AI ProCon 2020
☞23 歲創業，28 歲成爲福布斯亞洲青年領袖，這個“刷臉的男人”有點牛
☞可怕！如果張東昇是個程序員......
☞重磅！CSDN 發佈「AI開源貢獻獎Top5」「AI新銳公司獎Top10」「AI優秀案例獎Top30」三大榜單
☞爲了這個技術，操作系統把 CPU 害慘了！
☞如何解釋“我篡改了區塊鏈”這個問題
你點的每個“在看”，我都認真當成了喜歡