高效程序員的七個(gè)習(xí)慣

很多程序員花費(fèi)大量時(shí)間通過練習(xí)面試問題和完善簡歷來獲得更好的工作機(jī)會(huì)，一旦最終被實(shí)力強(qiáng)勁的名企錄用，很多人可能會(huì)發(fā)現(xiàn)：過去用來得到這份工作的技能與日常工作中需要的技能并不匹配。

受到這個(gè)現(xiàn)象的啟發(fā)，小編有幾個(gè)獨(dú)到的看法，以下是我們總結(jié)的高效程序員的七項(xiàng)技能。

1. 學(xué)習(xí)如何閱讀別人的代碼

除了你，每個(gè)人寫的代碼都是垃圾？實(shí)際上，能夠在別人的代碼之上繼續(xù)工作是一項(xiàng)有多重好處的偉大技能。不管以前工程師的代碼是多么混亂或者考慮不周，你仍然需要能夠擴(kuò)展它。畢竟，這是你的工作。

這項(xiàng)技能在兩個(gè)方面對你有益。第一，能夠閱讀他人的代碼是一個(gè)了解什么是糟糕設(shè)計(jì)的好機(jī)會(huì)。當(dāng)你瀏覽別人的代碼時(shí)，你會(huì)知道什么是有效的，什么是無效的。更重要的是您可以了解什么類型的代碼對于其他工程師來說是容易擴(kuò)展的，以及什么類型的代碼難以擴(kuò)展。

能夠閱讀別人亂七八糟的代碼，也使得在需要更新的時(shí)候變得容易。這有時(shí)意味著更新您缺乏經(jīng)驗(yàn)的代碼。例如，我們曾經(jīng)將一個(gè)腳本從 Powershell 更新到 Python 再到 Perl。我們在Perl方面的經(jīng)驗(yàn)有限，但我們?nèi)匀挥凶銐虻谋尘爸�識來弄清楚這段腳本到底做了什么，并做出必要的改變。

這一切都來自于對所有代碼的良好理解以及能夠閱讀以往的代碼。閱讀別人的代碼會(huì)讓你變得有價(jià)值，因?yàn)檫@項(xiàng)技能甚至可以讓你接手那些讓別人難堪的過度工程化的系統(tǒng)。

2. 對壞項(xiàng)目的感覺

有許多技能需要花時(shí)間去學(xué)習(xí)。我們認(rèn)為值得了解的技能之一是理解什么項(xiàng)目不值得做，什么項(xiàng)目顯然是行尸走肉。

大公司總是有非常非常多的項(xiàng)目在進(jìn)行（老板自己都不知道有多少），其中有些項(xiàng)目可能永遠(yuǎn)都不會(huì)完成，即時(shí)完成了，可能對公司也沒有什么有利的影響。有些可能本身就沒有任何商業(yè)意義(至少對你來說不是) ，還有一些項(xiàng)目可能存在管理不善的問題。這并不是說當(dāng)你不認(rèn)可一個(gè)項(xiàng)目時(shí)，你應(yīng)該立即拒絕這個(gè)項(xiàng)目。最嗨還是看看項(xiàng)目干系人是如何看待這個(gè)項(xiàng)目的，如果他們自己都不能正確地解釋他們對這個(gè)項(xiàng)目的最終成果會(huì)怎么樣的，那么可能這個(gè)項(xiàng)目就不值得做。

此外，有些項(xiàng)目可能過于專注于技術(shù)而不是解決方案，以至于從一開始就很清楚不會(huì)有太多的影響。這個(gè)技能需要你在知道一個(gè)糟糕的項(xiàng)目到底是什么之前做很多糟糕的項(xiàng)目。所以，不要過早地花費(fèi)太多時(shí)間試圖辨別每個(gè)項(xiàng)目。

在你職業(yè)生涯的某個(gè)時(shí)刻，你會(huì)擁有良好的直覺與意識。

3. 避免不必要的會(huì)議

無論您是軟件工程師還是數(shù)據(jù)科學(xué)家，會(huì)議都是必不可少的，因?yàn)槟�需要能夠與項(xiàng)目經(jīng)理、最終用戶和客戶達(dá)成共識。然而，也有一種傾向，會(huì)議會(huì)突然接管你的整個(gè)時(shí)間表。這就是為什么學(xué)會(huì)如何避免不必要的會(huì)議是很重要的。

也許一個(gè)更好的詞是管理，而不是避免。這里的目標(biāo)是確保你把時(shí)間花在能夠推動(dòng)決策和幫助你的團(tuán)隊(duì)前進(jìn)的會(huì)議上。

最常見的方法就是每天抽出兩個(gè)小時(shí)的時(shí)間，這是一個(gè)持續(xù)不斷的會(huì)議。通常，大多數(shù)人會(huì)在他們認(rèn)為有益的時(shí)候定期召開會(huì)議。他們會(huì)利用這段時(shí)間來趕上他們的開發(fā)工作。

另一個(gè)避免開會(huì)以便完成工作的方法是在別人之前出現(xiàn)。就我個(gè)人而言，我們喜歡早到，因?yàn)橐话銇碚f，辦公室比較安靜。大多數(shù)早到的人和你一樣，只是想把工作做完，這樣就不會(huì)有人打擾你了。

這對個(gè)人貢獻(xiàn)者來說很重要，因?yàn)槲覀兊墓ぷ餍枰�我們集中注意力的時(shí)間，而且我們不會(huì)和其他人交談。 是的，有時(shí)候你可能需要解決問題，你可能想和其他人一起工作。但是一旦你解決了阻塞問題，你只需要編碼。它是關(guān)于進(jìn)入那個(gè)區(qū)域，在那里你不斷地在你的頭腦中有許多關(guān)于你正在做的工作的復(fù)雜的想法。 如果你總是停下來，很難從中斷的地方重新開始。

4. 使用Git

一些計(jì)算機(jī)專業(yè)的學(xué)生在他們出道的那天就開始使用 Git 了。他們不需要專業(yè)人士指導(dǎo)就可以理解每一個(gè)命令和參數(shù)。其他人在他們的第一份工作中第一次體驗(yàn)到 GitHub。 對他們來說，Github 是一個(gè)地獄般的地方，充斥著混亂的命令和進(jìn)程。他們永遠(yuǎn)都不是100%的確定自己在做什么(備忘錄之所以流行是有原因的)。

無論您的公司使用什么倉庫系統(tǒng)，如果您正確使用它，該系統(tǒng)都是有用的，如果使用不當(dāng)，則是一個(gè)障礙。一個(gè)簡單的commit或push就可以讓你花上幾個(gè)小時(shí)來理清一些由多個(gè)分支合并組成的大雜燴。此外，如果您經(jīng)常忘記使用倉庫的最新版本，那么您還將處理不那么好玩的合并沖突。

如果您需要一個(gè) Git 命令備忘單，那么就做吧。只要能讓你的生活更簡單。

5. 編寫簡單可維護(hù)的代碼

年輕的工程師可能會(huì)有一種傾向，那就是試圖將他們所知道的一切都實(shí)現(xiàn)到一個(gè)解決方案中。有一種愿望，那就是把你對面向?qū)ο蟪绦蛟O(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)、設(shè)計(jì)模式和新技術(shù)的理解用到你編寫的每一個(gè)代碼中。然后，你就很有可能創(chuàng)建了一個(gè)不必要的復(fù)雜性，因?yàn)樗�很容易過度依附于您過去使用過的解決方案或設(shè)計(jì)模式。

在復(fù)雜的設(shè)計(jì)概念和簡單的代碼之間取得平衡。設(shè)計(jì)模式和面向?qū)ο笤O(shè)計(jì)應(yīng)該盡可能的去簡化宏觀計(jì)劃中的代碼。進(jìn)程越是被抽象、封裝和黑盒化，就越難以調(diào)試和維護(hù)。

6. 學(xué)會(huì)說不，分清主次

這一條適用于團(tuán)隊(duì)中的任何角色，不管你是財(cái)務(wù)分析師還是軟件工程師。但對于技術(shù)角色似乎每個(gè)人都更需要學(xué)會(huì)這一條。如果您是一名數(shù)據(jù)工程師，您可能會(huì)被要求做更多類似開發(fā)方向的事情。一些團(tuán)隊(duì)需要數(shù)據(jù)提取，其他團(tuán)隊(duì)需要儀表盤，其他團(tuán)隊(duì)又需要新的數(shù)據(jù)分析對接。

區(qū)分事情的優(yōu)先順序和說不，是兩種不同的技能，但它們緊密地交織在一起。優(yōu)先級區(qū)分意味著你只花時(shí)間在對公司有很大影響的事情上。然而，說不有時(shí)只是意味著回避應(yīng)該由其他團(tuán)隊(duì)來處理的工作。對于所有角色而言，它們經(jīng)常同時(shí)出現(xiàn)。

這可能是一個(gè)很難獲得的技能，因?yàn)槟憧偸窍Ｍ�用自己的方式去滿足每一個(gè)請求。尤其是你剛從大學(xué)畢業(yè)。你想避免讓任何人失望，而且你總是能得到大量的工作。但是，在大公司里總是有無窮無盡的工作量，所以一定要抓住關(guān)鍵：只承擔(dān)能做的事情。

有很多技能在面試中是沒有辦法測試和驗(yàn)證的，甚至在大學(xué)里都沒有教過。通常情況下，這更多的是環(huán)境的限制，而不是缺乏讓學(xué)生暴露在真實(shí)環(huán)境中發(fā)展成長的愿望。

7. 場景化思維

有一種技能在面試中很難測試，在大學(xué)學(xué)習(xí)時(shí)也很難復(fù)制，那就是思考最終用戶可能會(huì)如何錯(cuò)誤地使用你的軟件。我們通常將其稱為場景化操作思維。

由于大部分編程都是維護(hù)性的，因此它通常意味著更改與其他代碼高度耦合的代碼。即使是簡單的更改也需要跟蹤對象、方法和 API的每一個(gè)可能存在引用的地方。否則，很容易意外地打破你沒有意識到的模塊連接。即使您只是更改數(shù)據(jù)庫中的數(shù)據(jù)類型。

它還包括在進(jìn)入開發(fā)之前通過邊緣案例和整體化的高級設(shè)計(jì)進(jìn)行思考。

對于開發(fā)新模塊或者微服務(wù)的場景就更加復(fù)雜，花時(shí)間去考慮所構(gòu)建的操作場景非常重要。想想未來的用戶可能需要如何使用您的新模塊，他們可能會(huì)如何不正確地使用它，可能需要什么參數(shù)，以及未來的程序員是否會(huì)以不同的方式需要您的代碼。

簡單的編碼和編程只是問題的一部分。創(chuàng)建一個(gè)在你的電腦上運(yùn)行良好的軟件是很容易的。但是部署代碼可能出錯(cuò)的方式就會(huì)有很多。一旦進(jìn)入生產(chǎn)環(huán)境，就很難說代碼將如何使用，以及哪些其他代碼將附加到原始代碼中。五年后，未來的程序員可能會(huì)對你的代碼局限性感到沮喪。

編輯：石家莊新華電腦學(xué)校