編者按：要想成為一名軟件開發(fā)者需要學(xué)習(xí)各種專業(yè)知識、技術(shù)與框架。比如算法、數(shù)據(jù)結(jié)構(gòu)、編程語言、流行框架等。但是要想成為更加出色的軟件開發(fā)者，你要學(xué)習(xí)的就不僅僅是專業(yè)上的知識了。devtrails.io的編輯Pavels根據(jù)自己的經(jīng)驗提供了相關(guān)建議，供各位想在新年更進(jìn)一步的開發(fā)者參考。
今天我想分享一點關(guān)于軟件開發(fā)者如何改進(jìn)職業(yè)技能從而變得更擅長于自身工作的技巧。這里要談的主題是通用性的，并沒有針對任何特定的技術(shù)棧。其實這里要談的大部分甚至都不是針對IT的。這些都是如何形成個人特質(zhì)，跟同事、客戶改進(jìn)協(xié)作，以及拓展作為軟件開發(fā)者職業(yè)生涯的一般性建議。
本文里面有些東西屬于主觀性判斷，反映的是我的個人經(jīng)驗，還有一些則已經(jīng)被其他人采納并成功運用。
端到端理解整個流程
很多開發(fā)者認(rèn)為軟件開發(fā)純粹就是寫代碼，其他事情根本就是別人在打擾自己，浪費他們寶貴的時間。這種說法距離事實再也不能再遠(yuǎn)了。在你卸下第一行代碼之前，需要經(jīng)歷從模糊到精心設(shè)計準(zhǔn)備可以實施的解決方案這樣一個轉(zhuǎn)變過程。當(dāng)你把最新的變更推動到Git之后，軟件需要經(jīng)歷測試、部署、監(jiān)控、分析以及改進(jìn)等過程。編碼只是流程眾多步驟之一而已。
為什么會這樣？因為項目的不同階段經(jīng)常是由不同的團(tuán)隊甚至不同的部門來處理的，大型組織尤其是這樣。一切都先從收集需求的商業(yè)分析師開始。需求然后遞交給設(shè)計師，為開發(fā)者輸出原型。開發(fā)者編碼把結(jié)果提交給QA工程師。如果一切都OK，成品就會發(fā)送給運營團(tuán)隊交付給最終用戶。這個流程被當(dāng)作一組離散的步驟，沒有任何反饋。因為部門間缺乏溝通，其代表通常并不真正理解別人的目標(biāo)，這會導(dǎo)致誤解甚至沖突。
軟件開發(fā)流程往往被當(dāng)作一組離散的步驟，沒有任何反饋。
對于現(xiàn)在的很多人來說這種說法似乎太過夸張。隨著敏捷方法論的崛起，更多的公司已經(jīng)從此類僵化的做法轉(zhuǎn)移至混合不同專業(yè)的小型化團(tuán)隊。但即便這樣我們也還是看到大家并不真正理解別人的工作。你有多少次因為設(shè)計師要你實現(xiàn)一個太過耗時的定制化復(fù)選框而被激怒？反之亦然，你又有多少次因為忘記使用正確字體而受到指責(zé)？
這些差異很多都可以克服，如果你留意別人的工作的話。跟你的設(shè)計師坐到一起，解釋給他聽，說實現(xiàn)定制化復(fù)選框要花點時間，但是有個庫可以提供你可以重用的類似復(fù)選框。反之，你也得學(xué)習(xí)一下字體排版基礎(chǔ)，理解為什么選擇正確的字體會有影響。對待經(jīng)理、商業(yè)分析師、QA工程師、支撐人員以及營銷專家等也要養(yǎng)成同樣的態(tài)度。借用赫胥黎的話來說：
盡可能廣泛地涉獵各門學(xué)問，并且盡可能深入地?fù)褚汇@研。
通過盡可能廣泛地涉獵各門學(xué)問，你將能夠預(yù)測他們的需求，簡化反饋回環(huán)，促進(jìn)更頻繁的交付。此外，這還會為你贏得很多的愛以及所有其他人的尊重。
理解你客戶的需求
關(guān)于你的客戶，有一件重要的事情你需要理解：他們并不理解你做的大部分事情。敏捷、函數(shù)程序設(shè)計或者非關(guān)系式數(shù)據(jù)庫對他們來說都是黑暗魔法。甚至那些密切跟進(jìn)你的工作并且真心感興趣的人仍然大部分都不了解。這會有幾個后果。
大多數(shù)客戶跟軟件開發(fā)者交談時的面部表情。
雇軟件開發(fā)者需要有一定程度的信任。要為某個自己不理解的東西支付一大筆錢的時候大家往往會覺得不舒服。還記得上一次你走進(jìn)一家不熟悉的汽車維修店卻不擔(dān)心他們是否值得信任是什么時候嗎？你的客戶也會有同樣的感受。只是這里沒有車，而是一堆抽象的、不可觸摸的概念，你得將其具體化成產(chǎn)品或者收入。跟新客戶合作是贏得他們的信任非常重要。確保他們理解你是怎么工作的，然后小規(guī)模頻繁地交付迭代結(jié)果。這樣他們就能看到你的工作進(jìn)展，評估中間結(jié)果并且提供他們的反饋。
客戶經(jīng)常會提出他們自己的解決方案而不是分享他們的問題。由于他們對你的能力幾乎一無所知，他們的解決方案往往會誤判，不是過于保守就是太過激進(jìn)。記住亨利·福特的那句老話（也可能是杜撰的）：
每當(dāng)我問顧客需要什么的時候，他們總是會說需要跑得更快的馬。
這時候你不能總是默默地按照他們的要求去實現(xiàn)，有時候請他們先后退一步討論一下自己想要解決的問題是什么會很有用。在結(jié)合了他們的領(lǐng)域知識與你的專業(yè)技術(shù)時，你就有可能得出一個更好的解決方案。
記住，并不是每個人都喜歡自己的想法受質(zhì)疑，這種策略需要你機智一點，不要挫傷客戶的信心。你還得離開你的舒適區(qū)，讓自己沉浸到他們的業(yè)務(wù)當(dāng)中，從而真正理解問題所在，推薦更好的解決方案。如果你要做的是金融或者醫(yī)療保健等復(fù)雜行業(yè)的話，這會比較有挑戰(zhàn)性。但如果你搞定了一次，下次客戶的心態(tài)可能就會更加開放一點。
為工作選擇合適的工具
如果你手里只有一把錘子，其他一切看起來都像釘子。
只學(xué)了一門技術(shù)的開發(fā)者往往會急急忙忙就想用它來解決遇到的任何問題。毫不奇怪，這種做法會導(dǎo)致次優(yōu)結(jié)果。相反，在處理新問題時，要停下來思考一下你手頭的工具是否真的適合這類工作。如果你有疑慮，就要做點調(diào)查提出一組可能更加出色的替代者。為了讓這個過程簡單一點，可以編譯一個問題清單來評估不同的選擇。每次評估的問題可以不一樣，但大概可以是這樣的：
它必須支持哪些平臺或者設(shè)備？
有哪些非功能性的需求，比如性能或者內(nèi)存使用方面？
購買授權(quán)是不是可選，還是說你需要免費或者開源的？
該解決方案是否提供了你所需要的一切，還是說你需要自己寫些東西？
你還沒有其他的限制，比如公司政策，法律方面的考慮，或者你的團(tuán)隊缺乏專家？
回答這些問題應(yīng)該有助于你在腦子里構(gòu)思相關(guān)選項，將可選的名單范圍縮小。
安全地進(jìn)行試驗
如果你懂得的東西沒有一個合適你要解決的問題，所以你想嘗試一些新東西的話，會發(fā)生什么事情呢？你沒有經(jīng)驗并不意味著就不可能。只是你需要額外考慮一些事情：
你有足夠時間準(zhǔn)備嗎？如果項目的時間安排不緊張的話，你可以在實現(xiàn)前盡可能多地去學(xué)習(xí)，剩下的再邊做邊學(xué)?；蛘咧辽俨扇 凹傺b自己可以直到成功”的態(tài)度，并且說服客戶你知道你在做的事情。
識別你首先需要測試的東西。采取“快速失敗”的辦法，識別在得出實驗結(jié)論前你需要評估的關(guān)鍵東西。對某個系統(tǒng)的性能有疑問？做一個最小化的原型然后進(jìn)行負(fù)載測試。對特定庫或者與外部服務(wù)集成不確定？單獨實現(xiàn)它然后開發(fā)剩下的。
記住，這條路走下去對你和你的客戶來說依然是有風(fēng)險的，他們需要意識到這樣既有風(fēng)險也有潛在的好處。畢竟，從長遠(yuǎn)看，2周的調(diào)查可能可以省下幾個月的時間，這聽起來像是個相當(dāng)好的交易。即便試驗失敗了，你也只損失2個星期。你的客戶對你的信任越大，他們就更有可能同意類似這樣的事情。
站在巨人的肩膀上開發(fā)
重新發(fā)明單車往往會導(dǎo)致怪異的結(jié)果。
做IT的往往有兩個常見特征：善于獨出心裁并且欣賞自己的工作。這聽起來是件好事，但卻會有尷尬的副作用：對于此前已被解決的問題，我們往往會想出自己的解決方案。所以只要我們面臨使用某框架、庫或者服務(wù)還是自己實現(xiàn)的選擇時，我們往往會選擇后者。這會讓我們走上重新發(fā)明單車這條徒勞無功的道路。導(dǎo)致這樣的一些常見的誤解包括：
自己實現(xiàn)某個東西要比學(xué)習(xí)第三方解決方案容易。盡管這也許是個完美的正當(dāng)理由，但是不要將手頭的工作過度簡化很重要。經(jīng)常一些開始看起來很簡單的東西結(jié)果表明在過程會變得困難許多。最終，你得花很多的時間處理別人已經(jīng)替你處理好的bug和極端情況。
這個解決方案做的事情超出我的需要了。除非有特殊理由，否則的話這怎會是壞事情呢？增加成品的規(guī)模，增加潛在漏洞或者顯著放緩編譯速度，這通常不算什么壞事。你到頭來可能會需要的。另一方面，只用一項功能就增加一整個庫也許是大炮打蚊子了。
我們能做得更好。盡管有一些成功的項目是按照這樣的話開始的，但通常并非如此。優(yōu)質(zhì)的第三方解決方案是由既有經(jīng)驗又有資源且致力于解決這一特定問題的團(tuán)隊維護(hù)的。要想跟他們競爭既需要能夠投入更多的時間和資源。大多數(shù)項目既沒有資源也不需要這么做。
代碼所有權(quán)和長期維護(hù)會成為問題。一些人害怕如果用第三方解決方案的話，項目會有到一定時候會被放棄或者出于某種原因變得不可用的風(fēng)險。產(chǎn)品被鎖定的風(fēng)險是真實存在的，你應(yīng)該考慮可能的緩解風(fēng)險策略。如果那是個開源項目的話，有沒有可能fork出來自己維護(hù)？或者如果是專有項目的話，取代它需要多大成本？基于這些輸入你就可以確定風(fēng)險是否值得。
通過重新實現(xiàn)來學(xué)習(xí)
這個故事還有另一面。自己重新實現(xiàn)某樣?xùn)|西其實是很棒的學(xué)習(xí)方式。盡管給生產(chǎn)項目寫自己的框架幾乎永遠(yuǎn)都是壞主意，但是做來作為學(xué)習(xí)練習(xí)就非常有價值。通過用自己的辦法重新解決一遍同樣的問題，還有比這更好的熟悉待解決問題的方式嗎。不過兔子洞不要鉆太深，一個簡化的粗糙實現(xiàn)就足以讓你了解情況了。
在做的時候，不要羞于參考類似項目的做法。研究開源項目的代碼可以讓你從更有經(jīng)驗的開發(fā)者那里獲益。
按照你的工作方式工作
團(tuán)隊和項目管理方法論。既然我們大多數(shù)都是團(tuán)隊作戰(zhàn)的，采用可改進(jìn)協(xié)作的流程并且讓大家建立起共同的工作節(jié)奏就顯得非常重要。軟件開發(fā)的敏捷運動催生了若干廣為采用的方法論，比如Scrum 或者 Kanban。他們幫助組織總體的工作架構(gòu)但并未全面覆蓋一切。還有其他一些方法論幫助你做出估計，確定問題的輕重緩急，改進(jìn)溝通等。你需要找出自己感到困難的地方然后尋找最佳實踐來應(yīng)對那些困難。
個體過程。就像一支管弦樂隊一樣，高效團(tuán)隊必須有相同的節(jié)奏，但這并未意味著每個人都必須按照相同的方法行事。每個人都有自己的喜好，應(yīng)該按照能讓自己更有效率的方式去工作。比方說，很多人在編程的時候不喜歡被打擾，但我個人喜歡短沖刺1、2個小時然后就休息一下子（不那么嚴(yán)格版的番茄工作法）。我也不喜歡在家工作，以避免家務(wù)相關(guān)的干擾，而是喜歡在辦公室或者咖啡店工作。找出適合你的工作方法，堅持下去，但也要確保你的習(xí)慣不會給其他團(tuán)隊成員造成問題。
工程實踐。很多實踐都是游走在技術(shù)與方法論的邊緣，聚焦于改進(jìn)實際的開發(fā)流程上。比方說，測試驅(qū)動開發(fā)和行為驅(qū)動開發(fā)幫助保持代碼庫結(jié)構(gòu)良好并且是經(jīng)過測試的。代碼評審幫助減少代碼瑕疵也在團(tuán)隊中傳播了知識。持續(xù)集成和持續(xù)交付確保更容易更安全的部署流程。采用這些實踐再結(jié)合上其他的組織方法論來實現(xiàn)結(jié)果的最大化。
記住，沒有可適用每個人的流程，你需要在自己的環(huán)境下試驗一下。此外，要確保你完全理解流程并且正確地實現(xiàn)它。要從已經(jīng)走過該流程的團(tuán)隊那里尋求建議，從他們的經(jīng)驗中獲得一些東西。不要忽視有助于你采用該流程的軟件和具體工具。弄一塊真正的看板以及一個現(xiàn)代的平臺用于持續(xù)交付。采用新流程需要付出努力，甚至還會導(dǎo)致短期內(nèi)生產(chǎn)力的下降。要給它一些時間然后對事情是否有改進(jìn)進(jìn)行評估。
排除障礙
排除障礙這事兒得單獨說說。忽視看似不重要但對你的工作卻有毒性作用的小麻煩是常見的錯誤。你的設(shè)計師是不是單獨坐一間房或者在另外一座建筑內(nèi)？這意味著他過來討論要費點功夫，有些事情就不會得到討論。寫心的測試是不是很困難？那就會有很多東西不會經(jīng)過測試。
這些做法本身并不是特別危險，但是小事情積累起來往往會導(dǎo)致嚴(yán)重后果。令人不快的是，等你注意到這些事情是往往已經(jīng)太晚了。尤其是在你總會有更嚴(yán)重的問題要處理時。還記得溫水煮青蛙的寓言以及蔓延常態(tài)（creeping normality）的概念嗎？
要保持警惕，在剛有苗頭就要將這些小問題消滅。
聚焦基礎(chǔ)
基本概念是你職業(yè)生涯的建構(gòu)塊。
IT是一個節(jié)奏極快的行業(yè)。每周都會有新工具推向市場。我之前已經(jīng)提到過臭名卓著的“JavaScript疲勞綜合征”了。很多開發(fā)者對每做一個新項目似乎都要重新評估一下技術(shù)棧感到很有壓力和抓狂。的確，想要永遠(yuǎn)保持領(lǐng)先是很有挑戰(zhàn)性的，但我有幾個主意可以讓這件事情變得容易一點。
首先，要專注于基本面。即便新技術(shù)似乎出現(xiàn)得相當(dāng)頻繁，新的基本概念出現(xiàn)頻率卻要低得多。在學(xué)習(xí)新東西的時候，確保你理解了導(dǎo)致出來這個東西的背后想法。很可能這些思路也已經(jīng)用到了其他項目上了，一旦你遇到類似東西時，掌握起來就會更加容易點。比方說，現(xiàn)代JavaScript UI框架是基于組件的，一旦你理解了如何用React建構(gòu)面向組件應(yīng)用，就可以在使用Angular的時候利用這種經(jīng)驗。類似地，Redux的思路也可以在Angular里面找到，而Angular的反應(yīng)式狀態(tài)管理也在React中通過Mobx實現(xiàn)了。
花點時間去熟悉一下軟件開發(fā)常見模式方面的經(jīng)典書籍，比如Gregor Hohpe和Bobby Woolf的《企業(yè)集成模式》，四人組（Gang of Four）著名的《設(shè)計模式：可重用面向?qū)ο筌浖脑亍?，或者M(jìn)artin Fowler的不同作品。盡管書中描述的一些東西也許已經(jīng)過時了，但你也可以利用來學(xué)習(xí)模式是如何演進(jìn)成今天這樣的。
其次，不要匆匆忙忙就趕著去學(xué)所有的新東西。我知道，跟蹤在Hacker News上出現(xiàn)的新事物是很有誘惑力的，但是其中有很多其實都是雜音。還不如關(guān)注一下那些在社區(qū)出現(xiàn)了一段時間，已經(jīng)過了最初炒作的高峰期而逐漸變得成熟的東西。不要陷入FOMO（害怕錯過）。如果你起碼留意一下發(fā)生的事情的話，就不會錯過任何重要的事情。
額外提示
本文已經(jīng)討論了很多東西，但是在總結(jié)前我還有幾點想補充一下。這幾點主要關(guān)注的是個人特質(zhì)而不是職業(yè)上的，但我仍然認(rèn)為它們對你的工作會產(chǎn)生很大的影響。
分享知識
大家通常以為自己把有價值的知識藏起來會讓自己變得不可或缺。如果你的團(tuán)隊里面有這樣的人的話，這人也許就會成為你的“巴士因子”，當(dāng)他離開項目的時候讓你陷入困難處境。如果你是這樣的人的話，你還得這么想，雖然你的私貨能讓你變得不可或缺，但也會導(dǎo)致你失去晉升或者休假的機會。你可能會錯過組織內(nèi)其他的職業(yè)機會，因為你已經(jīng)被當(dāng)前的角色綁死了。反過來，要把自身知識跟同事分享，如果可能的話，把部分工作委派給他們?nèi)プ?，利用這種協(xié)作，在他們工作基礎(chǔ)上做出更偉大的事情來。
不要責(zé)怪自己或者別人
很久以前我記得有一個項目因為我的錯出了點事故。我們相當(dāng)迅速地設(shè)法從事故中恢復(fù)過來，我記得客戶當(dāng)時是這樣告訴我的：
判斷一個團(tuán)隊不是看一切順風(fēng)順?biāo)从媱澾M(jìn)行的時候他們的表現(xiàn)，而是要看出現(xiàn)大麻煩的時候他們的反應(yīng)。
不管你有多出色，有時候總會出問題，這種情況下能夠保持冷靜并且用體面和相互尊重去處理就顯得非常重要。當(dāng)火被熄滅后，不要把焦點放在尋找替罪羊上。這不會幫助你在將來避免同樣錯誤的發(fā)生，只會在公司內(nèi)傳播恐懼和懷疑。相反，要把受影響的各方聚到一起進(jìn)行共同的事后剖析。把焦點放在導(dǎo)致問題發(fā)生的東西上，找出為什么會發(fā)生，并對夏天或工作流可以改進(jìn)的地方進(jìn)行頭腦風(fēng)暴，以避免將來再出現(xiàn)這個問題。
不要變成一個混蛋
開發(fā)者社區(qū)很有趣。一方面我們看到很多開放思維的人通過做開源項目、在會議上發(fā)表演講或者寫文章來給社區(qū)做貢獻(xiàn)。另一方面，我們又碰到過那些高談闊論新想法的人，對新進(jìn)入者無禮的人，并且對周圍所有人都表現(xiàn)得很粗魯?shù)娜?。不要成為這樣的人。要懷有善意，要傳播愛。
很多職業(yè)建議都可以總結(jié)成4個字。
總結(jié)
我們工作最好的一面在于它沒有限制?？倳行碌穆房梢宰撸傆行碌凝埖饶闳ネ?。不管你是剛剛開始旅途還是一名經(jīng)驗豐富的專業(yè)人士，都要謹(jǐn)記這些東西。這些建議應(yīng)該可以幫助你找到自己的辦法，在一步步當(dāng)中成為一名更好的開發(fā)者。
