提升技術成為一名更好的開發者
本文要點：
- 僅領會為何使用編碼套路（kata)是遠遠不夠的。
- 學會成為開發達人所必需具備的四項重要技能。
- 為改進技能，需要在訓練項目中增加強度。
- 去發現對訓練項目有用的工具。
- 將度量用做把握自身技能水平的工具。
軟件開發者使用編碼套路學習新的軟件開發技能，這種方式在當前對于新技能的學習或是已有技能的完善是非常棒的。但是在我們的工作面對燃眉之急時，例如要達成最后期限、趕上發布日期、在遺留代碼中解決故障等，使用編碼套路并不能解決這時我們所面對的工作強度問題。本文給出了成為一名好的開發者所應具備的技能，重點強調了轉變訓練方法的重要性，這些訓練方法可完善我們在高強度和具有挑戰性環境中工作的技能。
一名好的開發者所應具備的技能
哪些技能對開發者是重要的？就此問題，不同的開發者會給出不同的回答。但是也不能將此問題理解成只涉及純技術范圍內的技能，否則也會令人失望的。好的技能知識的確非常有用，然而這并非問題的全部。一些開發者較多地側重于技術技能，還有一些開發者將十分關注敏捷技能，諸如此類。這取決于如何理解軟件開發者這個職位的目的所在。請試著回答一下下列問題：
- 我為什么做一個軟件開發者？
- 我為什么要開發這個產品？
- 我為什么要去學習新的語言或架構？
- 我的產品的價值或影響力是什么？
如果對上述問題的解答中并未提及最終用戶及他們的需求，這就意味考慮上有所欠缺了。
四項重要技能
作為一名好的開發者，第一項技能是時刻考慮著最終用戶。你應確保知道最終用戶的問題所在，了解最終用戶的需求，然后再去開發那些可以解決最終用戶的問題并滿足他們需求的產品。軟件開發就是這么回事。
第二項技能涉及所交付產品的質量。無缺陷交付是一種技能。顯然，這很難達成，但并非是完全不可能的。我們很喜歡 Ed Weissman 在推文中所說的（如截圖所示）。該技能應該可以一貫堅持，即在任何情況下都能夠交付無缺陷特性的功能。顯然這也意味著現有的功能沒有被破壞。
第三項技能考慮的是對簡易性的追求，不畏懼內在的和意外的復雜性。該技能與做分解和抽象的能力相關，即如何將復雜的系統和問題分解為小部分，使這些小部分形成反差以實現相互間的獨立，并將它們組織起來，使得它們能在適當的抽象層級中被理解。在上述步驟中，必須要保持對正確抽象的關注，忽視掉那些沒有必要的細節。這里我們推薦John Maeda所著的《簡單法則》一書，該書真的是靈感之源。
第四項技能是關于如何將所有前面的技能合在一起，進而無需對任何事情（尤其是質量）做妥協就做到改進開發的速度。你的目標并非是不考慮前三項技能就空談速度。你所尋求的也不僅是快速開發的效果，而且是高質量的和積極的快速開發效果。技能方法中最重要的一點是同時包容質量和強度。
充分休息
為了實現恢復、更新和再生，身體需要得到休息，而休息問題常常得不到開發者的優先考慮。我們中的很多人以熬夜工作為榮，甚至那些更加有天賦和經驗的人也不外乎如此。你可以去讀一下 Emily Beers撰寫的探討運動員和休息問題的文章 ，并認真考慮一下休息問題。
我們認為把這篇文章中的“運動員”替換為“開發者”也成立。在心理學領域，使用了“后視偏差”（Retrospective bias）這一術語解釋為什么人們的記憶總是會和過去實際發生的事情不同，并且常常是將實際的事情羅曼蒂克化。該術語可用于解釋為什么在我們熬夜之后，會忘記缺少效率以及其它的負面后果。牢記你的身體需要得到一些休息，很多時候躺下來休息會有助于自身的進步，睡眠也具有同樣的功效。在解決生產率問題和高質量完成工作時，必須要做到好的睡眠（至少每晚睡眠八小時）和良好的休息。
增強技能的兩個價值觀
在上述技能之外，我們想再強調兩個價值觀，就是不責備但是不憐憫，以及兼容并包。
“不責備”指在每次發現了程序錯誤和缺陷時，你應該停止對當事人的尋找。為避免松懈情緒的產生，在做到“不責備”的同時也應該總是“不憐憫”。團隊不應該去責備某人，而應力圖去理解產生軟件缺陷后面的深層原因、團隊實踐中存在著什么樣的問題以及如何去避免這樣的缺陷再度發生。
我們從“SoCraTes開發空間非會議”中理解了兼容并包的價值所在。作為首次參與這種非會議的人而言，我們并未感覺到自己就像個陌生人。每個與會的人都笑臉相迎，甚至是那些我們以前從來沒有打過交道的人。與其他首次參與者一樣，我們能迅速感到自身完全成為了社區的一部分。這是一種很棒的感覺。
下面將這些價值觀用到新同事的身上。注意應盡快讓新同事集成到團隊中，幫助他們建立工作空間，盡快去與他們結對。做這些事情的目標在于使新同事在首日工作中不會感到自己就像是個陌生人。該方法不僅適用于在員工管理的角度意義上所說的入職，而且適用于在技術和工作開展角度意義上所說的入職。這意味著團隊應該建立一個入職的環境，允許新員工從第一天就開始參與到工作的討論和決策中。同樣的價值觀也應該應用到與其他利益相關者的交流中。但是不要遺忘掉自身項目相關的本地技能。例如我們的企業就使用了一種自制的架構，如果一名新員工在團隊中表現良好，這就意味著他已經掌握了這個架構。
工作態度的重要性在于它對工作所產生深遠的影響。如果你有機會參與到一個高積極性、高士氣的團隊中，你將很有可能會與同事愉快共處，提出好的想法、做出最好的工作。
技能并非僅限于技術
上文中所定義的技能的范圍是非常廣泛的。還有很多技能需要從敏捷方法論、XP實踐、軟件工匠社區以及許多可能并非與軟件開發直接相關但是具有影響的事務中學習到。例如，團隊可將“嗚嘎嘎建筑師”（Ugg-Tect）這樣的嚴肅游戲作為一種趣味實踐。
在下面一節中，我們將側重于訓練的技術方面。更確切地說，我們將審視如何使用編程套路的，以及如何做到讓訓練更貼近于真實的生活。
在訓練中增添強度
當前在教練傳授和開發者學習軟件開發基礎（整潔代碼、TDD等）時，編程套路是最為廣泛使用的技術訓練內容。編程套路對于軟件開發基礎而言存在價值，但在面對挑戰性的情景時卻很少夠用，例如緊迫情景（例如達成最后期限、發布日期等），或是關鍵情景（例如在沒有測試或僅是做了遺留測試的情況下，修正大型遺留代碼庫中的軟件問題）。
不幸的是，很多開發者在面對激烈挑戰時的第一反應是努力去盡快完成。但是在沒有做好準備情況下就增加開發的速度，這將對工作的質量產生消極的影響。一些開發者將他們的開發工作看作是一種藝術而非績效問題。實際上軟件開發兩者皆是。當在訓練中增添強度之后，你就能適應挑戰的出現，并將克服挑戰去交付高質量的解決方案。
下面讓我們看一下看如何才能做到。
學習一項新技能有三個階段：
- 學習基礎知識，
- 協調性，
- 強度。
一定要確認在邁入到下一階段前，已達成了本階段的目標。
以重構為例
下面以重構問題為例去實施我們的訓練計劃。
學習基礎知識
第一步，你首先應該知道重構問題的含義。什么是代碼味道？如何使用重構編目清除代碼味道？
Martin Fowler所著的《重構：改善既有代碼的設計》一書是了解重構的必讀書目。另一個值得關注的閱讀內容是Uncle Bob的文章“ 轉換優先級的前提 ”。還可在軟件匠藝社區中找到一些值得關注的文章。對于 重構的基本規則 和 重構三法則 ，Adrian Bolboaca提供了一些好文章。
一定要掌握你所使用IDE的重構編目，并學會使用IDE提供的快捷方式，這可節省時間和大腦的處理工作，還有助于避免程序錯誤。本階段的目標并非在于開發速度，而是去學會如何正確地重構，學會有助于高效重構的工具。為做到這一點，在本階段中你應該可以識別出代碼味道，使用重構編目去清除這些味道，并掌握你所使用的IDE。在訓練中可以使用編程套路。在Emily Bach所著的《 Coding Dojo Handbook 》一書中，總結了一些有意思的編程套路，例如Gilded Rose、Yahtzee和Racing Car。
應謹記重構是一種在維持應用行為的同時，通過完成小規模的“自動”轉化而改進代碼和架構的過程。在重構的訓練項目中，應始終將全局情況牢記于心。
協調性
第二個訓練階段是將在第一階段中所學到的內容協調地應用于新的編程套路或自身項目中。例如，你可以去嘗試使用Sandro Mancuso所定義的Trip Service編程討論、J.B. Rainsberger所定義的Trivia編程套路，或是應用 mikado方法 。本階段中需要你去熟悉IDE中的所有重構特性。你會有信心去將雜亂代碼轉換為整潔代碼，并將此應用到新的編程套路和在開發的項目中。
強度
第三個階段是增添強度。在這個階段開始前，你必須達到對練習得心應手，可以高質量地完成練習，并多少有些精通的感覺。一旦達到了這些要求，你就可以著手去改進開發速度。
你可通過重構復雜代碼實現強度。一個增添強度的方法是改進完成編碼套路所需的時間。在這種情況下，要勇于將你的工作與其他開發者的工作做對比。看上去 BeFaster 網站給出了一種好的績效比較方法，并可學到他人的快速開發方法。另一個小竅門是觀看那些受到青睞的開發者實戰。 油Tube的Codurance 頻道 中包含了一些有意思的截屏錄像，建議每個開發者都應該看一下。記住，如果改進開發速度導致了軟件錯誤，那么速度的改進將毫無意義。應總是將軟件質量置于開發速度之上。
實踐軟件開發的工具
同行間的會面、觀點分享和想法交換是改進軟件開發的一個重要方式，也是建議、想法和反饋的一個很好來源。當然，是否采納新發現取決于你自身。
本地聚合和活動
全球Coderetreat日于每年的十月召開，是年度全球開發者聚會。可以通過網站了解更多關于該活動的信息，看看是否在你附近舉辦了聚會。如果沒有，要勇于去組織一次聚會。這是非常棒的事情！在網站上有很多對你有所幫助的資料。
你可在自己的城市中去尋找聚會。聚會是接觸其它有才華開發者的絕好機會，從新成員那里學習，并享受這種樂趣。
在公司內部組織培訓項目
在午餐時間或是工作日之外，你可以和同事組織一場時長60到90分鐘的會議。這是一種很好的編程討論方式，可在安全氛圍中開展有意義的討論。
最后，我們強烈推薦在團隊中至少每周組織一次mob編程培訓項目。在其中不要使用編程套路。使用你的生產代碼就可很好地分享理念，并可以激勵團隊成員間的凝聚力。
個體培訓
個體培訓從練習開始，編程套路完全適用于此。本文中已經給出了一些編程討論。但是謹記，為獲取知識你必須反復練習直至養成習慣（最好是養成下意識的反射）。不要嫌多次重復編程套路是個麻煩。
如果想要學會一個新的編程語言，你每年至少要使用上一次。對此 Exercicsm.io 網站給出了一個很好起始點。該網站提供了一些按復雜度排序的練習，并提供了相應的單元測試。
如果你想在代碼練習中得到樂趣，可以嘗試一下 CodinGame 網站。該網站通過對真實項目最終期限的模擬實現訓練強度的增添，其中一個很好的例子就是“Clashes of Code”游戲。還可通過解答智力游戲獲得樂趣，這些智力游戲的挑戰不僅來自于時間上的壓力，而且更多的是來自于所需解決問題的內在復雜性。CodinGame還組織了競賽，競賽中對需解決的問題會保密至競賽開始。該競賽給出了排行榜。在CodinGame競賽中出人頭地，你必須能編寫出整潔且高效的代碼。
使用度量改進編程技能
開發者與度量間有著復雜的關聯。度量早已被開發者使用，尤其是在面對績效問題時。這里開發者所達成的共識是，如果沒有一些類型的度量做測定，績效問題的處理工作就非常像是博彩，只能憑運氣取勝。
另一方面，有非常多的度量和KPI會令開發者生厭，例如工時單和甘特表。這些被開發者看成是用于監管和控制的，或是用做炫耀目的的。正因為這個原因，當你和開發者探討度量時，大家相互之間總是會存在著猜疑心。
將度量作為工具
從本質上講，度量應該是一個幫助你去做決策的日常工具。開發者是工程師，使用嚴謹科學的方法是一件正常的事情。如果你并未深刻理解你的起始點和目標所在，將不能有效地和持續地做事。度量的確是一個有助于你獲悉自身狀況的好工具。
一個使用度量的例子
例如，為改進你的IDE技能，一個做法是盡最大可能使用鍵盤快捷鍵。你可按如下過程去做：
- 第一步當然是學會這些快捷鍵。但這是不夠的，因為如果不使用它們，你的技能并不會真正地提高。為實現對此技能的測定，你必須要跟蹤自己的進展。
- 第二步是設置一個度量。對于本例而言，度量可以是未使用和使用了快捷鍵間的比例。
- 最后一步是去使用該度量。你可以定義一個目標觀察進展情況。
使用這個方法，你可基于目標事實觀察到IDE技能缺失問題的改進情況。相比于“跟著感覺走”的方法，你將能在目標達成中感受到更多的個人滿足感。這里順便說句題外話，IntelliJ的Key Promoter插件和生產力指導工具為這類實驗提供了很多的便利。
說服經理為你提供改進時間
說服經理為你提供時間并非一件易事。培訓是一種好的實踐，這是幾乎所有管理者在某種程度上所具有的共識，但是工作積壓的壓力常導致他們做出短期考慮的反應。學習新技能常被管理者作為那一類低優先級的任務。導致該問題的另一方面在于企業困境，這種困境可描述為CFO與CEO間的如下對話。
CFO：“如果我們培訓了員工而員工又辭職了，那會發生什么？”
CEO：“如果我們不去培訓員工而員工又留下來，那會發生什么？”
我們如何去打破這樣的現象？對此并沒有放之四海而皆準的解決方案，這取決于情境，并與很多因素（管理者、企業文化等）相關。那么我們應該如何做呢？
分享共同的心態
解決方法的第一部分是提醒你的經理，產品反映了一個團隊。產品是團隊的直接產出，因而具有更多技能的員工才會開發更好的產品。培訓是一個雙贏的情況。可以通過因特網搜索關鍵詞“團隊就是產品”去尋找令人信服的論據。
建立你的例證
在尋求經理的支持時，可以通過引用經理的話去建立你的例證。讓經理更輕松地理解你的訴求的正確性。你的經理可能將會使用你的論據去向他的經理論證你所提出的論點。
精益問題解決過程是一種通用工具。它有助于構建請求。該工具可用如下的四個迭代步驟進行描述：
- 問題描述：問題是什么？
- 揭示問題不得到解決會導致什么后果：問題的重要性是什么？
- 找出假定的導致原因：根本原因是什么？
- 通過對解決方案的實驗進行確認：解決方案是什么？
如此，你首先必須要回溯并思考這項技能：它為什么很重要？對于業務來說有什么潛在的問題？通過陳述對客戶、團隊及自身的影響，你可以更生動地把問題陳述出來。如果能給出度量就更好了，這是一個加分項。經理們都喜歡事實。
這里給出一個遵循上述四個步驟的請求例子，就是“在過去的Y周中，我們收到了由客戶提出的與數據庫相關的X個軟件問題，因此團隊必須花費Z天去解決這些問題。導致問題的原因是我們的存儲過程不支持我們客戶實際及未來的業務增長。我們并不具有開發穩定存儲過程的技能。基于此，我建議我們對該問題做培訓上的投資。”
有這樣的工具在手，就能輕易地說服經理。
讓培訓物有所值
你得到培訓時間只是一個開端。為充分利用培訓，你一定要好好組織一下培訓項目。如果你的經理能從中看到比較好的結果，你將更有可能得到做下一次培訓的時間。
結論
本文討論了如何在軟件開發中改進開發速度和質量。軟件開發被一些開發者看成是一種藝術而非績效問題，在我們看來兩者皆是。但是與軟件開發的藝術相比，績效問題卻很少得到探討，并總是被作為是一種禁忌話題。大多數開發者都反感談及開發速度，乃至度量或指標。本文中，我們力圖去打破這個禁忌，分享我們對于開發速度的想法。我們希望本文及關于這些問題的演講將可有助于給出對這個爭議性話題的有效探討。
來自：http://www.infoq.com/cn/articles/skills-better-developer