標題過於浮誇，希望大家諒解，但本篇是滿滿的幹貨。今天我想分享一點關於軟件開發者如何改進職業技能從而變得更擅長於自身工作的技巧。這裏要談的主題是通用性的，並沒有針對任何特定的技術棧。其實這裏要談的大部分甚至都不是針對 IT 的。這些都是如何形成個人特質，跟同事、客戶改進協作，以及拓展作為軟件開發者職業生涯的一般性建議。

端到端理解整個流程

　　很多開發者認為軟件開發純粹就是寫代碼，其他事情根本就是別人在打擾自己，浪費他們寶貴的時間。這種說法距離事實再也不能再遠了。在你卸下第一行代碼之前，需要經歷從模糊到精心設計準備可以實施的解決方案這樣一個轉變過程。當你把最新的變更推動到 Git 之後，軟件需要經歷測試、部署、監控、分析以及改進等過程。

編碼只是流程眾多步驟之一而已。

　　為什麽會這樣？因為項目的不同階段經常是由不同的團隊甚至不同的部門來處理的，大型組織尤其是這樣。一切都先從收集需求的商業分析師開始。需求然後遞交給設計師，為開發者輸出原型。

開發者編碼把結果提交給 QA 工程師。如果一切都 OK，成品就會發送給運營團隊交付給最終用戶。這個流程被當作一組離散的步驟，沒有任何反饋。因為部門間缺乏溝通，其代表通常並不真正理解別人的目標，這會導致誤解甚至沖突。

軟件開發流程往往被當作一組離散的步驟，沒有任何反饋。

　　對於現在的很多人來說這種說法似乎太過誇張。隨著敏捷方法論的崛起，更多的公司已經從此類僵化的做法轉移至混合不同專業的小型化團隊。但即便這樣我們也還是看到大家並不真正理解別人的工作。你有多少次因為設計師要你實現一個太過耗時的定制化復選框而被激怒？反之亦然，你又有多少次因為忘記使用正確字體而受到指責？

　　這些差異很多都可以克服，如果你留意別人的工作的話。跟你的設計師坐到一起，解釋給他聽，說實現定制化復選框要花點時間，但是有個庫可以提供你可以重用的類似復選框。反之，你也得學習一下字體排版基礎，理解為什麽選擇正確的字體會有影響。對待經理、商業分析師、QA 工程師、支撐人員以及營銷專家等也要養成同樣的態度。借用赫胥黎的話來說：

盡可能廣泛地涉獵各門學問，並且盡可能深入地擇一鉆研。

通過盡可能廣泛地涉獵各門學問，你將能夠預測他們的需求，簡化反饋回環，促進更頻繁的交付。此外，這還會為你贏得很多的愛以及所有其他人的尊重。

　　理解你客戶的需求

　　關於你的客戶，有一件重要的事情你需要理解：他們並不理解你做的大部分事情。敏捷、函數程序設計或者非關系式數據庫對他們來說都是黑暗魔法。甚至那些密切跟進你的工作並且真心感興趣的人仍然大部分都不了解。這會有幾個後果。

大多數客戶跟軟件開發者交談時的面部表情。

　　雇軟件開發者需要有一定程度的信任。要為某個自己不理解的東西支付一大筆錢的時候大家往往會覺得不舒服。還記得上一次你走進一家不熟悉的汽車維修店卻不擔心他們是否值得信任是什麽時候嗎？你的客戶也會有同樣的感受。只是這裏沒有車，而是一堆抽象的、不可觸摸的概念，你得將其具體化成產品或者收入。跟新客戶合作是贏得他們的信任非常重要。確保他們理解你是怎麽工作的，然後小規模頻繁地交付叠代結果。這樣他們就能看到你的工作進展，評估中間結果並且提供他們的反饋。

　　客戶經常會提出他們自己的解決方案而不是分享他們的問題。由於他們對你的能力幾乎一無所知，他們的解決方案往往會誤判，不是過於保守就是太過激進。記住亨利·福特的那句老話（也可能是杜撰的）：

每當我問顧客需要什麽的時候，他們總是會說需要跑得更快的馬。

　這時候你不能總是默默地按照他們的要求去實現，有時候請他們先後退一步討論一下自己想要解決的問題是什麽會很有用。在結合了他們的領域知識與你的專業技術時，你就有可能得出一個更好的解決方案。

　　記住，並不是每個人都喜歡自己的想法受質疑，這種策略需要你機智一點，不要挫傷客戶的信心。你還得離開你的舒適區，讓自己沈浸到他們的業務當中，從而真正理解問題所在，推薦更好的解決方案。如果你要做的是金融或者醫療保健等復雜行業的話，這會比較有挑戰性。但如果你搞定了一次，下次客戶的心態可能就會更加開放一點。

　　為工作選擇合適的工具

如果你手裏只有一把錘子，其他一切看起來都像釘子。

只學了一門技術的開發者往往會急急忙忙就想用它來解決遇到的任何問題。毫不奇怪，這種做法會導致次優結果。相反，在處理新問題時，要停下來思考一下你手頭的工具是否真的適合這類工作。如果你有疑慮，就要做點調查提出一組可能更加出色的替代者。為了讓這個過程簡單一點，可以編譯一個問題清單來評估不同的選擇。每次評估的問題可以不一樣，但大概可以是這樣的：

• 它必須支持哪些平臺或者設備？

• 有哪些非功能性的需求，比如性能或者內存使用方面？

• 購買授權是不是可選，還是說你需要免費或者開源的？

• 該解決方案是否提供了你所需要的一切，還是說你需要自己寫些東西？

• 你還沒有其他的限制，比如公司政策，法律方面的考慮，或者你的團隊缺乏專家？

回答這些問題應該有助於你在腦子裏構思相關選項，將可選的名單範圍縮小。

　　安全地進行試驗

• 如果你懂得的東西沒有一個合適你要解決的問題，所以你想嘗試一些新東西的話，會發生什麽事情呢？你沒有經驗並不意味著就不可能。只是你需要額外考慮一些事情：

• 你有足夠時間準備嗎？如果項目的時間安排不緊張的話，你可以在實現前盡可能多地去學習，剩下的再邊做邊學。或者至少采取“假裝自己可以直到成功”的態度，並且說服客戶你知道你在做的事情。

識別你首先需要測試的東西。采取“快速失敗”的辦法，識別在得出實驗結論前你需要評估的關鍵東西。對某個系統的性能有疑問？做一個最小化的原型然後進行負載測試。對特定庫或者與外部服務集成不確定？單獨實現它然後開發剩下的。

　　記住，這條路走下去對你和你的客戶來說依然是有風險的，他們需要意識到這樣既有風險也有潛在的好處。畢竟，從長遠看，2 周的調查可能可以省下幾個月的時間，這聽起來像是個相當好的交易。即便試驗失敗了，你也只損失 2 個星期。你的客戶對你的信任越大，他們就更有可能同意類似這樣的事情。

　站在巨人的肩膀上開發

做 IT 的往往有兩個常見特征：善於獨出心裁並且欣賞自己的工作。這聽起來是件好事，但卻會有尷尬的副作用：對於此前已被解決的問題，我們往往會想出自己的解決方案。所以只要我們面臨使用某框架、庫或者服務還是自己實現的選擇時，我們往往會選擇後者。這會讓我們走上重新發明單車這條徒勞無功的道路。導致這樣的一些常見的誤解包括：

• 自己實現某個東西要比學習第三方解決方案容易。盡管這也許是個完美的正當理由，但是不要將手頭的工作過度簡化很重要。經常一些開始看起來很簡單的東西結果表明在過程會變得困難許多。最終，你得花很多的時間處理別人已經替你處理好的 bug 和極端情況。

• 這個解決方案做的事情超出我的需要了。除非有特殊理由，否則的話這怎會是壞事情呢？增加成品的規模，增加潛在漏洞或者顯著放緩編譯速度，這通常不算什麽壞事。你到頭來可能會需要的。另一方面，只用一項功能就增加一整個庫也許是大炮打蚊子了。

• 我們能做得更好。盡管有一些成功的項目是按照這樣的話開始的，但通常並非如此。優質的第三方解決方案是由既有經驗又有資源且致力於解決這一特定問題的團隊維護的。要想跟他們競爭既需要能夠投入更多的時間和資源。大多數項目既沒有資源也不需要這麽做。

• 代碼所有權和長期維護會成為問題。一些人害怕如果用第三方解決方案的話，項目會有到一定時候會被放棄或者出於某種原因變得不可用的風險。產品被鎖定的風險是真實存在的，你應該考慮可能的緩解風險策略。如果那是個開源項目的話，有沒有可能 fork 出來自己維護？或者如果是專有項目的話，取代它需要多大成本？基於這些輸入你就可以確定風險是否值得。

通過重新實現來學習

　　這個故事還有另一面。自己重新實現某樣東西其實是很棒的學習方式。盡管給生產項目寫自己的框架幾乎永遠都是壞主意，但是做來作為學習練習就非常有價值。通過用自己的辦法重新解決一遍同樣的問題，還有比這更好的熟悉待解決問題的方式嗎。不過兔子洞不要鉆太深，一個簡化的粗糙實現就足以讓你了解情況了。

　　在做的時候，不要羞於參考類似項目的做法。研究開源項目的代碼可以讓你從更有經驗的開發者那裏獲益。

　　按照你的工作方式工作

爭取改進不只是技術方面，也要在方法上。就像設計得當並且優化過的軟件一樣，一個固定下來的工作流可讓你少費力也沒那麽大壓力就能產生更好的結果。確定一套既有效率又有效能的工作流程並不是容易的任務，這方面有無數的書本和材料。不過就起步而言，可以考慮以下的改進之處：

團隊和項目管理方法論。

既然我們大多數都是團隊作戰的，采用可改進協作的流程並且讓大家建立起共同的工作節奏就顯得非常重要。

個體過程。

就像一支管弦樂隊一樣，高效團隊必須有相同的節奏，但這並未意味著每個人都必須按照相同的方法行事。每個人都有自己的喜好，應該按照能讓自己更有效率的方式去工作。比方說，很多人在編程的時候不喜歡被打擾，但我個人喜歡短沖刺1、2 個小時然後就休息一下子（不那麽嚴格版的番茄工作法）。我也不喜歡在家工作，以避免家務相關的幹擾，而是喜歡在辦公室或者咖啡店工作。找出適合你的工作方法，堅持下去，但也要確保你的習慣不會給其他團隊成員造成問題。

工程實踐。

很多實踐都是遊走在技術與方法論的邊緣，聚焦於改進實際的開發流程上。比方說，測試驅動開發和行為驅動開發幫助保持代碼庫結構良好並且是經過測試的。代碼評審幫助減少代碼瑕疵也在團隊中傳播了知識。持續集成和持續交付確保更容易更安全的部署流程。采用這些實踐再結合上其他的組織方法論來實現結果的最大化。

記住，沒有可適用每個人的流程，你需要在自己的環境下試驗一下。此外，要確保你完全理解流程並且正確地實現它。要從已經走過該流程的團隊那裏尋求建議，從他們的經驗中獲得一些東西。不要忽視有助於你采用該流程的軟件和具體工具。弄一塊真正的看板以及一個現代的平臺用於持續交付。采用新流程需要付出努力，甚至還會導致短期內生產力的下降。要給它一些時間然後對事情是否有改進進行評估。

排除障礙

　　排除障礙這事兒得單獨說說。忽視看似不重要但對你的工作卻有毒性作用的小麻煩是常見的錯誤。你的設計師是不是單獨坐一間房或者在另外一座建築內？這意味著他過來討論要費點功夫，有些事情就不會得到討論。寫心的測試是不是很困難？那就會有很多東西不會經過測試。

　　這些做法本身並不是特別危險，但是小事情積累起來往往會導致嚴重後果。令人不快的是，等你註意到這些事情是往往已經太晚了。尤其是在你總會有更嚴重的問題要處理時。還記得溫水煮青蛙的寓言以及蔓延常態（creeping normality）的概念嗎？

　　要保持警惕，在剛有苗頭就要將這些小問題消滅。

　　聚焦基礎

基本概念是你職業生涯的建構塊。

　　IT 是一個節奏極快的行業。每周都會有新工具推向市場。我之前已經提到過臭名卓著的“JavaScript 疲勞綜合征”了。很多開發者對每做一個新項目似乎都要重新評估一下技術棧感到很有壓力和抓狂。的確，想要永遠保持領先是很有挑戰性的，但我有幾個主意可以讓這件事情變得容易一點。

　　首先，要專註於基本面。即便新技術似乎出現得相當頻繁，新的基本概念出現頻率卻要低得多。在學習新東西的時候，確保你理解了導致出來這個東西的背後想法。很可能這些思路也已經用到了其他項目上了，一旦你遇到類似東西時，掌握起來就會更加容易點。比方說，現代 JavaScript UI 框架是基於組件的，一旦你理解了如何用 React 建構面向組件應用，就可以在使用 Angular 的時候利用這種經驗。類似地，Redux 的思路也可以在 Angular 裏面找到，而 Angular 的反應式狀態管理也在 React 中通過 Mobx 實現了。

　　花點時間去熟悉一下軟件開發常見模式方面的經典書籍，比如 Gregor Hohpe 和 Bobby Woolf 的《企業集成模式》，四人組（Gang of Four）著名的《設計模式：可重用面向對象軟件的元素》，或者 Martin Fowler 的不同作品。盡管書中描述的一些東西也許已經過時了，但你也可以利用來學習模式是如何演進成今天這樣的。

　　其次，不要匆匆忙忙就趕著去學所有的新東西。我知道，跟蹤在 Hacker News 上出現的新事物是很有誘惑力的，但是其中有很多其實都是雜音。還不如關註一下那些在社區出現了一段時間，已經過了最初炒作的高峰期而逐漸變得成熟的東西。不要陷入 FOMO（害怕錯過）。如果你起碼留意一下發生的事情的話，就不會錯過任何重要的事情。

　　額外提示

　　本文已經討論了很多東西，但是在總結前我還有幾點想補充一下。這幾點主要關註的是個人特質而不是職業上的，但我仍然認為它們對你的工作會產生很大的影響。

　　分享知識

　　大家通常以為自己把有價值的知識藏起來會讓自己變得不可或缺。如果你的團隊裏面有這樣的人的話，這人也許就會成為你的“巴士因子”，當他離開項目的時候讓你陷入困難處境。如果你是這樣的人的話，你還得這麽想，雖然你的私貨能讓你變得不可或缺，但也會導致你失去晉升或者休假的機會。你可能會錯過組織內其他的職業機會，因為你已經被當前的角色綁死了。反過來，要把自身知識跟同事分享，如果可能的話，把部分工作委派給他們去做，利用這種協作，在他們工作基礎上做出更偉大的事情來。

　　不要責怪自己或者別人

　　很久以前我記得有一個項目因為我的錯出了點事故。我們相當迅速地設法從事故中恢復過來，我記得客戶當時是這樣告訴我的：

判斷一個團隊不是看一切順風順水按計劃進行的時候他們的表現，而是要看出現×××煩的時候他們的反應。

　　不管你有多出色，有時候總會出問題，這種情況下能夠保持冷靜並且用體面和相互尊重去處理就顯得非常重要。當火被熄滅後，不要把焦點放在尋找替罪羊上。這不會幫助你在將來避免同樣錯誤的發生，只會在公司內傳播恐懼和懷疑。相反，要把受影響的各方聚到一起進行共同的事後剖析。把焦點放在導致問題發生的東西上，找出為什麽會發生，並對夏天或工作流可以改進的地方進行頭腦風暴，以避免將來再出現這個問題。

　　不要變成一個混蛋

　　開發者社區很有趣。一方面我們看到很多開放思維的人通過做開源項目、在會議上發表演講或者寫文章來給社區做貢獻。另一方面，我們又碰到過那些高談闊論新想法的人，對新進入者無禮的人，並且對周圍所有人都表現得很粗魯的人。不要成為這樣的人。要懷有善意，要傳播愛。

　　很多職業建議都可以總結成 4 個字。

　　總結

　　我們工作最好的一面在於它沒有限制。總會有新的路可以走，總有新的龍等你去屠。不管你是剛剛開始旅途還是一名經驗豐富的專業人士，都要謹記這些東西。這些建議應該可以幫助你找到自己的辦法，在一步步當中成為一名更好的開發者。

自己是從事了五年的前端工程師，不少人私下問我，2019年前端該怎麽學，方法有沒有？

沒錯，年初我花了一個多月的時間整理出來的學習資料，希望能幫助那些想學習前端，卻又不知道怎麽開始學習的朋友。

這裏推薦一下我的前端學習交流群：784783012 ，裏面都是學習前端的從最基礎的HTML+CSS+JS【炫酷特效，遊戲，插件封裝，設計模式】到移動端HTML5的項目實戰的學習資料都有整理，送給每一位前端小夥伴。2019最新技術，與企業需求同步。好友都在裏面學習交流，每天都會有大牛定時講解前端技術!

點擊：加入

年薪百萬的程序員都是站在巨人的肩膀上開發