高效程序員的七個(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è)方面對(duì)你有益。第一，能夠閱讀他人的代碼是一個(gè)了解什么是糟糕設(shè)計(jì)的好機(jī)會(huì)。當(dāng)你瀏覽別人的代碼時(shí)，你會(huì)知道什么是有效的，什么是無效的。更重要的是您可以了解什么類型的代碼對(duì)于其他工程師來說是容易擴(kuò)展的，以及什么類型的代碼難以擴(kuò)展。

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

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

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

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

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

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

無論您是軟件工程師還是數(shù)據(jù)科學(xué)家，會(huì)議都是必不可少的，因?yàn)槟�需要能夠與項(xiàng)目經(jīng)理、最終用戶和客戶達(dá)成共識(shí)。然而，也有一種傾向，會(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ì)有人打擾你了。

這對(duì)個(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。 對(duì)他們來說，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è)解決方案中。有一種愿望，那就是把你對(duì)面向?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ù)分析師還是軟件工程師。但對(duì)于技術(shù)角色似乎每個(gè)人都更需要學(xué)會(huì)這一條。如果您是一名數(shù)據(jù)工程師，您可能會(huì)被要求做更多類似開發(fā)方向的事情。一些團(tuán)隊(duì)需要數(shù)據(jù)提取，其他團(tuán)隊(duì)需要儀表盤，其他團(tuán)隊(duì)又需要新的數(shù)據(jù)分析對(duì)接。

區(qū)分事情的優(yōu)先順序和說不，是兩種不同的技能，但它們緊密地交織在一起。優(yōu)先級(jí)區(qū)分意味著你只花時(shí)間在對(duì)公司有很大影響的事情上。然而，說不有時(shí)只是意味著回避應(yīng)該由其他團(tuán)隊(duì)來處理的工作。對(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ù)性的，因此它通常意味著更改與其他代碼高度耦合的代碼。即使是簡單的更改也需要跟蹤對(duì)象、方法和 API的每一個(gè)可能存在引用的地方。否則，很容易意外地打破你沒有意識(shí)到的模塊連接。即使您只是更改數(shù)據(jù)庫中的數(shù)據(jù)類型。

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

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

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

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