軟體工程師花費大量時間通過練習leet code問題和完善簡歷來獲得更好的面試通過可能。一旦他們最終被谷歌、亞馬遜或其他公司錄用，他們可能會發現：過去用來得到這份工作的技能與他們日常工作中需要的技能並不匹配。
我們的團隊受到 techlead 建立的高效程式設計師七項技能的啟發。我們想提供我們自己對這個話題的看法。以下是我們總結的高效程式設計師的七項技能。
除了你，每個人寫的**都是垃圾？實際上，能夠在別人的**之上繼續工作是一項有多重好處的偉大技能。
不管以前工程師的**是多麼混亂或者考慮不周，您仍然需要能夠擴充套件它。畢竟，這是你的工作。同時，這個「以前的工程師」也可能是一年前的你。
這項技能在兩個方面對你有益。第一，能夠閱讀他人的**是乙個了解什麼是糟糕設計的好機會。當你瀏覽別人的**時，你會知道什麼是有效的，什麼是無效的。更重要的是，您可以了解什麼型別的**對於其他工程師來說是容易擴充套件的，以及什麼型別的**難以擴充套件。
你需要確保在閱讀他人**時盡可能多地找出問題所在。這樣，其他的工程師就會知道你是乙個多麼優秀的工程師。確保您提出了關於可維護**和良好注釋的重要性觀點。這進一步顯示了你在程式設計領域的優勢。
您的**應該設計得非常好，不需要任何文件。事實上，如果你是乙個好的程式設計師，你不需要任何文件來說明你的任何**。這只是浪費時間，更需要你花時間的是編碼和開會。
能夠閱讀別人亂七八糟的**的話，也使得在需要更新的時候變得容易。這有時意味著更新您缺乏經驗的**。例如，我們曾經將乙個指令碼從 powershell 更新到 python 再到 perl。我們在perl方面的經驗有限，但我們仍然有足夠的背景知識來弄清楚這段指令碼到底做了什麼，並做出必要的改變。
這一切都來自於對所有**的良好理解以及能夠閱讀以往的**。閱讀別人的**會讓你變得有價值，因為這項技能甚至可以讓你接手那些讓別人難堪的過度工程化的系統。
有許多技能需要花時間去學習。我們認為值得了解的技能之一是理解什麼專案不值得做，什麼專案顯然是行屍走肉。
大公司總是有非常非常多的專案在進行（老闆自己都不知道有多少），其中有些專案可能永遠都不會完成，即時完成了，可能對公司也沒有什麼有利的影響。有些可能本身就沒有任何商業意義(至少對你來說不是) ，還有一些專案可能存在管理不善的問題。這並不是說當你不認可乙個專案時，你應該立即拒絕這個專案。最嗨還是看看專案干係人是如何看待這個專案的，如果他們自己都不能正確地解釋他們對這個專案的最終成果會怎麼樣的，那麼可能這個專案就不值得做。
此外，有些專案可能過於專注於技術而不是解決方案，以至於從一開始就很清楚不會有太多的影響。這個技能需要你在知道乙個糟糕的專案到底是什麼之前做很多糟糕的專案。所以，不要過早地花費太多時間試圖辨別每個專案。
在你職業生涯的某個時刻，你會擁有良好的直覺與意識。
無論您是軟體工程師還是資料科學家，會議都是必不可少的，因為您需要能夠與專案經理、終端使用者和客戶達成共識。然而，也有一種傾向，會議會突然接管你的整個時間表。這就是為什麼學會如何避免不必要的會議是很重要的。
也許乙個更好的詞是管理，而不是避免。這裡的目標是確保你把時間花在能夠推動決策和幫助你的團隊前進的會議上。
最常見的方法就是每天抽出兩個小時的時間，這是乙個持續不斷的會議。通常，大多數人會在他們認為有益的時候定期召開會議。他們會利用這段時間來趕上他們的開發工作。
另乙個避免開會以便完成工作的方法是在別人之前出現。就我個人而言，我們喜歡早到，因為一般來說，辦公室比較安靜。大多數早到的人和你一樣，只是想把工作做完，這樣就不會有人打擾你了。
這對個人貢獻者來說很重要，因為我們的工作需要我們集中注意力的時間，而且我們不會和其他人交談。 是的，有時候你可能需要解決問題，你可能想和其他人一起工作。但是一旦你解決了阻塞問題，你只需要編碼。它是關於進入那個區域，在那裡你不斷地在你的頭腦中有許多關於你正在做的工作的複雜的想法。 如果你總是停下來，很難從中斷的地方重新開始。
一些計算機專業的學生在他們出道的那天就開始使用 git 了。他們不需要專業人士指導就可以理解每乙個命令和引數。其他人在他們的第乙份工作中第一次體驗到 github。 對他們來說，github 是乙個地獄般的地方，充斥著混亂的命令和程序。他們永遠都不是100%的確定自己在做什麼(備忘錄之所以流行是有原因的)。
無論您的公司使用什麼倉庫系統，如果您正確使用它，該系統都是有用的，如果使用不當，則是乙個障礙。乙個簡單的commit或push就可以讓你花上幾個小時來理清一些由多個分支合併組成的大雜燴。此外，如果您經常忘記使用倉庫的最新版本，那麼您還將處理不那麼好玩的合併衝突。
如果您需要乙個 git 命令備忘單，那麼就做吧。只要能讓你的生活更簡單。
年輕的工程師可能會有一種傾向，那就是試圖將他們所知道的一切都實現到乙個解決方案中。有一種願望，那就是把你對物件導向程式設計、資料結構、設計模式和新技術的理解用到你編寫的每乙個**中。然後，你就很有可能建立了乙個不必要的複雜性，因為它很容易過度依附於您過去使用過的解決方案或設計模式。
在複雜的設計概念和簡單的**之間取得平衡。設計模式和物件導向設計應該盡可能的去簡化巨集觀計畫中的**。程序越是被抽象、封裝和黑盒化，就越難以除錯和維護。
這一條適用於團隊中的任何角色，不管你是財務分析師還是軟體工程師。但對於技術角色似乎每個人都更需要學會這一條。如果您是一名資料工程師，您可能會被要求做更多類似開發方向的事情。一些團隊需要資料提取，其他團隊需要儀錶盤，其他團隊又需要新的資料分析對接。
區分事情的優先順序和說不，是兩種不同的技能，但它們緊密地交織在一起。優先順序區分意味著你只花時間在對公司有很大影響的事情上。然而，說不有時只是意味著迴避應該由其他團隊來處理的工作。對於所有角色而言，它們經常同時出現。
這可能是乙個很難獲得的技能，因為你總是希望用自己的方式去滿足每乙個請求。尤其是你剛從大學畢業。你想避免讓任何人失望，而且你總是能得到大量的工作。但是，在大公司裡總是有無窮無盡的工作量，所以一定要抓住關鍵：只承擔能做的事情。
有很多技能在面試中是沒有辦法測試和驗證的，甚至在大學裡都沒有教過。通常情況下，這更多的是環境的限制，而不是缺乏讓學生暴露在真實環境中發展成長的願望。
有一種技能在面試中很難測試，在大學學習時也很難複製，那就是思考終端使用者可能會如何錯誤地使用你的軟體。我們通常將其稱為場景化操作思維。
由於大部分程式設計都是維護性的，因此它通常意味著更改與其他**高度耦合的**。即使是簡單的更改也需要跟蹤物件、方法和 api的每乙個可能存在引用的地方。否則，很容易意外地打破你沒有意識到的模組連線。即使您只是更改資料庫中的資料型別。
它還包括在進入開發之前通過邊緣案例和整體化的高階設計進行思考。
對於開發新模組或者微服務的場景就更加複雜，花時間去考慮所構建的操作場景非常重要。想想未來的使用者可能需要如何使用您的新模組，他們可能會如何不正確地使用它，可能需要什麼引數，以及未來的程式設計師是否會以不同的方式需要您的**。
簡單的編碼和程式設計只是問題的一部分。建立乙個在你的電腦上執行良好的軟體是很容易的。但是部署**可能出錯的方式就會有很多。一旦進入生產環境，就很難說**將如何使用，以及哪些其他**將附加到原始**中。五年後，未來的程式設計師可能會對你的**侷限**到沮喪。
高效程式設計師應該養成的七個習慣
理解你的需求 成為乙個有效率的程式設計師首先要知道如何正確的支配自己的時間。對時間最大的浪費莫過於去做那些沒有用處或者永遠不會上線的專案。而導致這種結果的根源往往是對需求理解的偏差。要最大程度避免這種情況的發生，最好的辦法是快速建模，盡可能讓演示系統早點出來。對於客戶來說，只有看得到摸得著的產品擺在...
評高效程式設計師應該養成的七個習慣
評高效程式設計師應該養成的七個習慣 高效程式設計師應該養成的七個習慣 一文中，phil chu根據自己的經驗提出了高效程式設計師應該養成的七個習慣。它們是 1.理解你的需求 2.保持真實性 3.理解你的 4.最優程式設計 5.管理好你自己 6.持續教育 7.r e s p e c t 請閱讀原文，僅...
優秀程式設計師的七個好習慣
在企業級的應用開發中，我們更強調程式設計師的協作能力和團隊開發，如何能融入團隊，成為乙個優秀的程式設計師，本文總結了從事開發工作中七個好習慣。所謂 思想 影響行為，行為決定習慣，習慣養成性格，性格左右命運 本文介紹的內容需要有意識地 思想上認同 培養才能具備，需要隨時提醒自己按照這七個好習慣去行 動...