圖片來(lái)源：pexels.com/@anastasiya-gepp-654466
軟件工程師們總是花費(fèi)許多時(shí)間磨練面試技巧，如練習(xí)力扣題(leet code)和完善各自的簡(jiǎn)歷。而一旦他們?cè)谝患倚聞?chuàng)企業(yè)、谷歌、亞馬遜、或其他公司得到了工作，也許就會(huì)發(fā)現(xiàn)，其實(shí)日常工作中用不到當(dāng)初為了得到這份工作所獲得的技能。
谷歌的TechLead提出了高效程序員該有的七項(xiàng)技能。本文受到啟發(fā)，提出高效程序員該有的七項(xiàng)技能。
1. 學(xué)習(xí)如何閱讀別人的代碼
能夠閱讀其他人的代碼是一個(gè)很厲害的技能，且能帶來(lái)許多好處。
不管上一個(gè)工程師的代碼有多亂有多糟，你還是得讀懂它。這畢竟是你的工作。就算那些爛代碼是你一年前寫(xiě)的。
這個(gè)技能有兩個(gè)好處。第一，學(xué)會(huì)如何閱讀其他人的代碼可幫助你更了解什么是糟糕的設(shè)計(jì)。在看過(guò)其他人的代碼時(shí)，可以學(xué)會(huì)看出代碼可不可用。更重要的是，也可從中得知哪些代碼更易被其他工程師理解或否。
在閱讀其他人的代碼時(shí)，盡可能地對(duì)其評(píng)價(jià)。這樣，其他工程師才會(huì)知道眼前的工程師多么的不簡(jiǎn)單。
作出評(píng)價(jià)時(shí)，記得提起可維護(hù)代碼和清楚注釋的重要性。這將給編程領(lǐng)域里的優(yōu)勢(shì)加分。
你本身的代碼應(yīng)該設(shè)計(jì)得好，好到無(wú)需注釋。事實(shí)上，一個(gè)優(yōu)秀的程序員本就不應(yīng)該給自己代碼進(jìn)行注釋。那只是在浪費(fèi)時(shí)間，而寶貴的時(shí)間應(yīng)該用在編碼和開(kāi)會(huì)上。
學(xué)會(huì)閱讀其他人雜亂的代碼也有助于必要時(shí)對(duì)其進(jìn)行更新。這有時(shí)意味著更新你可能不那么熟悉的代碼。舉個(gè)例子，我們?cè)刂粋€(gè)腳本語(yǔ)言，編程語(yǔ)言從PowerShell換到Python，再改成Perl。雖然我們對(duì)Perl的經(jīng)驗(yàn)有限，但是任然有足夠的上下文來(lái)搞懂其中的代碼，并做出所需的更改。
這都?xì)w功于我們對(duì)所有代碼有一定的認(rèn)識(shí)，以及閱讀Perl腳本的能力。
閱讀別人代碼這個(gè)技能可提升個(gè)人價(jià)值，因?yàn)榫退闶莿e人望而卻步的過(guò)度工程化的系統(tǒng)也難不倒你。
2. 感知爛項(xiàng)目
圖片來(lái)源：Chris Ried, Unsplash
許多技能都需花費(fèi)時(shí)間來(lái)學(xué)習(xí)。其中一項(xiàng)技能是值得去獲取的，那就是知道哪些項(xiàng)目不值得去做，哪些項(xiàng)目顯然注定死路一條。
大企業(yè)總是有很多進(jìn)行中的項(xiàng)目，而其中可完成或有作用的卻不多。有些項(xiàng)目也許沒(méi)有任何商業(yè)意義（至少對(duì)你來(lái)說(shuō)），也有一些項(xiàng)目就是沒(méi)管理好。這并不意味著當(dāng)你對(duì)某個(gè)項(xiàng)目有異議時(shí)就直接拒絕。但是，如果股東們無(wú)法清楚解釋項(xiàng)目用途時(shí)，那這個(gè)項(xiàng)目很可能不值得去做。
此外，一些項(xiàng)目也許過(guò)于專(zhuān)注在技術(shù)方面而忽略了尋找解決方案。因此，從一開(kāi)始就可顯然看出不會(huì)有太大的作用。只有在接觸過(guò)很多爛項(xiàng)目后，方能得到感知它們的技能。所以剛開(kāi)始時(shí)不需要花太多時(shí)間去識(shí)別每個(gè)項(xiàng)目。
在你職業(yè)生涯的某個(gè)階段，自然就會(huì)練就一種直覺(jué)。
3. 避開(kāi)會(huì)議
無(wú)論軟件工程師還是數(shù)據(jù)科學(xué)家，都必須參與會(huì)議，以確保能與項(xiàng)目經(jīng)理、終端用戶(hù)和客戶(hù)達(dá)成共識(shí)。然而，參與太多會(huì)議反而會(huì)占據(jù)一整天的工作時(shí)間。所以學(xué)會(huì)避免不必要參與的會(huì)議是很重要的?；蛘?，“管理”一詞比“避免”會(huì)更好聽(tīng)一些。這里的目標(biāo)是確保時(shí)間能用于參與推動(dòng)決策的會(huì)議上，并且能幫助團(tuán)隊(duì)前進(jìn)。
最常見(jiàn)的方法就是每天留出兩個(gè)小時(shí)的時(shí)間，用來(lái)進(jìn)行定期開(kāi)會(huì)。通常多數(shù)人會(huì)在他們最方便的時(shí)候安排例常會(huì)議。這段時(shí)間便可用來(lái)了解所負(fù)責(zé)開(kāi)發(fā)項(xiàng)目的最新情況。
另一種為了完成工作而避開(kāi)會(huì)議的方法就是比其他人早報(bào)到。筆者們認(rèn)為，我們喜歡早到的原因是因?yàn)?，總的?lái)說(shuō)，辦公室會(huì)比較清靜。多數(shù)早到的人也一樣，都想把工作做完，這樣就不會(huì)有人打擾了。
這對(duì)獨(dú)自工作者來(lái)說(shuō)很重要，因?yàn)槲覀兊墓ぷ饔幸欢螘r(shí)間需要極度專(zhuān)注，而不和其他人交談。當(dāng)然，有些時(shí)候也許得和別人合作來(lái)解決問(wèn)題。但是一旦越過(guò)了障礙，剩下的只需編程。這時(shí)候就得進(jìn)入狀態(tài)，在腦中不斷地思考有關(guān)手上項(xiàng)目的種種復(fù)雜想法。如果不停地被打斷，那就很難恢復(fù)狀態(tài)。
4. Github
有些計(jì)算機(jī)科學(xué)專(zhuān)業(yè)的學(xué)生從出生那天起就開(kāi)始使用GitHub。他們能夠理解每一個(gè)指令和參數(shù)，能力甚至超越了教授們。
其他人則是在第一份工作后第一次接觸到GitHub。對(duì)他們來(lái)說(shuō)，GitHub是個(gè)充滿(mǎn)令人困惑的指令和程序的地獄。他們從不100%確定自己在做什么（這也就是為什么cheat sheet如此的受歡迎）。
不管公司用的是哪種存儲(chǔ)庫(kù)系統(tǒng)，該系統(tǒng)只有在正確使用時(shí)才有用；反之，則會(huì)成為阻礙。一個(gè)簡(jiǎn)單的push或者commit，和花數(shù)小時(shí)嘗試梳理亂成一團(tuán)的分支，其實(shí)只有一線(xiàn)之差。除此之外，如果經(jīng)常忘記提取存儲(chǔ)庫(kù)的最新版本，那也將面臨處理合并沖突的難題。
如果有需要保存GitHub的指令cheat sheet，那就保存起來(lái)。只要有幫助即可。
5. 編寫(xiě)簡(jiǎn)單且可維護(hù)的代碼
通常出現(xiàn)于資歷較淺工程師的一個(gè)問(wèn)題就是，他們總試圖將所有所知的東西放到一個(gè)解決方案中。他們有一種渴望，想把所學(xué)到的面向?qū)ο缶幊?、?shù)據(jù)結(jié)構(gòu)、設(shè)計(jì)模式和新技術(shù)統(tǒng)統(tǒng)用于所編寫(xiě)的每一段代碼中。這反而形成了不必要的復(fù)雜性，因?yàn)槟愫苋菀走^(guò)度依賴(lài)過(guò)去使用的解決方案或設(shè)計(jì)模式。
復(fù)雜的設(shè)計(jì)概念和簡(jiǎn)單的代碼之間存在著一種平衡。整體上來(lái)說(shuō)，設(shè)計(jì)模式和面向?qū)ο蟮脑O(shè)計(jì)應(yīng)該將代碼簡(jiǎn)化。然而，當(dāng)一個(gè)程序越被抽象化、概括化、和黑箱化，則越難偵錯(cuò)。
6. 懂得拒絕，學(xué)會(huì)分輕重緩急
這個(gè)技巧其實(shí)適用于任何職位，無(wú)論金融分析師還是軟件工程師。但尤其值得一提的是，每個(gè)人似乎都會(huì)因?yàn)槟撤N原因找技術(shù)性人員。如果你是數(shù)據(jù)工程師，處理開(kāi)發(fā)管道外還可能會(huì)被要求做其他東西。一些團(tuán)隊(duì)也許需要數(shù)據(jù)提取，其他則需要控制面板，更有一些需要新管道給他們的數(shù)據(jù)科學(xué)家。
其實(shí)，分輕重緩急和拒絕可能是兩種不同的技能，但他們是緊密交織在一起的。前者意味著只把時(shí)間花在對(duì)公司有重大影響的事情上。后者則意味著避免處理本應(yīng)屬于其他團(tuán)隊(duì)的工作。這兩個(gè)技能的需求在所有職位中都是相互存在的。
這是一項(xiàng)很難掌握的技能，因?yàn)橛袝r(shí)候面對(duì)別人請(qǐng)求的時(shí)候，會(huì)很難拒絕他們。尤其是剛畢業(yè)的大學(xué)生，都會(huì)想盡量滿(mǎn)足所有人，手上也都是可完成的工作量。
在大企業(yè)里，總是會(huì)有窮無(wú)止盡的工作要完成。關(guān)鍵在于扛下可完成的任務(wù)。
事實(shí)上很多技能都沒(méi)有在面試測(cè)試到，甚至在大學(xué)里也沒(méi)有教過(guò)。通常，這更多是環(huán)境的限制，而不是沒(méi)意愿讓學(xué)生接觸真實(shí)開(kāi)發(fā)環(huán)境下存在的問(wèn)題。
7. 操作性設(shè)計(jì)思維
有一項(xiàng)技能，面試中難以測(cè)試，大學(xué)課程里又難以復(fù)制的，就是想透終端用戶(hù)使用軟件時(shí)會(huì)出錯(cuò)的地方。我們通常將此稱(chēng)為操作性場(chǎng)景思考。
然而，這其實(shí)只是一個(gè)較好聽(tīng)的說(shuō)法。事實(shí)上你只是在確保你的代碼連白癡也可以使用。
例如，既然編碼大多都是在進(jìn)行維護(hù)，這通常代表改編互相極度纏結(jié)的代碼。就連一個(gè)簡(jiǎn)單的調(diào)整，都需要追蹤對(duì)象、方法、和/或API的所有可能關(guān)聯(lián)。否則，很容易意外地破壞之前沒(méi)注意到附加著的模塊。就算只是更改數(shù)據(jù)庫(kù)中的數(shù)據(jù)類(lèi)型也是。
這也包括在進(jìn)入開(kāi)發(fā)階段前想透邊角案例和整體的高層設(shè)計(jì)。
而對(duì)于開(kāi)發(fā)新模塊或微服務(wù)的更復(fù)雜案例，重要的是花點(diǎn)時(shí)間思考一下你手中任務(wù)的操作性場(chǎng)景。想一想未來(lái)用戶(hù)將如何需要用到你的新模塊，他們將如何錯(cuò)誤使用，什么參數(shù)將被需要，以及是否有其他時(shí)候未來(lái)程序員將會(huì)用到你的代碼。
純粹的代碼和編程只是問(wèn)題的一部分。創(chuàng)造一個(gè)可以在你電腦完好運(yùn)行的軟件并不難。但利用代碼時(shí)可以出錯(cuò)的地方卻很多。一旦投入生產(chǎn)，就很難說(shuō)代碼將如何被使用，以及其他代碼中哪些將會(huì)附加到原始代碼中。五年后，一個(gè)未來(lái)的程序員也許會(huì)因?yàn)槟愦a的限制而感到煩躁也說(shuō)不定呢。
聯(lián)系客服
