關於如何成為一個更好的開發者，我覺得作者總結得很全面。可能有些說法對於一些人來說有點“老掉牙”了，但往往越是這樣的東西越有存在的價值，更多的只是看的人眼高手低，知易行難。原文連結: medium.com/devtrailsio…
今天我要分享一些想法，用這些方法，一個軟體開發者不僅能夠提高他們的專業技能還能夠在工作中表現更加出色。這裡丟擲的話題具有普遍性並不限定於特定技術棧。大部分的建議甚至不只是針對IT職業，這些通用的建議是關於如何開發你的人格特質，改善與同事和客戶之間的合作，促使你的軟體開發職業往前邁進。
雖說這篇文章有些東西是主觀的以及個人經歷的一些反思，然而除此之外的建議已經被其他人採納，併為他們帶來成功。
理解點對點的流程
許多開發者把軟體開發想像成都只是關乎編碼的工作，並且除此之外的一切都是惹人厭煩的，並且浪費了他們的寶貴時間。然而，事實並非如此，在你開始編寫軟體的部分程式碼之前，需要經歷把模糊的想法轉換到精心設計的解決方案的過程，這一切都是在為具體實現做準備。當你把最後的修改推送到Git倉庫之後，軟體將被測試，部署，監控，分析和改善。編寫程式碼只是這許多步驟中的一個而已。
那麼為何會產生這種想法？多數情況下，特別是在為一個龐大的組織工作的時候，專案不同的階段會由不同的團隊甚至是不同的部門負責。這一切開始於負責需求的商業分析師，接下來這些需求會被設計人員進一步處理併為開發者產生原型。開發者帶著原型離去並進行編碼工作，然後把工作成果提交給QA工程師。如果一切都順利，這個工藝品就會被髮送給運維團隊，他們會對相關程式碼進行部署，並交付到終端使用者手上。這個過程就像是一堆彼此分離的步驟的集合，它們之間並沒有任何反饋。就因為部門之間缺乏交流，各自的代表們通常也不明白其他部門工作的目的，這會造成誤解甚至衝突。
如上圖，軟體開發經常被認為是缺乏反饋的多個步驟的集合。
在今天很多人聽起來這是不可思議的。隨著敏捷方法論的盛行，更多的公司從這種死板的開發方式過渡到由不同的專業人員組成的小團隊。但是即便如此，我們依然發現人們還是沒有去了解其他人工作的打算。你每隔多長時間會被你的設計師惹怒，只因為他們想要你實現一個定製的多選框，這在你看來只是浪費時間？還是說，你因為忘記使用正確的字型而受到他們的批評？
這裡的許多分歧都可以被克服，只需要通過關注其他人的工作。跟你的設計師坐在一起並向他們表明實現一個定製的多選框需要一些時間，而且這個元件庫已經提供了一個相似的多選框，我們可以複用它。學習排版印刷的相關基礎，就會明白為什麼選擇正確的字型會對結果有影響。對管理者，商業分析師，QA工程師，技術支援以及市場專員們都採取相同的態度，T. Huxley說過
儘可能廣泛地涉獵各門學問，並且儘可能深入地擇一鑽研。
通過在每個人身上學習一些東西，你將能夠預估他們的需求，減少反饋的次數並且更頻繁地交付。除此之外，你還贏得許多人的喜愛和尊重。
瞭解你客戶的需求
對於你的客戶有件重要的事情你需要知道一下：你的絕大部分的工作他們都是無法理解的。敏捷，函數語言程式設計或者非關係型資料庫在他們看來都是黑魔法。即便他們中有些人對你的工作感興趣，並密切關注著你的工作，但大部分時間他們都是處於模糊的狀態。每次跟開發者交流他們的表情就會像下圖這樣
他們需要對所僱傭的軟體開發真有一定程度的信任。當人們需要為某件他們所不理解的事物花費大量金錢的時候，往往會覺得不適。還記得你上次走進不熟悉的汽車維修服務店，並不確定自己是否可以相信他們會把你的坐騎修好時的感覺嗎？很好，你的客戶對你也是有相同的感覺，不同的只是這裡沒有汽車，而只有一大堆抽象的並對他們而言是模凌兩可的概念，這些概念被假定可以以某種方式具像化為產品以及收益。當與新客戶一起工作的時候，獲得他們的信任是很重要的。要確保他們理解你的運營方式，目標是每次交付更小的結果但是會更加頻繁地進行迭代。這種方式能讓他們看到你的工作進度，稽核中間產物，並提出他們的意見。
客戶通常會傾向於提出他們自己的解決方案，而不是分享他們的問題。當他們對你的能力有一點概念的時候，他們就會意識到自己的解決方案通常是帶誤導性的，低端的或者說是不切實際的。還記得一句亨利福特的老話（可能是虛構的）
如果我問人們想要什麼，他們會說更快的馬。
比起隨波逐流並且靜悄悄地實現客戶想要的功能，有些時候更有效的方式是請他們退一步，並討論他們想要解決的首要問題。結合他們的領域經驗以及你的專業知識，你可能會得到一個更好的解決方案。
記住，任何人都不喜歡自己的想法被質疑，實施這個戰略的前提是你在客戶眼中是睿智的並且是能鼓舞信心的。為了理解問題並提出更好的解決方案，你需要離開舒適區並讓自己沉浸在他們的生意場中。如果你是為金融或者健康護理這樣的複雜行業工作的話，會有一定的挑戰性。然而一旦你做到了，可能顧客下次還會找你合作，並且能夠進一步對你敞開心扉。
為工作選擇恰當的工具
如果你有一個錘子，一切看起來就像是釘子。
通常的開發者一旦學習了一門技術，就急於用它來解決所有他們遇到的問題。並不意外，但這種方式會引匯出許多次優的結果。相反，當處理一個新的問題時，停下來並思考你所支配的工具是否真的適合這類工作。如果你對此有所懷疑，稍微做一下調研，並提出一堆用於解決這類問題的優秀可替代選項。為了使工作更容易，需要編制出一系列問題並且挨個地去審查每一個可選項。雖說每次評估的時候問題會有所不同，但是可以按下面的路線前進：
- 它必須支援什麼平臺或者裝置？
- 非功能性需求是什麼，比方說效能或者說記憶體使用？
- 這個選擇是否需要購買證照？或者說你需要免費，開源的東西？
- 這個解決方案是否提供了超出你需求的東西，或者說你是否需要自己手寫一些東西？
- 你是否有一些其他的限制，比如公司的政策，法律層面的考慮，或者團隊中缺少專家？
通過回答這些問題應該可以幫助你組織腦海中的可選項，並縮減“候選人”名單。
安全地進行試驗
那麼如果你所掌握的東西實際上並不是很符合你案例的需求，你想要嘗試一些新的東西該怎麼辦呢？實際上你對一些事物沒有經驗並不意味著它超出了你要解決的問題。這只是意味著你需要考慮更多的東西：
-
你有足夠的時間做準備嗎？ 如果專案交付日期並不是很趕，在開始實現一個功能之前你可以儘可能去學習一些東西，並承受走這條路所需要的時間成本。或者至少採用“成功之前先裝一下”的方法，告訴客戶你知道你自己在做什麼，並以此來安撫他們。
-
首先確定那些你需要測試的東西。 貫徹“儘早失敗”的原則，在你可以對這次試驗做總結之前，需要確定有哪些重要的東西是需要評估的。對這個系統的效能有所懷疑？那就嘗試構建一個最小的原型，並執行一個負載測試。對採用一個獨特的程式庫或者整合一個外部的系統沒有把握？那就分別實現他們，然後再去構建剩下的東西。
記住，走這條路對無論對你還是客戶來說都是有風險的，他們需要知道風險的存在以及潛在的好處。在這之後，可能兩週的調研會節省你數個月的工作量，往長遠來看這聽起來是個不錯的成果。即便最後試驗失敗了，你也只是失去了兩週的時間。你的客戶對你越信任，就越有可能會同意這類試驗。
站在巨人的肩膀上
往往重新發明的輪子往往會導致奇怪的結果
IT從業者有兩個普遍的特徵：1. 我們是有發明才能的。2.我們享受我們的工作。這聽起來像是好事兒，然而這會帶來一個尷尬的副作用：我們傾向於對曾經被解決過的問題提出自己的解決方案，因此，當我們面臨到底是使用已有的框架，庫，服務還是自己手動去實現這兩種選擇的時候，我們都傾向於選擇後者。這會把我們帶上重新發明輪子的無效之旅。下面是一些造成這種結果的常見誤區
-
自己來實現要比學習第三方庫要容易。 這可能是一個最有說服力的理由，但重要的是不要過於低估手動實現的難度。通常有些東西一開始看起來很簡單，但它會在開發過程中變得越發困難。最終你可能會花費一大串的時間來處理bug以及邊界值問題，而這些問題可能已經有人幫你處理過了。
-
這個解決方案提供的東西超出了我的需求。 要說它是個壞東西除非有什麼特殊的理由，比如增加了最終產品的體積，新增了一些潛在的風險因素或者說考慮到這會拖慢構建流程。而這並不總是壞事，你可能到後面還是會需要用到它。另一方面，如果新增整一個庫最終卻只使用了其中的一個函式，就可能是個過度行為了。
-
我們能比它做得更好。 即便是有一些成功的專案都是以這種說法為開端，但這並不是一個慣例。一個高質量的第三方的解決方案都是由團隊維護的，他們有一定的經驗，並且為了解決實際問題投入了不少資源。為了完成這些事情，你需要投入的甚至更多。在大多數專案中我們都沒有資源來做這些事情，或者說這根本不必要。
-
從程式碼的所有權以及長期維護角度來考慮，第三方的方案可能會是個問題。 有些人害怕一旦使用第三方庫，你將會陷入因某種原因在某個時間點該專案會被拋棄或者不再穩定的風險當中。這種被專案封禁的危機是真實存在的，你應該要考慮遷移的策略。如果它是一個開源專案，你是否有可能fork它並且自己維護？或者說如果它是一個有專利的專案，替換它需要付出什麼代價？基於這些問題，你可以對這種冒險是否值得作出一個清醒的抉擇。
通過重新實現來學習
這是這則故事的另一面。自己重新實現一些東西實際上是很好的學習方式。為一個生產級別的專案編寫你自己的框架總是一個壞的主意，然而通過建立一個框架來練手卻有很高的價值。嘗試解決相同的問題，能夠讓你對框架已經解決了的問題有進一步的理解。但不要太過於深入兔子洞中，一個簡化了的粗糙實現足以讓你對場景有所理解。
當你這樣做的時候，要敢於窺探相似專案的原始碼。從開源專案中學習，你將會在那些更老練的開發者的經驗中受益。
為如何工作而工作
你需要努力去改善的的不僅僅是技術方面，還應該包括方法倫。如同恰當地設計並且優化過的軟體，一個確定的工作流程將會減少你的工作量及工作壓力，卻能產出更好的結果。建立一個有效且高效的工作流程並不是一個簡單的任務，針對這個話題已經有許多的書籍和材料可以參考。不過在開始之前，先考慮改善接下來的幾個領域：
-
團隊和專案管理的方法倫。 我們的大多數工作都是團隊協作，採用一個能夠改善團隊成員合作關係併為每個人建立一個通用工作節奏的流程是很重要的。軟體開發中的敏捷運動已經孕育出許多被廣泛接受的方法倫，比如Scrum和Kanban。雖說它們能夠協助你組織好工作但卻不能覆蓋所有東西。你還需要其他的方法論幫助你做預算，安排問題的優先順序，改善溝通等等。你需要去確定你正在努力工作的領域，並尋求該領域的最佳實踐，這將會使你的努力更有價值。
-
個人流程。 就像是管絃樂隊，一個高效的團隊必須有相同的節奏，但是這並不意味著每一個團隊成員必須用完全相同的方式來工作，每個人都有他們自己的選擇權，應該要以對他們而言更高效的方式來工作。舉個例子，大多數人都希望在數個小時的編碼過程中不被打擾，但我自己則喜歡在一個或者兩個小時中新增一些休息間隔（一個不太嚴格的番茄工作法）。我也不喜歡在家工作，而更喜歡在辦公室或者咖啡廳工作，這是為了避免家庭相關的干擾。找出對你有效工作方式的並堅持它，但是要確保你的習慣並不會給團隊的其他成員製造問題。
-
工程實踐。 在技術和方法論之間有許多專注於改善開發流程的實踐。舉個例子，測試驅動開發以及行為驅動開發會協助你更好地組織和測試程式碼。程式碼審查會幫助減少程式碼的缺陷，並在團隊中傳播知識。持續整合和持續交付簡化了部署流程，使過程更加健壯。結合其他已經被有效組織的方法論來貫徹這些實踐以達到產出最大化。
記住，沒有一個流程會對所有人都有效，你需要自己的環境中試驗它。當然，要確保對流程的完全把控並且能夠正確地實現它。在已經實踐過這些開發流程的團隊中尋求建議，從他們的經驗中受益。不要忽視相關的軟體以及實質性的工具，它們會幫助你接納一個流程。為持續交付準備一個真實的看板以及一個現代化平臺。採納一個新的流程會需要付出些努力甚至會導致短期的生產力減退。給它一點時間，並對其中的一些事情是否得到改善做個評估。
移除障礙物
關於障礙物的問題需要單獨拿出來說一下。人們通常會錯誤地疏忽一些小的麻煩事，因為它們看起來似乎是無關緊要的，然而卻可能會對你的工作有十分負面的影響。你的產品設計師是不是坐在獨立辦公區或者是另一個樓層？這意味著如果需要進行交流不得不多投入些努力，這會導致一些事情不會被討論到。寫測試是否是件困難的事情？這會導致許多地方沒有被測試覆蓋。
這些東西在他們自己看來都沒有實際的危險，但是問題一旦堆積就會引發嚴重的後果。危險的狀況是，在一切都太晚之前你通常都不會注意到它們，尤其是總會更多嚴重事故需要跟進的時候。記住溫水煮青蛙的預言以及量變產生質變的觀點。
在麻煩的事情來臨之前保持警惕並與這些事情的根源作鬥爭。
專注基礎
IT行業是發展極其迅速的行業。每一週都會有新的工具被髮布到市場上。我之前的文章曾經提到過名聲狼藉的JavaScript疲勞綜合症。許多開發者會感受到壓力並覺得自己被強制在每一個新的專案中更換他們的JS技術棧，這會讓他們發狂。確實，總是使用前沿技術是有挑戰性的，這裡有一些關於如何讓這過程更簡單的想法。
首先，把焦點放在基礎上。即便新的技術會頻繁地出現，新的基礎概念其實是很少的。當學習新東西的時候，確定你能夠理解引匯出這整個實現的底層思想，很有可能，這些思想還會在其他的專案中被用到，一旦你遇到相似的東西，你將會更加容易去掌握它。舉個例子，現代的JavaScript UI框架都是基於元件的，一旦你明白怎麼用React去構建一個面向元件的應用程式的時候，這個經驗在Angular上也能夠適用。你會在Angular身上找到Redux思想的相似實現，Angular聯動式狀態管理思想也被React社群以Mobx的方式實現了。
花費一些時間讓自己去熟悉一些經典的書籍裡面關於軟體開發通用模式的話題，比如Gregor Hohpe和Bobby Woolf合著的“企業整合模式”，Gang of Four寫的著名的“設計模式：可複用物件導向軟體基本單元”或者Martin Flowler的“重構”。即便這些書裡所描述的一些東西已經過時了，你仍然可以通過它們來學習到設計模式是怎麼進化到今天這樣的。
第二，不要急於學習每一樣新的事物。我明白追隨在Hacker News上出現的每一樣新的事物是很有誘惑力的，但是裡面的大多數東西都只是噪音而已。把視線放在那些已經被社群圍繞了一段時間，並且對比最初的大肆宣揚已經成熟了的事物。不要陷入害怕錯過的情緒中。你只需要稍微關注一些正在發生的事情，就不會錯過重要的東西。
額外提示
我們已經在這篇文章中談論了許多東西了，但是在圓滿結束之前我還有一些其他的觀點想要強調一下。比起專業技能這些小貼士更多跟你的個人特質有關，但是我依舊相信它們會對你的職業生涯有很大的影響。
分享知識
通常人們會覺得囤積有價值的知識會讓他們成為團隊中不可或缺的存在。你的團隊中如果有這樣的人將會把你暴露在巴士因素下，而這樣一個人一旦離開專案就會把你置於一個艱難的處境。如果你是這種人中的一員，考慮到讓自己在團隊中變得不可或缺的話，你的專業知識將會是一種束縛並且你也會沒有假期可言。你可能會失去組織裡的其他的工作機會，畢竟你已經被捆綁在這個角色上了。反之，嘗試跟團隊的成員分享知識，如果有可能把你一部分的工作代理給他們並運用好這種合作關係，甚至可以基於他們的工作構建出更好的東西。
不要抱怨你自己或者其他人
記得很久之前由於我的失誤導致一個專案遭遇事故。我們被驅趕著迅速修復這次事故，還記得當時我的客戶跟我說
你不要在一切都跟隨著計劃進行的時候去審判一個團隊的表現，而是應該在麻煩大了的時候看他們是怎麼運作的。
不管你多麼優秀，有些事情也會出錯。而在這個時候重要的是能夠保持冷靜，體面地去處理這種場景，團隊成員彼此間要相互尊重。當火勢蔓延，不要急著尋找替罪羊，這並不會幫助你在未來的日子中避免失誤，而只會在公司中傳播恐懼及懷疑。反之，你可以與受影響的當事人一起來到事故現場，並做常規的“屍體檢查”。把焦點放在事故的源頭上，總結事故發生的原因，並且還要頭腦風暴一下，為了在未來避免這類問題應該要怎麼去改善你的系統還有工作流程。
不要做一個混蛋
開發者社群是一個有意思的地方。一方面我們看到許多受到開源想法驅動的人們通過為開源專案工作，在會議中做演講或者編寫文章來為社群做貢獻。另一方面，我們也遇到一些人他們高喊新的思想，不尊重新來的人並且對周圍的人表現出粗魯的行為。不要成為他們中的一份子。保持和藹並傳播愛。
圓滿結束
對於我們的工作，最好的一點就是沒有限制。有許多新的道路可以走，有許多怪可以刷。不管你是剛開始你的征途還是一個有經驗的專家，請把這些東西放在心上。它們會幫助你尋找你自己道路，每執行一步你都會變成一個更好的開發者。
你是否有不一樣的建議想要分享給其他人？儘管把它提交到評論中或者開啟一個討論組！
是否有興趣學習Web開發或者更大程度地提升你的技能？切換到devtrails.io，這裡有許多有用的指南，它們會協助你圍繞著Web開發推算出你自己的成長路線。