代碼質量

Question

我爲一家軟件開發公司工作，我們有大約100人從事產品工作，其中1/3是質量保證。最近管理層希望有一個更好的方法來評估個別程序員的表現，所以建議使用錯誤報告作爲衡量標準。開發者的錯誤報告越多，他就越糟糕。由於更多的原因，這似乎不明智這是一種測量的主觀方式，開發人員針對不同複雜度的不同項目開展工作。另外，如果QA是根據它們生成的錯誤報告的數量來衡量的，那麼會有很多關於錯誤報告有效性的討論。

在這種環境下衡量開發人員的表現會更好嗎？

一個建議是不使用QA的bug報告作爲衡量標準，而是使用外部的bug報告，比如beta測試者，那麼當發佈這樣的公共bug報告時，也要讓QA測量它。

編輯：＃1讀取你的一些優秀的回答，我在想，用上述的一般問題描述度量之後是它是負面報道的錯誤 - 它不鼓勵生產優質的代碼。

編輯：＃2我認爲問題在於它是兩個世界。一方面有非程序員將程序員視爲基本的工作人員，他們希望優先使用度量標準/分鐘。然後，我們有程序員，誰想要看自己是藝術家或工匠，「請不要打擾我，我是C - O - D - I - N - 克」:)我不認爲測量質量可以通過指標來完成，而不是沒有適得其反。相反，一個人對錯誤，改變意願，創造力以及高於一切工作質量的反應是重要的，但大多不一定是可衡量的。

Answer 1

試圖用錯誤報告來衡量程序員的表現是一個壞主意。然而，試圖通過幾乎any other metric來衡量性能。無論你做什麼，人們都會弄清楚如何進行遊戲並給你所測量的東西，而不會給你真正想要的東西。

從一個喬爾的other articles：

羅伯特·奧斯汀，在他的著作測量和管理組織中的表現，說，有，當你引進新的績效指標分爲兩個階段。起初，你實際上得到了你想要的東西，因爲沒有人知道如何作弊。在第二階段，你實際上會遇到更糟糕的情況，因爲每個人都會想出最大化你測量的事情的伎倆，即使是以損壞公司爲代價。

Answer 2

alt text http://i18.tinypic.com/34461wi.jpg

Answer 3

這是一個可怕的指標，你提到的原因。

此外，「外」錯誤報告也判斷開發商的不公平和不可靠的方式 - 如果有什麼一些開發商所使用比別人更多的代碼方面的工作？如果我的功能使用了我的80％的用戶，而您的使用率爲1％，那麼您認爲哪些人會看到更多的錯誤報告？

任何可以很容易被玩的指標 - 或者讓其他人被測量的獎勵來遊戲他們 - 也是可怕的。

Answer 4

，以驗證質量的唯一途徑是審查工作......並衡量什麼是審查，返工量。錯誤是事後方式測量如此---只有一個指標，但在開發過程中的評價也較好。查看一下TopCoder使用的一些指標。

Answer 5

不僅臭蟲報告是一個暗示性的措施，但它們並沒有真正的可比性。這個bug如何「大」？一個大錯誤可能比有五個小錯誤更糟...另一方面它可能不是。所以你需要了解每個bug的具體細節（這將是一場噩夢）。

你可以花多長時間來修復每個bug，但這可以很容易發揮 - 添加一個簡單的bug，快速修復，這抵消了修復一個更難的誠實善良bug的時間修理。

您可以使用lint工具和單元測試來提高代碼質量而不會受到懲罰。 lint是一個相對簡單的過程變化，隨着時間的推移你會工作（從現有代碼庫中的X警告開始，然後獎勵那些在一段時間內刪除最多警告的人 - 將其轉化爲積極的而不是負）。

單元測試是另一回事，獎勵與最少的錯誤和大多數測試（如果測試是正確寫入那麼賠率是最好的測試代碼有缺陷最少）的代碼。這對開發人員來說也是一個積極的回報和鼓舞人心的事情。測試使代碼更好，人們不會受到懲罰。

還有許多其他的像這樣的事情，但是從我的頭頂這些將有顯着的影響（和公正是衡量）對產品的質量 - 這是最終的目標。

Answer 6

最大的問題，我從外地bug報告看到的是，一個程序員可能已經設定100％，他給出的規格，然後在該領域的問題是由於不良或incomplets規格。

讓我給你舉個例子：你開發和測試在Windows Vista的32位應用程序，然後在要運行64位Windows XP的一個coustomer站點發生故障。是程序員錯了嗎（特別是如果你從未給他一臺運行XP 64位的機器來測試）？

一旦你意識到一個錯誤可能由於許多原因而出現，其中只有一部分程序員可以控制，你需要非常小心，因爲你沒有設置一個能夠指向指向和設備的環境。團隊的所有成員都需要共同努力，使產品更好，而不是花時間試圖將錯誤歸咎於別人。

不管你做什麼，不要創造一個動力系統中有人被加分證明它是別人的錯。錯誤需要被視爲由整個組織所擁有。

Answer 7

我建議你閱讀管理實施精益軟件開發：從概念到現金，由瑪麗·波彭代克和Tom Poppendieck的。他們高度不鼓勵根據指標評估開發人員的想法。他們的偏好是獎勵團隊，而不是個人。

如果這一方法不符合實際情況，我建議你（所以做他們......我想......）同行評審。不要直截了當地說，「你怎麼排名你的隊友？」，雖然。反而問：當你遇到一個你無法解決的問題時，你會去哪裏？誰爲項目提供了最佳的創意投入？等等。這些問題的答案可以爲誰最大限度地投入團隊提供更好的指導。

Answer 8

我不同意「測量錯誤計數」的概念，即使測試儀在內部或外部。

您可以使用一些關於嚴重程度的評分機制，而不是直接計算錯誤數量，即我的意思是衡量程序員的粗心大意。

說一個程序員正在寫代碼而不處理異常。這個問題比複雜算法中複雜邏輯中的錯誤要大。因此，對每個錯誤使用評估機制對於這種情況會更好。在這種情況下，每個錯誤/錯誤/錯誤將得到公平的權重，並且我們可以得到關於使用錯誤評級總和的性能的總體思想。

另一方面，這種方法也可能造成問題，因爲評級也是由人類完成的。但是有一個團隊來做這個評級會減少這些問題，並且隨着時間的推移，這個機制將會得到更多的可用性，並進行必要的改進和改變。

但它的責任是將錯誤類別分組並將它們分配給必要的權重..我認爲您不能一次執行此操作。這個「定義」也應該隨着時間的推移而變得成熟起來。:)

Answer 9

說得好克里斯。

我們在我們的辦公室有類似的問題。首席執行官和其他大型假髮不知道如何測量開發質量，他們實施了自己的測量。總計一個開發者的bug數量絕對不是衡量標準。我不知道是否有完美的答案，但我希望我的工作能夠通過我是否符合我的最後期限和消費者反饋（他們對產品感到滿意）來衡量。

Answer 10

這個指標很糟糕，並會鼓勵真正的壞習慣和內部鬥爭，以確定是誰造成了哪個錯誤。任何度量標準都應該通過測量成功度量來抵消。編寫更多代碼的人根據定義會有更多錯誤機會。根據可用的數據，您可能希望將您的評分系統歸一化。如果一個開發人員實現了一個沒有缺陷的功能，那麼我不會以比開發人員更好的方式對他進行評估，這個開發人員實現了243個具有3個缺陷的功能。評級開發人員要求管理層放下數字並觀察每個團隊成員。積極參與的經理會了解哪些開發人員有缺陷，並會與他們合作以改善他們的表現。這實際上需要管理者的工作來幫助每個人設定目標並達成目標。

Answer 11

Answer 12

開發人員的錯誤報告是一個可怕的指標。作爲質量保證主管，我曾多次爭論過這個問題。錯誤會發生。他們如何處理這些問題更有意義。

更好的指標是開發者的bug重新開放率。換句話說，當質量檢查記錄了一個錯誤，然後修正錯誤，錯誤是否正確修正，或者錯過了一些錯誤，導致QA重新打開錯誤？

發生這種情況越頻繁，這是開發人員可能沒有真正關注該問題的線索。當然，這是假定該錯誤首先被智能地記錄下來，最好是重現步驟，實際結果，預期結果以及原因。屏幕截圖也有幫助。

顯然，這只是一個要報告的指標。其他可能性有：

• 開發者是否符合承諾的截止日期？
• 對客戶問題的反應。
• 準確的任何所需的文件。

和其他可能。

編輯：我已經完成了開發和QA，並且在我的開發過程中很幸運，沒有在評論中對我使用錯誤計數。我當前的公司在我目前的職位上反對它，因爲它是IMO不可靠的指標。我們使用重新開放率作爲妥協，讓高層管理人員（閱讀「尖頭髮型」開發總監）對他們有事要報告感到高興。我不是經理，實際上也沒有自己生成任何報告（如果這是造成一些低估的原因）。

Answer 13

我對這種評分系統的基本問題是，你最終會與你的團隊相互競爭，而不是相互合作。如果你知道你可能會支付罰款，那麼在代碼難度部分工作的動機是什麼？只需選擇不易出錯的更簡單的東西。爲什麼要幫助你的同事改善他們的代碼，這樣做會使他們受益，並可能會傷害你的評級系統。

我認爲使用同伴壓力來提高代碼質量會更好：沒有人想寫垃圾，也沒有人願意以廢話寫作而聞名。真正努力通過TDD驅動缺陷 - 或者至少通過單元測試。轉向持續集成並公佈誰破壞了構建。在創建任何新的代碼之前，讓構建者修復它的責任。像這樣的事情會提高質量。

一旦所有人都參與了質量目標，對團隊而不是個人進行評級。合作共事是一種真正的好處。如果你有懶散的人正在利用這個團隊 - 每個人都會知道他們是誰 - 與他們一起改善，如果他們不這樣做或者不能，減少你的損失並找到一個更適合團隊的人。如果你有合適的人，它可能永遠不會達到這一點。如果他們是錯誤的人，那麼你和他們都會更好地瞭解它，並且繼續更好地適應。

如果團隊中的某個人真的超越了他們，用一些額外的獎勵給他們，但要確保這是一個超越團隊其他成員的非凡努力。如果是這樣，團隊不會介意（太多），因爲他們會知道他們的共同報酬很大程度上是由於該人的努力。

顯然，以上所有內容都應視爲一般規則。雖然他們喜歡稱之爲管理科學，但它更像是一門藝術。瞭解你的團隊的動態是複雜的業務，但我認爲一般規則應該是鼓勵和獎勵團隊合作。

Answer 14

我有三兩件事要說一下：

1）誰認爲，「較高的錯誤計數==糟糕的開發者」或「...... ==更好的測試者」可能是一個更大的問題，經理您公司比任何單一的開發人員都難。這個人如何成爲關於評估開發者表現的討論的一部分？如果他們在管理開發人員，他們應該更好地瞭解。

2）爲開發到遊戲任何指標相關的bug（錯誤計數，重新打開率，正火或不按功能/ LOC /不管）就是讓自己的執行情況很難測試，因爲他們可以最簡單的方法。不可能測試意味着QA發現零錯誤。也可能無法使用，這意味着來自該領域的零錯誤報告（嗯，也許是一個）。任何錯誤計數指標都是與可測性的激勵。詢問管理層是否真的是他們想要的。3）如果他們真的實施了這個政策，就像地獄一樣運行。

Answer 15

在實施任何類型的指標之前，先問問自己......最終......您要衡量的是什麼？

- 程序員的生產力是你沒有聽？嗯

- 是啊當然..但爲什麼這很重要？

讓人蔘與指標將不可避免地嘗試爲了他們自己的目標對其進行優化，因此，知道這一點後，您應該能夠利用這種優化來獲得優勢。

• 問問自己，然後問問自己，如果有人優化指標，他們將集中在什麼？

然後直接測量成才，將積極地影響系統的指標，因此，不是測量每程序員只給彈藥管理火，如果事情變壞，試圖測量位置和原因的錯誤發生的錯誤，不是誰製造的。

因此，每個模塊的錯誤，每個版本的錯誤，每次代碼修復的錯誤，每個功能的錯誤將是更高效的指標，並且有助於識別熱點。當然，你總是可以把它與某人聯繫起來，因爲總是與程序員有間接的聯繫，但是在你把程序員放在責備戰爭的最前沿之前，你最好確保HE-SHE是原因。

• 問問自己想要創建什麼樣的環境？團隊，經理，董事面對指標出版時會有什麼反應？

如果你測量的人，並使他們看起來不好，那麼你是在要求麻煩。如果你對產品進行評估，那麼重點不會放在讓自己看起來不錯但讓產品看起來很好。這反過來將是一個更好的激勵者，並將培養積極的團隊精神。

• 公開你的度量標準，任何形式的信息隱藏都會導致不良反應和不公正。因此，如果您公佈您的指標，請仔細閱讀他們的評論。

最後，如果你真的在測量人，然後衡量他們所有人，程序員，建築師，經理，銷售人員，董事都應該有相同的審查。然後隱藏刀子並將金屬探測器放置在門上。通常原因在於，公司內部人員的透明度只能以一種方式進行，從頂部向下看。

Answer 16

我們是專業人士，就像很多人一樣。我們也相信我們是藝術家，在我看來我們是。不幸的是（大多數）程序員是擁有贊助人的藝術家。

通過說沒有可行的度量衡量我們是說「只留下我們，我們會做我們的工作」。那可能適用於你，但你有多少同事，你只是希望你有一個數字來表明他們是多麼糟糕？主觀性很好，讓我們都感覺更好，併爲經理創造了不錯的薪水，但我們做需要一些程序員熟練程度。

如果我們自己沒有拿出讓管理層感到滿意的東西，那麼他們會做與藝術贊助人一樣的事情。 「我不喜歡它，你被解僱了。」

世界>公司>產品>開發

對於特定指標，我像失去了其他人一樣。我看到的最好的是重新開放的錯誤指標。

Answer 17

閱讀一些你出色 答覆後，我在想，上述 的 一般問題描述指標是，它是 負面報道的錯誤 - 它不 鼓勵生產優質的代碼。

的確如此。而且你會遇到同樣的麻煩，你應用的任何其他指標。關鍵問題是質量不是我們知道如何進行數字測量的。此外，主要是如果您正確地完成工作，您不應該關心代碼質量問題。你真正的問題應該是，「這個人怎麼幫我們賺錢？」

評估不是你可以用數字做的事情，但它是你必須要做的事情。我可以給你的最好的建議是，你的經理只需要和程序員一起工作，瞭解程序員在做什麼。另一個重要的信息來源來自程序員的同行，他們每天都與他們一起工作。由於我們沒有一種數值方法來衡量質量，所以您在某種程度上必須依靠較軟的科學來深入瞭解您的程序員的表現如何。

Answer 18

QA發現的錯誤=好。 客戶發現的錯誤=錯誤。

如果您需要測量開發人員，請使用在測試後發現的#bugs，即在光盤上的生產/發佈/版本中。

質量保證同樣的指標......「一個團隊一個夢想」。

邁克爾

Answer 19

這個想法只是讓我想/ facepalm。

嗯，10年前我有一個老闆，他建議我爲SLOC付錢。

我在同一天離開。