開發(fā)人員很容易迷戀上工具，因為工具通常比較實用涧狮，而且具備明確定義的行為锭汛，比起學(xué)習(xí)最佳實踐或方法，學(xué)習(xí)工具更為簡單假夺。然而，工具僅僅為解決問題提供協(xié)助斋攀，他們并不能自行解決問題已卷。
![]/14004175-eaa991ecfe12f86c.JPG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
一位理解問題實質(zhì)的開發(fā)人員能夠使用工具提高生產(chǎn)率和質(zhì)量，而拙劣的程序員從來不投入時間或精力去理解如何更好的編程和如何避免缺陷淳蔼，他們會花時間學(xué)習(xí)如何使用工具侧蘸，但這種學(xué)習(xí)方式脫離了對工具目標(biāo)以及如何高效使用的正確理解裁眯。
在某種程度上說，這其中有一部分是工具供應(yīng)商的錯讳癌，他們嗅到了為一些普遍問題提供支持是一條財路穿稳，比如說：
*缺陷追蹤器，幫助你進行缺陷追蹤管理
*版本控制系統(tǒng)晌坤，管理源代碼更改
*敏捷開發(fā)支持工具(Version One, JIRA)
*調(diào)試器逢艘，幫助你尋找缺陷
市面上有很多工具，但在這里我僅僅瀏覽一下下面的列表骤菠，同時指出在哪些地方開發(fā)人員和組織正在經(jīng)受挑戰(zhàn)它改。記住，以下所有的統(tǒng)計數(shù)據(jù)都來源于40多年間的超過15000個項目商乎。
缺陷跟蹤器
一些公司還沒有用過缺陷跟蹤軟件央拖，不管你信不信，我反正是信了鹉戚，我遇到過這樣幾個奇葩公司鲜戒，你一定覺得難以置信吧。沒有缺陷跟蹤軟件的結(jié)果是相當(dāng)杯具的抹凳，我們有證據(jù)證實袍啡。
不充分的缺陷跟蹤方法：生產(chǎn)率 -15%，質(zhì)量 -21%
就此我們達成了高度共識却桶，那就是我們需要進行缺陷跟蹤境输，并且我們都清楚，離開了這類工具颖系，管理大量缺陷是不可能的嗅剖。
自動化缺陷跟蹤工具：生產(chǎn)率 +18%，質(zhì)量 26%*
先說一個問題嘁扼，開發(fā)人員總是愛爭執(zhí)哪個缺陷跟蹤系統(tǒng)最好信粮，這里的根本問題在于，幾乎每個缺陷跟蹤系統(tǒng)設(shè)置不好都會導(dǎo)致糟糕的結(jié)果趁啸。實際上强缘，如果每個缺陷跟蹤系統(tǒng)都能進行合理配置的話，結(jié)果都會大有裨益不傅。這里最常見的誤區(qū)是：
*在缺陷生命周期狀態(tài)中引入了不相關(guān)屬性旅掂，即創(chuàng)建諸如”延期“, ”無法解決“或 ”已設(shè)計的功能“這樣的狀態(tài)。
*無法指出問題是否已被修復(fù)访娶。
*無法理解誰負(fù)責(zé)解決缺陷商虐。
工具的供應(yīng)商非常樂意繼續(xù)提供這些缺陷跟蹤器的新版本，然而要高效地使用缺陷跟蹤器，更多的是取決于如何使用好這個工具秘车，而非選擇哪一種工具典勇。
很多公司都在設(shè)法解決的一個最基本的問題是：如何定義缺陷？缺陷通常是指代碼沒有遵照規(guī)范工作叮趴，但是假設(shè)我們沒有規(guī)范或規(guī)范很爛割笙，那又會如何？你可以看一下《It’s not a bug, it’s…》獲取更多信息眯亦。
聰明的公司知道伤溉，是否理解缺陷跟蹤器的工作方式會帶來很大不同，你可以在《Bug Tracker Hell and How to Get Out》中找到更多缺陷跟蹤系統(tǒng)的周邊知識搔驼。
另一個普遍的問題是谈火，公司通常會嘗試在缺陷跟蹤系統(tǒng)中管理新功能和需求侈询，畢竟無論是需求還是缺陷都會導(dǎo)致代碼變動舌涨，那么為什么不將所有信息都放到缺陷跟蹤器中呢？你可以在《Don’t manage enhancements in the bug tracker》中學(xué)到為什么在缺陷跟蹤系統(tǒng)中管理需求和新功能是愚蠢的扔字。
版本控制系統(tǒng)
和缺陷控制系統(tǒng)一樣囊嘉，大部分開發(fā)人員都將版本控制視為是一個必須的“保健”過程，如果離開它革为，你就可能換上嚴(yán)重疾才ち弧（在最不合適的時間）。
不充分的變動控制：生產(chǎn)率 -11%震檩，質(zhì)量 -16%
其實琢蛤，所有的程序員都不喜歡版本控制系統(tǒng)，并且他們會相當(dāng)直言不諱地指出版本控制系統(tǒng)所不能做到的事情抛虏。如果你很不幸博其，需要拍板最后用哪個版本控制系統(tǒng)，那么就寬慰一下自己吧迂猴，你的背后一定會有成群結(jié)隊的家伙在詛咒你慕淡。
版本控制只是個開始，與選擇哪個版本控制系統(tǒng)相比沸毁，理解如何組織代碼峰髓、集成持續(xù)構(gòu)建技術(shù)、確保缺陷對應(yīng)正確的版本息尺，這些也同樣重要携兵。
敏捷開發(fā)支持工具
很抱歉，對于Version One和JIRA搂誉，至簡的真理是眉孩，使用敏捷開發(fā)工具并不能讓你變得敏捷，看這里。
當(dāng)你真正理解敏捷開發(fā)的時候浪汪，你才能將這些工具的作用最大化巴柿，我有一個最高效的敏捷開發(fā)實現(xiàn)僅僅用到了Google Docs而已。
毋庸贅言死遭。
調(diào)試器
我已經(jīng)寫了大量的文章广恢，說明為什么調(diào)試器不是跟蹤缺陷的最好工具，所以這里我會換一種說法呀潭！
在軟件工程領(lǐng)域钉迷，最經(jīng)久不衰的比率是1：10：100。也就是說钠署，如果在測試前就能跟蹤缺陷（即QA前）的成本為1的話糠聪，那么在QA階段發(fā)現(xiàn)缺陷的成本就是10倍，如果在部署的時候被你的客戶發(fā)現(xiàn)了谐鼎，成本就是100倍舰蟆，而大部分調(diào)試器在整個過程的10倍至100倍階段才會被使用。
這并不是說我不喜歡調(diào)試器狸棍，我只是相信所謂的預(yù)先測試消除缺陷策略身害，因為它的成本很低，又能保證高質(zhì)量草戈，預(yù)先測試消除缺陷策略包括：
規(guī)劃代碼塌鸯，即PSP
測試驅(qū)動開發(fā)，TDD
契約式設(shè)計唐片，DbC
代碼審查
對復(fù)雜代碼段進行結(jié)對編程
你可以在下面找到更多信息：
很少用到的工具
以下這些工具能夠帶來巨大的不同丙猬，但是很多開發(fā)人員卻不用它們：
自動化靜態(tài)分析：生產(chǎn)率 +21%，質(zhì)量 +31%
自動化單元測試：生產(chǎn)率 +17%费韭，質(zhì)量 +24%
自動化單元測試經(jīng)常在測試驅(qū)動開發(fā)（TDD）或數(shù)據(jù)驅(qū)動開發(fā)中引入茧球，同時伴隨著持續(xù)開發(fā)技術(shù)。
自動化功能點分級：生產(chǎn)率 +17%揽思，質(zhì)量 +24%
自動化質(zhì)量與風(fēng)險預(yù)測：生產(chǎn)率 +16%袜腥，質(zhì)量 +23%
自動化測試覆蓋率分析：生產(chǎn)率 +15%，質(zhì)量 +21%
自動化部署支持：生產(chǎn)率 +15%钉汗，質(zhì)量 +20%
自動化圈復(fù)雜度計算：生產(chǎn)率 +15%羹令，質(zhì)量 +20%
還沒有工具支持的一些重要技術(shù)
我們還有一些軟件開發(fā)的重要技術(shù)存在，但是那些工具供應(yīng)商還沒有找到賺錢的方式损痰。這些技術(shù)往往被大多數(shù)開發(fā)人員忽略福侈，即便它們能在生產(chǎn)率和質(zhì)量上帶來巨大改變。
個人軟件過程和團隊軟件過程是由Watts Humphrey建立的卢未，他是致力于構(gòu)建高質(zhì)量軟件產(chǎn)品的先驅(qū)肪凛。
個人軟件過程：生產(chǎn)率 +21%堰汉，質(zhì)量 +31%
團隊軟件過程：生產(chǎn)率 +21%，質(zhì)量 +31%
代碼審查的重要性可以在下面兩篇文章中找到：
Software Professionals do Inspections
代碼審查：生產(chǎn)率 +21%伟墙，質(zhì)量 +31%
需求審查：生產(chǎn)率 +18%翘鸭，質(zhì)量 +27%
正式的測試計劃：生產(chǎn)率 +17%，質(zhì)量 +24%
功能點分析（IFPUG）：生產(chǎn)率 +16%戳葵，質(zhì)量 +22%
總結(jié)
肯定是一大群開發(fā)人員認(rèn)為使用工具能夠使他們變得更給力就乓。
但現(xiàn)實是，如果你脫離了對所要解決問題的實質(zhì)的學(xué)習(xí)拱烁，僅僅去學(xué)一門工具的話生蚁，那就像你覺得你能夠在籃球場上贏下喬丹，僅僅因為你擁有一雙好的跑鞋戏自。
學(xué)習(xí)工具并不能取代學(xué)習(xí)如何把一件事情做好邦投。
真正給力的開發(fā)人員會持續(xù)學(xué)習(xí)那些能帶來更高生產(chǎn)率和質(zhì)量的技術(shù)，無論這門技術(shù)是不是有工具支持擅笔。
