摘要：自動(dòng)化缺陷跟蹤工具生產(chǎn)率，質(zhì)量先說(shuō)一個(gè)問(wèn)題，開(kāi)發(fā)人員總是愛(ài)爭(zhēng)執(zhí)哪個(gè)缺陷跟蹤系統(tǒng)最好，這里的根本問(wèn)題在于，幾乎每個(gè)缺陷跟蹤系統(tǒng)設(shè)置不好都會(huì)導(dǎo)致糟糕的結(jié)果。

開(kāi)發(fā)人員很容易迷戀上工具，因?yàn)楣ぞ咄ǔ１容^實(shí)用，而且具備明確定義的行為，比起學(xué)習(xí)最佳實(shí)踐或方法，學(xué)習(xí)工具更為簡(jiǎn)單。然而，工具僅僅為解決問(wèn)題提供協(xié)助，他們并不能自行解決問(wèn)題。

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

　　一位理解問(wèn)題實(shí)質(zhì)的開(kāi)發(fā)人員能夠使用工具提高生產(chǎn)率和質(zhì)量，而拙劣的程序員從來(lái)不投入時(shí)間或精力去理解如何更好的編程和如何避免缺陷，他們會(huì)花時(shí)間學(xué)習(xí)如何使用工具，但這種學(xué)習(xí)方式脫離了對(duì)工具目標(biāo)以及如何高效使用的正確理解。

　　在某種程度上說(shuō)，這其中有一部分是工具供應(yīng)商的錯(cuò)，他們嗅到了為一些普遍問(wèn)題提供支持是一條財(cái)路，比如說(shuō)：

　　*缺陷追蹤器，幫助你進(jìn)行缺陷追蹤管理

　　*版本控制系統(tǒng)，管理源代碼更改

　　*敏捷開(kāi)發(fā)支持工具(Version One, JIRA)

　　*調(diào)試器，幫助你尋找缺陷

　　市面上有很多工具，但在這里我僅僅瀏覽一下下面的列表，同時(shí)指出在哪些地方開(kāi)發(fā)人員和組織正在經(jīng)受挑戰(zhàn)。記住，以下所有的統(tǒng)計(jì)數(shù)據(jù)都來(lái)源于40多年間的超過(guò)15000個(gè)項(xiàng)目。

　　一些公司還沒(méi)有用過(guò)缺陷跟蹤軟件，不管你信不信，我反正是信了，我遇到過(guò)這樣幾個(gè)奇葩公司，你一定覺(jué)得難以置信吧。沒(méi)有缺陷跟蹤軟件的結(jié)果是相當(dāng)杯具的，我們有證據(jù)證實(shí)。 歡迎加入全棧開(kāi)發(fā)交流劃水交流圈：582735936
面向劃水1-3年前端人員
幫助突破劃水瓶頸，提升思維能力

　　不充分的缺陷跟蹤方法：生產(chǎn)率 -15%，質(zhì)量 -21%

就此我們達(dá)成了高度共識(shí)，那就是我們需要進(jìn)行缺陷跟蹤，并且我們都清楚，離開(kāi)了這類工具，管理大量缺陷是不可能的。

　　自動(dòng)化缺陷跟蹤工具：生產(chǎn)率 +18%，質(zhì)量 26%*

　　先說(shuō)一個(gè)問(wèn)題，開(kāi)發(fā)人員總是愛(ài)爭(zhēng)執(zhí)哪個(gè)缺陷跟蹤系統(tǒng)最好，這里的根本問(wèn)題在于，幾乎每個(gè)缺陷跟蹤系統(tǒng)設(shè)置不好都會(huì)導(dǎo)致糟糕的結(jié)果。實(shí)際上，如果每個(gè)缺陷跟蹤系統(tǒng)都能進(jìn)行合理配置的話，結(jié)果都會(huì)大有裨益。這里最常見(jiàn)的誤區(qū)是：

　　*在缺陷生命周期狀態(tài)中引入了不相關(guān)屬性，即創(chuàng)建諸如”延期“, ”無(wú)法解決“或 ”已設(shè)計(jì)的功能“這樣的狀態(tài)。

　　*無(wú)法指出問(wèn)題是否已被修復(fù)。

　　*無(wú)法理解誰(shuí)負(fù)責(zé)解決缺陷。

　　工具的供應(yīng)商非常樂(lè)意繼續(xù)提供這些缺陷跟蹤器的新版本，然而要高效地使用缺陷跟蹤器，更多的是取決于如何使用好這個(gè)工具，而非選擇哪一種工具。

　　很多公司都在設(shè)法解決的一個(gè)最基本的問(wèn)題是：如何定義缺陷？缺陷通常是指代碼沒(méi)有遵照規(guī)范工作，但是假設(shè)我們沒(méi)有規(guī)范或規(guī)范很爛，那又會(huì)如何？你可以看一下《It’s not a bug, it’s…》獲取更多信息。

　　聰明的公司知道，是否理解缺陷跟蹤器的工作方式會(huì)帶來(lái)很大不同，你可以在《Bug Tracker Hell and How to Get Out》中找到更多缺陷跟蹤系統(tǒng)的周邊知識(shí)。

　　另一個(gè)普遍的問(wèn)題是，公司通常會(huì)嘗試在缺陷跟蹤系統(tǒng)中管理新功能和需求，畢竟無(wú)論是需求還是缺陷都會(huì)導(dǎo)致代碼變動(dòng)，那么為什么不將所有信息都放到缺陷跟蹤器中呢？你可以在《Don’t manage enhancements in the bug tracker》中學(xué)到為什么在缺陷跟蹤系統(tǒng)中管理需求和新功能是愚蠢的。

　　和缺陷控制系統(tǒng)一樣，大部分開(kāi)發(fā)人員都將版本控制視為是一個(gè)必須的“保健”過(guò)程，如果離開(kāi)它，你就可能換上嚴(yán)重疾病（在最不合適的時(shí)間）。

　　不充分的變動(dòng)控制：生產(chǎn)率 -11%，質(zhì)量 -16%
其實(shí)，所有的程序員都不喜歡版本控制系統(tǒng)，并且他們會(huì)相當(dāng)直言不諱地指出版本控制系統(tǒng)所不能做到的事情。如果你很不幸，需要拍板最后用哪個(gè)版本控制系統(tǒng)，那么就寬慰一下自己吧，你的背后一定會(huì)有成群結(jié)隊(duì)的家伙在詛咒你。

　　版本控制只是個(gè)開(kāi)始，與選擇哪個(gè)版本控制系統(tǒng)相比，理解如何組織代碼、集成持續(xù)構(gòu)建技術(shù)、確保缺陷對(duì)應(yīng)正確的版本，這些也同樣重要。

　　很抱歉，對(duì)于Version One和JIRA，至簡(jiǎn)的真理是，使用敏捷開(kāi)發(fā)工具并不能讓你變得敏捷，看這里。

　　當(dāng)你真正理解敏捷開(kāi)發(fā)的時(shí)候，你才能將這些工具的作用最大化，我有一個(gè)最高效的敏捷開(kāi)發(fā)實(shí)現(xiàn)僅僅用到了Google Docs而已。

　　毋庸贅言。

　　我已經(jīng)寫了大量的文章，說(shuō)明為什么調(diào)試器不是跟蹤缺陷的最好工具，所以這里我會(huì)換一種說(shuō)法！

　　在軟件工程領(lǐng)域，最經(jīng)久不衰的比率是1：10：100。也就是說(shuō)，如果在測(cè)試前就能跟蹤缺陷（即QA前）的成本為1的話，那么在QA階段發(fā)現(xiàn)缺陷的成本就是10倍，如果在部署的時(shí)候被你的客戶發(fā)現(xiàn)了，成本就是100倍，而大部分調(diào)試器在整個(gè)過(guò)程的10倍至100倍階段才會(huì)被使用。

　　這并不是說(shuō)我不喜歡調(diào)試器，我只是相信所謂的預(yù)先測(cè)試消除缺陷策略，因?yàn)樗某杀竞艿停帜鼙ＷC高質(zhì)量，預(yù)先測(cè)試消除缺陷策略包括：

　　規(guī)劃代碼，即PSP

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，TDD

契約式設(shè)計(jì)，DbC

代碼審查

對(duì)復(fù)雜代碼段進(jìn)行結(jié)對(duì)編程

　　你可以在下面找到更多信息：

　　Defects are for Losers

　　Not planning is for Losers

　　Debuggers are for Losers

　　Are debuggers crutches

　　以下這些工具能夠帶來(lái)巨大的不同，但是很多開(kāi)發(fā)人員卻不用它們：

　　自動(dòng)化靜態(tài)分析：生產(chǎn)率 +21%，質(zhì)量 +31%

自動(dòng)化單元測(cè)試：生產(chǎn)率 +17%，質(zhì)量 +24%

　　自動(dòng)化單元測(cè)試經(jīng)常在測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）或數(shù)據(jù)驅(qū)動(dòng)開(kāi)發(fā)中引入，同時(shí)伴隨著持續(xù)開(kāi)發(fā)技術(shù)。

　　自動(dòng)化功能點(diǎn)分級(jí)：生產(chǎn)率 +17%，質(zhì)量 +24%

自動(dòng)化質(zhì)量與風(fēng)險(xiǎn)預(yù)測(cè)：生產(chǎn)率 +16%，質(zhì)量 +23%

自動(dòng)化測(cè)試覆蓋率分析：生產(chǎn)率 +15%，質(zhì)量 +21%

自動(dòng)化部署支持：生產(chǎn)率 +15%，質(zhì)量 +20%

自動(dòng)化圈復(fù)雜度計(jì)算：生產(chǎn)率 +15%，質(zhì)量 +20%

　　我們還有一些軟件開(kāi)發(fā)的重要技術(shù)存在，但是那些工具供應(yīng)商還沒(méi)有找到賺錢的方式。這些技術(shù)往往被大多數(shù)開(kāi)發(fā)人員忽略，即便它們能在生產(chǎn)率和質(zhì)量上帶來(lái)巨大改變。

　　個(gè)人軟件過(guò)程和團(tuán)隊(duì)軟件過(guò)程是由Watts Humphrey建立的，他是致力于構(gòu)建高質(zhì)量軟件產(chǎn)品的先驅(qū)。

　　個(gè)人軟件過(guò)程：生產(chǎn)率 +21%，質(zhì)量 +31%

團(tuán)隊(duì)軟件過(guò)程：生產(chǎn)率 +21%，質(zhì)量 +31%

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

　　Inspections are not Optional

　　Software Professionals do Inspections

　　代碼審查：生產(chǎn)率 +21%，質(zhì)量 +31%

需求審查：生產(chǎn)率 +18%，質(zhì)量 +27%

正式的測(cè)試計(jì)劃：生產(chǎn)率 +17%，質(zhì)量 +24%

功能點(diǎn)分析（IFPUG）：生產(chǎn)率 +16%，質(zhì)量 +22%

　　肯定是一大群開(kāi)發(fā)人員認(rèn)為使用工具能夠使他們變得更給力。

　　但現(xiàn)實(shí)是，如果你脫離了對(duì)所要解決問(wèn)題的實(shí)質(zhì)的學(xué)習(xí)，僅僅去學(xué)一門工具的話，那就像你覺(jué)得你能夠在籃球場(chǎng)上贏下喬丹，僅僅因?yàn)槟銚碛幸浑p好的跑鞋。
學(xué)習(xí)工具并不能取代學(xué)習(xí)如何把一件事情做好。

　　真正給力的開(kāi)發(fā)人員會(huì)持續(xù)學(xué)習(xí)那些能帶來(lái)更高生產(chǎn)率和質(zhì)量的技術(shù)，無(wú)論這門技術(shù)是不是有工具支持。