軟件工程師花費(fèi)大量時(shí)間通過(guò)練習(xí)解決代碼問(wèn)題和完善簡(jiǎn)歷來(lái)獲得面試技巧。

[[273789]]

一旦他們最終在一家初創(chuàng)公司、谷歌、亞馬遜或其他公司找到了那份工作，他們可能會(huì)發(fā)現(xiàn)，他們獲得這份工作所需的技能與他們?nèi)粘９ぷ魉璧募寄懿⒉黄ヅ洹?/p>

我們的團(tuán)隊(duì)受到了一位前谷歌技術(shù)主管創(chuàng)造的七個(gè)高效程序員技能的啟發(fā)。我們想就這個(gè)話題發(fā)表我們自己的看法。下面是關(guān)于高效程序員的七種技巧。

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

除了你，所有人的代碼都很糟糕。

這就是為什么一項(xiàng)具有多重好處的偉大技能是能夠遵循他人的代碼。

不管以前的工程師的代碼有多混亂或考慮得多么糟糕，您仍然需要能夠仔細(xì)閱讀它。畢竟，這是你的工作。甚至在一年前那個(gè)工程師還是你的時(shí)候。

這項(xiàng)技能對(duì)你有兩個(gè)好處。第一，能夠閱讀別人的代碼是一個(gè)很好的機(jī)會(huì)去了解什么是糟糕的設(shè)計(jì)。當(dāng)你在瀏覽別人的代碼時(shí)，你會(huì)學(xué)到什么有用，什么沒(méi)用。更重要的是，您將了解哪些代碼類型對(duì)其他工程師來(lái)說(shuō)比較容易理解，哪些代碼比較難理解。

您需要確保在閱讀其他人的代碼時(shí)盡可能多地抱怨。這樣，其他工程師就會(huì)明白你是一個(gè)多么優(yōu)秀的工程師。

確保您提到了可維護(hù)代碼和良好注釋的重要性。這進(jìn)一步顯示了您在編程領(lǐng)域的優(yōu)勢(shì)。

您的代碼應(yīng)該設(shè)計(jì)得非常好，不需要任何文檔。事實(shí)上，如果您是一個(gè)優(yōu)秀的程序員，就不應(yīng)該編寫(xiě)任何代碼的文檔。這只是浪費(fèi)時(shí)間，你需要把時(shí)間花在編程和開(kāi)會(huì)上。

能夠閱讀其他人混亂的代碼也使得在需要時(shí)進(jìn)行更新變得很容易。這有時(shí)意味著更新您缺乏經(jīng)驗(yàn)的代碼。例如，我們?cè)?jīng)遵循一個(gè)腳本，從Powershell到Python再到Perl。雖然我們?cè)赑erl方面的經(jīng)驗(yàn)有限，但是我們?nèi)匀挥凶銐虻纳舷挛膩?lái)了解發(fā)生了什么，并做出所需的更改。

這來(lái)自于對(duì)所有代碼的良好理解以及能夠閱讀Perl腳本。

閱讀別人的代碼會(huì)讓你更有價(jià)值，因?yàn)榧词故悄切┻^(guò)于復(fù)雜的系統(tǒng)也會(huì)讓別人感到困惑。

對(duì)糟糕項(xiàng)目的感覺(jué)

有很多技能需要花時(shí)間去學(xué)習(xí)。我們相信有一項(xiàng)技能是值得知道的，那就是了解哪些項(xiàng)目不值得去做，哪些項(xiàng)目顯然是在走向死亡。

大公司總是有很多項(xiàng)目在進(jìn)行，而這些項(xiàng)目可能永遠(yuǎn)無(wú)法完成或產(chǎn)生影響。有一些項(xiàng)目可能沒(méi)有任何商業(yè)意義(至少對(duì)您來(lái)說(shuō)沒(méi)有)，還有一些項(xiàng)目管理不善。這并不是說(shuō)，當(dāng)你不同意某個(gè)項(xiàng)目的時(shí)候，你就應(yīng)該打斷它。然而，如果涉眾不能正確地解釋他們將對(duì)最終結(jié)果做什么，那么項(xiàng)目可能不值得做。

此外，有些項(xiàng)目可能過(guò)于關(guān)注技術(shù)而不是解決方案，因此從一開(kāi)始就很明顯不會(huì)有太大的影響。這一技能要求在你對(duì)一個(gè)糟糕的項(xiàng)目真正是什么有概念之前做很多糟糕的項(xiàng)目。所以，不要過(guò)早地花太多時(shí)間去分辨每個(gè)項(xiàng)目。

在你職業(yè)生涯的某個(gè)時(shí)候，你會(huì)有一個(gè)很好的直覺(jué)。

避免會(huì)議

無(wú)論您是軟件工程師還是數(shù)據(jù)科學(xué)家，會(huì)議都是必要的，因?yàn)槟枰軌蚺c項(xiàng)目經(jīng)理、最終用戶和客戶保持一致。然而，會(huì)議也有突然占據(jù)你整個(gè)日程的趨勢(shì)。這就是為什么學(xué)習(xí)如何避免不必要的會(huì)議很重要。

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

最常見(jiàn)的方法就是每天留出兩個(gè)小時(shí)的時(shí)間，那就是經(jīng)常開(kāi)會(huì)。通常，大多數(shù)人會(huì)在他們認(rèn)為有益的時(shí)候安排一次經(jīng)常性的會(huì)議。他們將利用這段時(shí)間來(lái)趕上他們的開(kāi)發(fā)工作。

另一種避免開(kāi)會(huì)的方法是比其他人早到，這樣你就能完成工作。就我個(gè)人而言，我們喜歡早到，因?yàn)榭偟膩?lái)說(shuō)，辦公室比較安靜。大多數(shù)早起的人和你一樣，只是想把工作做完，這樣就不會(huì)有人打擾你了。

這對(duì)個(gè)人貢獻(xiàn)者來(lái)說(shuō)很重要，因?yàn)槲覀兊墓ぷ餍枰覀儗Ｗ⒌臅r(shí)間，我們不需要和其他人交談。有時(shí)候你可能想和別人一起解決問(wèn)題。但是一旦您解決了阻塞問(wèn)題，您只需要編寫(xiě)代碼。它是關(guān)于進(jìn)入一個(gè)區(qū)域，在這個(gè)區(qū)域里，你的頭腦中不斷地持有許多關(guān)于你正在做的工作的復(fù)雜想法。如果你不停地停下來(lái)，你就很難從停止的地方繼續(xù)。

Git

一些CS專業(yè)的學(xué)生從出生那天就開(kāi)始使用Git。他們能夠理解每一個(gè)命令和參數(shù)，并且能夠圍繞專業(yè)人員運(yùn)行。

其他人則是在第一份工作中第一次接觸到GitHub。對(duì)他們來(lái)說(shuō)，Github是一個(gè)混亂的命令和進(jìn)程的地獄。他們從不100%確定自己在做什么(備忘單受歡迎是有原因的)。

無(wú)論您的公司使用哪種存儲(chǔ)庫(kù)系統(tǒng)，如果正確使用該系統(tǒng)，那么該系統(tǒng)都是有用的;如果使用不當(dāng)，則會(huì)成為障礙。一個(gè)簡(jiǎn)單的推動(dòng)或承諾并不會(huì)讓你花費(fèi)很多時(shí)間去理清由多個(gè)分支和叉組成的大雜燴。此外，如果您經(jīng)常忘記提取存儲(chǔ)庫(kù)的最新版本，那么您還將處理從未有過(guò)樂(lè)趣的合并沖突。

如果需要保存Git命令備忘單，那么就這么做。只要能讓你的生活更簡(jiǎn)單。

編寫(xiě)簡(jiǎn)單的可維護(hù)代碼

年輕工程師可能有一種傾向，就是試圖將他們所知道的所有東西都實(shí)現(xiàn)到一個(gè)解決方案中。人們希望理解面向?qū)ο缶幊?、?shù)據(jù)結(jié)構(gòu)、設(shè)計(jì)模式和新技術(shù)，并在編寫(xiě)的每一段代碼中使用所有這些知識(shí)。您創(chuàng)建了不必要的復(fù)雜性，因?yàn)楹苋菀走^(guò)度依賴于過(guò)去使用的解決方案或設(shè)計(jì)模式。

復(fù)雜的設(shè)計(jì)概念和簡(jiǎn)單的代碼之間存在一種平衡。設(shè)計(jì)模式和面向?qū)ο蟮脑O(shè)計(jì)應(yīng)該從整體上簡(jiǎn)化代碼。然而，一個(gè)過(guò)程被抽象、封裝和黑盒化的越多，調(diào)試就越困難。

學(xué)會(huì)說(shuō)“不”，分清輕重緩急

這適用于任何角色，無(wú)論是金融分析師還是軟件工程師。但尤其值得一提的是，技術(shù)角色似乎讓每個(gè)人都需要從中得到一些東西。如果您是一名數(shù)據(jù)工程師，您可能會(huì)被要求做的不僅僅是開(kāi)發(fā)管道。一些團(tuán)隊(duì)將需要數(shù)據(jù)提取，其他團(tuán)隊(duì)將需要儀表板，其他團(tuán)隊(duì)將需要為數(shù)據(jù)科學(xué)家提供新的管道。

現(xiàn)在，分清輕重緩急和說(shuō)“不”可能真的是兩種不同的技能，但它們緊密地交織在一起。優(yōu)先級(jí)意味著你只花對(duì)公司有重大影響的時(shí)間。然而，有時(shí)候說(shuō)“不”只是意味著逃避應(yīng)該由另一個(gè)團(tuán)隊(duì)來(lái)處理的工作。對(duì)于所有的角色，它們常常是同時(shí)發(fā)生的。

這是一項(xiàng)很難掌握的技能，因?yàn)槟愫苋菀捉邮軇e人提出的每一個(gè)要求。尤其是如果你剛大學(xué)畢業(yè)。你想要避免讓任何人失望，你總是被提供了大量的工作。

在大公司里，總是有無(wú)窮無(wú)盡的工作要做。關(guān)鍵在于承擔(dān)能做的事情。

有很多技能在面試中沒(méi)有經(jīng)過(guò)測(cè)試，甚至在大學(xué)里也沒(méi)有教授過(guò)。通常，這更多的是環(huán)境的限制，而不是缺乏讓學(xué)生接觸真實(shí)開(kāi)發(fā)環(huán)境中存在的問(wèn)題的愿望。

操作設(shè)計(jì)思考

有一項(xiàng)技能是很難在面試中測(cè)試的，當(dāng)你在大學(xué)里上課時(shí)也很難復(fù)制的，那就是思考最終用戶可能會(huì)如何錯(cuò)誤地使用你的軟件。我們通常將此引用為通過(guò)操作場(chǎng)景進(jìn)行思考。

不過(guò)，這只是一種禮貌的說(shuō)法，表示您正在嘗試偽證明代碼。

例如，由于大多數(shù)編程都是維護(hù)，所以它通常意味著更改與其他代碼高度混亂的代碼。即使是簡(jiǎn)單的更改也需要跟蹤對(duì)象、方法和/或API的所有可能引用。否則，很容易意外地破壞附加的模塊。即使只是更改數(shù)據(jù)庫(kù)中的數(shù)據(jù)類型。

它還包括在進(jìn)行開(kāi)發(fā)之前考慮邊緣案例和整個(gè)高層設(shè)計(jì)。

對(duì)于開(kāi)發(fā)新模塊或微服務(wù)的更復(fù)雜的情況，重要的是要花時(shí)間考慮正在構(gòu)建的操作場(chǎng)景?？紤]未來(lái)的用戶可能需要如何使用您的新模塊，他們可能如何不正確地使用它，可能需要哪些參數(shù)，以及未來(lái)的程序員可能需要您的代碼的方式是否不同。

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