受到前Google TechLead的啟發
Photo by Chris Ried on Unsplash
軟件工程師花費大量時間通過練習leet代碼問題和完善簡歷來獲得面試技巧。
一旦他們最終在初創公司，谷歌，亞馬遜或另一家公司獲得這份工作，他們可能會發現他們用來獲得這份工作的技能與他們日常工作所需要的技能不匹配。
我們的團隊受到TechLead創建的高效程序員的七項技能的啟發。 我們想對這個話題發表自己的看法。
這是我們有效的程序員的七項技能。
1.學習如何閱讀他人的密碼
除您之外的每個人都編寫糟糕的代碼。
這就是為什麼一個具有多項好處的偉大技能就是能夠遵循他人的代碼。
不管以前的工程師的代碼多麼混亂或不怎麼認真，您仍然需要能夠遍歷它。 畢竟，這是您的工作。 即使那位工程師是一年前的你。
此技能有兩種好處。 一種是，能夠閱讀別人的代碼，這是瞭解什麼是不良設計的絕佳機會。 在瀏覽其他人的代碼時，您會了解哪些有效，哪些無效。 更重要的是，您將學習哪種類型的代碼容易被另一位工程師遵循以及哪些代碼難以遵循。
您需要確保儘可能多地閱讀別人的代碼。 這樣，其他工程師就會了解您是一名高級工程師。
確保您提出有關可維護代碼和良好註釋的重要性的要點。 這進一步顯示了您在編程領域的主導地位。
您的代碼應設計得井井有條，不需要任何文檔。 實際上，如果您是一名優秀的程序員，則不應編寫任何代碼。 這只是浪費時間，您需要花費時間進行編碼和參加會議。
能夠讀取他人的凌亂代碼，也可以在需要時輕鬆進行更新。 有時候這意味著更新您缺乏經驗的代碼。例如，我們曾經將腳本從Powershell轉換為Python，再轉換為Perl。 我們在Perl方面的經驗有限，但是我們仍然有足夠的背景信息來弄清楚發生了什麼，並進行所需的更改。
這源於對所有代碼的理解，以及對Perl腳本的理解。
閱讀別人的代碼使您變得很有價值，因為即使您使用的都是經過精心設計的系統，也可能會使他人感到困惑。
2.對不良項目的品味
有很多技能需要花一些時間來學習。 我們認為值得了解的技能之一，就是了解哪些項目不值得做，哪些項目顯然是步履蹣跚。
大公司的項目總是比可能完成或影響更大的項目多。 有些項目可能沒有任何業務意義（至少對您而言沒有意義），還有一些項目的管理不善。 這並不是說您不同意該項目時就應該放棄想法。 但是，如果利益相關者無法正確解釋最終結果將做什麼，那麼該項目可能就不值得做。
另外，某些項目可能過於關注技術而不是解決方案，因此從一開始就很明顯不會產生太大影響。 在瞭解到底什麼是壞項目之前，此技能需要執行許多壞項目。 因此，不要花太多時間在嘗試辨別每個項目上。
在您的職業生涯的某個時候，您將擁有良好的直覺。
3.避免開會
無論您是軟件工程師還是數據科學家，開會都是必要的，因為您需要能夠與項目經理，最終用戶和客戶保持一致。但是，會議也有可能突然佔據您的整個日程。這就是為什麼重要的是要學習如何避免不必要的會議。也許使用一個更好的詞是管理而不是避免。這裡的目標是確保您將時間花在制定決策並幫助團隊前進的會議上。
最常見的方法是每天簡單地阻止兩個小時的會議，這是一個持續不斷的會議。 通常，大多數人會在發現有益時召開一次定期會議。 他們將利用這段時間來趕上他們的開發工作。
避免開會以便完成工作的另一種方法是在別人到達之前到達辦公室。 就個人而言，我們喜歡早點出現，因為總的來說，辦公室比較安靜。 多數早期出現的人都像您一樣，只是想完成工作，所以沒有人打擾您。
這對於個人貢獻者來說很重要，因為我們的工作需要我們專注於時間，而且我們不與其他人交談。 是的，有時候您可能想在與他人一起工作的地方解決問題。 但是一旦解決了阻塞問題，您只需要編寫代碼。 這是關於進入那個區域的事情，在這個區域中，您經常對自己正在做的工作抱有很多複雜的想法。 如果您經常停下來，可能很難從上次停下來的地方繼續往前走。
4. Github…還有Git？
一些CS專業的學生在出生那天就開始使用Git。 他們瞭解每個命令和參數，並可以在專業人員周圍盤旋。
其他人在第一份工作中就對Git有初見。 對於他們來說，Git是令人困惑的命令和地獄般的進程。 他們從未百分百確定自己在做什麼（這是備忘單很受歡迎的原因）。
無論您的公司使用哪種存儲庫系統，如果正確使用該系統都將很有幫助，而如果使用不當則會對系統造成阻礙。 一次簡單的推送或Commit並不需要花費很多時間來解開多個分支和Fork的雜亂。 另外，如果您經常忘記拉取最新版本的存儲庫，那麼您還將要處理從未有過的有趣的合併衝突。
如果您需要保留Git命令備忘單，請執行此操作。 一切都會使您的生活更簡單。
5.編寫簡單的可維護代碼
年輕工程師可能會出現的一種趨勢是，嘗試將他們所知道的一切實施到一個解決方案中。 有這樣一種願望，使您對面向對象的編程，數據結構，設計模式和新技術有所瞭解，並在編寫的每一段代碼中都使用這些知識。 您會產生不必要的複雜性，因為它很容易過度附加到您過去使用的解決方案或設計模式。
在複雜的設計概念和簡單的代碼之間取得平衡。 設計模式和麵向對象的設計應該可以簡化宏偉的事物中的代碼。 但是，越來越多的流程被抽象化，封裝和黑盒化，調試起來就越困難。
6.學會說不和優先級
無論您是財務分析師還是軟件工程師，這實際上都適合任何角色。 但特別是，技術角色似乎讓每個人都需要一些東西。 如果您是數據工程師，則可能會被要求做更多的事情，而不僅僅是開發管道。 一些團隊將需要數據提取，其他團隊將需要儀表板，而其他團隊則需要為其數據科學家提供新的管道。
現在，確定優先順序並說“不”可能實際上是兩種不同的技能，但是它們緊密地交織在一起。確定優先級意味著您只花費對公司有重大影響的時間。而有時候說不，只是意味著避免應該由其他團隊處理的工作。對於所有角色，它們確實經常串聯在一起發生。
這很困難，因為它很容易處理您提出的每個請求。 尤其是如果您即將大學畢業。 您希望避免使任何人失望，並且始終為您提供大量的工作。
在大公司中，總是有無數的工作。 關鍵僅在於採取什麼措施。
很多技能在面試中都沒有經過測試，甚至在大學中也從未教授過。通常，這更多是對環境的限制，而不是缺乏讓學生暴露於實際開發環境中存在的問題的渴望。
7.運營設計思維
在大學學習時，一項很難在面試中測試且難以複製的技能正在思考最終用戶可能如何錯誤地使用您的軟件。 我們通常將其稱為通過操作場景進行思考。
不過，這只是一種禮貌的方式，表示您正在嘗試偽造證明代碼。
例如，由於許多編程都是維護工作，因此通常意味著更改與其他代碼高度糾纏的代碼。 即使是簡單的更改也需要跟蹤對象，方法和/或API的所有可能引用。 否則，很容易意外破壞您未意識到已連接的模塊。 即使您只是在更改數據庫中的數據類型。
它還包括在進行開發之前仔細考慮邊緣情況，並仔細考慮整個高層設計。
對於要開發新模塊或微服務的更復雜的情況，重要的是要花一些時間並仔細考慮所構建內容的操作場景。 考慮一下未來的用戶可能如何使用您的新模塊，他們可能如何不正確地使用它，可能需要哪些參數以及未來的程序員是否可能以其他方式使用您的代碼。
簡單地編碼和編程只是問題的一部分。 創建在您的計算機上運行良好的軟件很容易。 但是，部署代碼有很多方法可能會出錯。 一旦投入生產，就很難說出代碼的使用方式，以及原始代碼會附加哪些其他代碼。 從現在開始的五年後，未來的程序員可能會對代碼的侷限感到沮喪。
我們的靈感
我想知道他從哪裡得到所有這些各種飲料？
(本文翻譯自SeattleDataGuy的文章《7 Skills of Highly Effective Programmers》，參考：https://medium.com/better-programming/7-habits-of-highly-effective-programmers-563ee3b63f33)
閱讀更多 聞數起舞 的文章
