不要成爲工具的奴隸

開發人員很容易迷戀上工具，由於工具一般比較實用，並且具有明肯定義的行爲，比起學習最佳實踐或方法，學習工具更爲簡單。然而，工具僅僅爲解決問題提供協助，他們並不能自行解決問題。

![]/14004175-eaa991ecfe12f86c.JPG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

　　一位理解問題實質的開發人員可以使用工具提升生產率和質量，而拙劣的程序員歷來不投入時間或精力去理解如何更好的編程和如何避免缺陷，他們會花時間學習如何使用工具，但這種學習方式脫離了對工具目標以及如何高效使用的正確理解。

　　在某種程度上說，這其中有一部分是工具供應商的錯，他們嗅到了爲一些廣泛問題提供支持是一條財路，好比說：

　　*缺陷追蹤器，幫助你進行缺陷追蹤管理

　　*版本控制系統，管理源代碼更改

　　*敏捷開發支持工具(Version One, JIRA)

　　*調試器，幫助你尋找缺陷

　　市面上有不少工具，但在這裏我僅僅瀏覽一下下面的列表，同時指出在哪些地方開發人員和組織正在經受挑戰。記住，如下全部的統計數據都來源於40多年間的超過15000個項目。

　缺陷跟蹤器

　　一些公司尚未用過缺陷跟蹤軟件，無論你信不信，我反正是信了，我遇到過這樣幾個奇葩公司，你必定以爲難以置信吧。沒有缺陷跟蹤軟件的結果是至關杯具的，咱們有證據證明。 歡迎加入全棧開發交流划水交流圈：582735936
面向划水1-3年前端人員
幫助突破划水瓶頸，提高思惟能力

　　不充分的缺陷跟蹤方法：生產率 -15%，質量 -21%

就此咱們達成了高度共識，那就是咱們須要進行缺陷跟蹤，而且咱們都清楚，離開了這類工具，管理大量缺陷是不可能的。

　　自動化缺陷跟蹤工具：生產率 +18%，質量 26%*

　　先說一個問題，開發人員老是愛爭執哪一個缺陷跟蹤系統最好，這裏的根本問題在於，幾乎每一個缺陷跟蹤系統設置很差都會致使糟糕的結果。實際上，若是每一個缺陷跟蹤系統都能進行合理配置的話，結果都會大有裨益。這裏最多見的誤區是：

　　*在缺陷生命週期狀態中引入了不相關屬性，即建立諸如」延期「, 」沒法解決「或 」已設計的功能「這樣的狀態。

　　*沒法指出問題是否已被修復。

　　*沒法理解誰負責解決缺陷。

　　工具的供應商很是樂意繼續提供這些缺陷跟蹤器的新版本，然而要高效地使用缺陷跟蹤器，更多的是取決於如何使用好這個工具，而非選擇哪種工具。

　　不少公司都在設法解決的一個最基本的問題是：如何定義缺陷？缺陷一般是指代碼沒有遵守規範工做，可是假設咱們沒有規範或規範很爛，那又會如何？你能夠看一下《It’s not a bug, it’s…》獲取更多信息。

　　聰明的公司知道，是否理解缺陷跟蹤器的工做方式會帶來很大不一樣，你能夠在《Bug Tracker Hell and How to Get Out》中找到更多缺陷跟蹤系統的周邊知識。

　　另外一個廣泛的問題是，公司一般會嘗試在缺陷跟蹤系統中管理新功能和需求，畢竟不管是需求仍是缺陷都會致使代碼變更，那麼爲何不將全部信息都放到缺陷跟蹤器中呢？你能夠在《Don’t manage enhancements in the bug tracker》中學到爲何在缺陷跟蹤系統中管理需求和新功能是愚蠢的。

　版本控制系統

　　和缺陷控制系統同樣，大部分開發人員都將版本控制視爲是一個必須的「保健」過程，若是離開它，你就可能換上嚴重疾病（在最不合適的時間）。

　　不充分的變更控制：生產率 -11%，質量 -16%
其實，全部的程序員都不喜歡版本控制系統，而且他們會至關直言不諱地指出版本控制系統所不能作到的事情。若是你很不幸，須要拍板最後用哪一個版本控制系統，那麼就寬慰一下本身吧，你的背後必定會有三五成羣的傢伙在詛咒你。

　　版本控制只是個開始，與選擇哪一個版本控制系統相比，理解如何組織代碼、集成持續構建技術、確保缺陷對應正確的版本，這些也一樣重要。

　敏捷開發支持工具

　　很抱歉，對於Version One和JIRA，至簡的真理是，使用敏捷開發工具並不能讓你變得敏捷，看這裏。

　　當你真正理解敏捷開發的時候，你才能將這些工具的做用最大化，我有一個最高效的敏捷開發實現僅僅用到了Google Docs而已。

　　毋庸贅言。

　調試器

　　我已經寫了大量的文章，說明爲何調試器不是跟蹤缺陷的最好工具，因此這裏我會換一種說法！

　　在軟件工程領域，最經久不衰的比率是1：10：100。也就是說，若是在測試前就能跟蹤缺陷（即QA前）的成本爲1的話，那麼在QA階段發現缺陷的成本就是10倍，若是在部署的時候被你的客戶發現了，成本就是100倍，而大部分調試器在整個過程的10倍至100倍階段纔會被使用。

　　這並非說我不喜歡調試器，我只是相信所謂的預先測試消除缺陷策略，由於它的成本很低，又能保證高質量，預先測試消除缺陷策略包括：

　　規劃代碼，即PSP

測試驅動開發，TDD

契約式設計，DbC

代碼審查

對複雜代碼段進行結對編程

　　你能夠在下面找到更多信息：

　　Defects are for Losers

　　Not planning is for Losers

　　Debuggers are for Losers

　　Are debuggers crutches

　不多用到的工具

　　如下這些工具可以帶來巨大的不一樣，可是不少開發人員卻不用它們：

　　自動化靜態分析：生產率 +21%，質量 +31%

自動化單元測試：生產率 +17%，質量 +24%

　　自動化單元測試常常在測試驅動開發（TDD）或數據驅動開發中引入，同時伴隨着持續開發技術。

　　自動化功能點分級：生產率 +17%，質量 +24%

自動化質量與風險預測：生產率 +16%，質量 +23%

自動化測試覆蓋率分析：生產率 +15%，質量 +21%

自動化部署支持：生產率 +15%，質量 +20%

自動化圈複雜度計算：生產率 +15%，質量 +20%

　尚未工具支持的一些重要技術

　　咱們還有一些軟件開發的重要技術存在，可是那些工具供應商尚未找到賺錢的方式。這些技術每每被大多數開發人員忽略，即使它們能在生產率和質量上帶來巨大改變。

　　我的軟件過程和團隊軟件過程是由Watts Humphrey創建的，他是致力於構建高質量軟件產品的先驅。

　　我的軟件過程：生產率 +21%，質量 +31%

團隊軟件過程：生產率 +21%，質量 +31%

　　代碼審查的重要性能夠在下面兩篇文章中找到：

　　Inspections are not Optional

　　Software Professionals do Inspections

　　代碼審查：生產率 +21%，質量 +31%

需求審查：生產率 +18%，質量 +27%

正式的測試計劃：生產率 +17%，質量 +24%

功能點分析（IFPUG）：生產率 +16%，質量 +22%

　總結

　　確定是一大羣開發人員認爲使用工具可以使他們變得更給力。

　　但現實是，若是你脫離了對所要解決問題的實質的學習，僅僅去學一門工具的話，那就像你以爲你可以在籃球場上贏下喬丹，僅僅由於你擁有一雙好的跑鞋。
學習工具並不能取代學習如何把一件事情作好。

　　真正給力的開發人員會持續學習那些能帶來更高生產率和質量的技術，不管這門技術是否是有工具支持。