|
|
英文原文：Technical Debt a Perspective for Managers
作者：Mark Levison 譯者：賴勤毅 發(fā)布于 2010年11月5日
現(xiàn)在已經(jīng)到第十次迭代開發(fā)周期了，你的項目開發(fā)速度開始變慢。在之前的幾個迭代周期中，團隊沒有像以前那樣完成很多的“故事場景”（stories）。此外，最近在新的故事場景和回溯中卻發(fā)現(xiàn)更多缺陷(bug)。項目經(jīng)理知道，團隊成員沒有變，他們也花同樣的時間工作。但是，客戶會發(fā)問：“發(fā)生什么事情了？這個團隊還在努力工作嗎？”
很多敏捷團隊的產(chǎn)品改進率為150-500%，可是你們的項目看起來卻貌似只有20-40%左右的改進率。這到底是怎么回事呢？在此我們找不到什么大問題；相反，只是有無數(shù)的小問題。有時，這些只是一些為了方便而使用的捷徑（開發(fā)人員沒有時間去清理這些修改），有時開發(fā)人員僅僅是不熟悉這中語言。還有一些問題就是，代碼跟灌木叢一樣凌亂，需要大幅度的修整。所有這些都屬于“技術(shù)債務”。
什么是“技術(shù)債務”？
它就是“那些內(nèi)在的事物，現(xiàn)在你不去解決，遺留下來（不干完），它就會阻礙未來開發(fā)”[Ward Cunningham]。 表面上，應用程序看起來質(zhì)量很高且狀況良好，但是這些問題卻隱藏在下面。 QA（質(zhì)量保證部門）甚至可能告訴你說，這個應用程序真是不錯，幾乎找不到缺陷，但是其中仍然存在“技術(shù)債務”，如果我們沒有很好地管理并設法降低這些“技術(shù)債務”，那么，程序編寫和維護的代價最終將會超過它對客戶的價值。
技術(shù)債務就像信用卡一樣，會有很高的利息率，就如同給團隊留下了大量的帳務開銷。這種情況下，開銷將會體現(xiàn)在時間花費和解決問題所需的努力上面。開發(fā)團隊拖延債務的時間越長，所積累的利息就越多（會額外增加很多工作），付出的成本也就越高。
另外，這還增加了實際的財務支出：開發(fā)團隊處理技術(shù)債務所花費的時間，可以用在對團隊有價值的其它工作上。同時，這些難讀的代碼引起的技術(shù)債務也讓我們難以找到軟件的缺陷。再且，理解代碼所損失的時間還可以用來做其它更有價值的事情呢。
我們?yōu)楹我鄯e技術(shù)債務呢？
項目編碼初期，不整理代碼，不寫單元測試，也不做測試驅(qū)動開發(fā)，整個團隊粗制濫造出更多的“故事場景”。 這些問題通常都不會馬上暴露出來，而循規(guī)蹈矩地編寫代碼往往需要更多的時間，特別是在早期階段。
技術(shù)債務來自哪里？
- 沒有經(jīng)驗的開發(fā)人員 —— 有些項目里面，編寫Java/C#/Ruby的開發(fā)人員沒有接受過培訓，或者沒有面向?qū)ο蟮挠^念。結(jié)果呢，他們會一直編寫適用于他們曾經(jīng)習慣的編程語言——像Visual Basic等——的代碼。
- 項目工期的壓力 —— 那些來自于經(jīng)理或客戶的顯性壓力和其它一些潛在的壓力。“我們承諾在以后迭代（發(fā)布）的故事場景中做到這些”。開發(fā)團隊會發(fā)現(xiàn)他們不會交付這些承諾的發(fā)行版本（迭代版本），而是采取便捷的手段。“我們不得不把事情做完；我們無法承擔修整代碼所耗費的時間。如果這不是新特性/缺陷，那么就不用去做”。 不幸的是，這些觀點還會得到管理人員的支持，特別是在管理層沒有意識到這些成本的時候。
- 凌亂而難讀的代碼。當一個方法或類中存在一些難讀的代碼，下一個開發(fā)人員繼續(xù)這些工作的時候，就覺得他也沒有必要迫使自己編寫清晰的代碼。所以，每次有人接手這些代碼的時候，一小段臟亂的代碼將會變成一大堆亂七八糟的代碼。
- 專業(yè)領(lǐng)域的代碼 —— 往往有這樣的觀念：這些代碼看起來就是很差勁，但是這不屬于我的領(lǐng)域，所以我不能或不會改變它們。另外，對于修改專業(yè)領(lǐng)域的代碼，開發(fā)人員也會覺得力不從心。
- 過度復雜 —— 開發(fā)人員經(jīng)常趨向于在需求之前設計解決方案。而且，很多情況下他們的代碼沒有找到正確的方向，還會寫一些沒有用處的代碼。或者，這些代碼沒有真正地符合需求，因為代碼在問題還沒有完全明白的時候就已經(jīng)寫完了。還有另外一種情況，過度設計花費了額外的時間，產(chǎn)生的代碼不是不能使用就是不符合項目的需求。
- 糟糕的設計 —— 有些解決方案只是設計不佳。但在設計不好的代碼上面繼續(xù)擴展，而不去解決這個問題，會使問題更加惡化。
解決問題
這個問題的并不是一下子可以解決的，解決方案需要通過幾個迭代周期。并且，你需要耐心，并要從多個角度尋找解決途徑。
解決方案中的要點
- 讓開發(fā)人員接受語言方面的基本培訓并教授他們面向?qū)ο蟮脑?，從而把他們的理解力提升至入門階段。要想既成功又有效的話，這需要花幾個禮拜的時間培訓，還需要有精通這方面的人員來跟進和支持這一系列培訓。
- 告訴開發(fā)人員和管理人員，當前的這些問題都是需要花費企業(yè)資金的。這點尤其重要，因為它會使解決這些問題的意義更加明確。你要清楚地告訴他們，管理人員會重視這些問題，并且已經(jīng)開始著手償還這些技術(shù)債務了。不斷支持這些工作使之成為常規(guī)的原則之一，這樣整個團隊就會信任這個準則。
- 提供一些培訓，包括代碼的壞味道，重構(gòu)，單元測試和測試驅(qū)動開發(fā)等。還可以結(jié)合課堂會議，基于網(wǎng)絡的材料和書籍來進行培訓。
- 在工作的時候，給他們一些空余時間去研究和練習他們的技能（一個禮拜兩個小時應該是達成這個目標的最小的時間量）。練習的代碼應該被丟棄，這樣，他們就能無拘無束地嘗試和試驗一些事情，不管怎么樣，他們不用在基礎(chǔ)代碼庫上面進行練習?；c時間練習和研究應該是最有用的建議了。假如沒有為他們提供空閑的時間，就壓根不會發(fā)現(xiàn)真正合理的敏捷開發(fā)方式。這種組織方式也被稱為“道場”-Dojo（更加詳細的資料可以參考 TDD Randori Session 和 TDD Randori Workshop）。
- 使用工具（靜態(tài)分析，單元測試，持續(xù)集成，自動化可接受性測試）來幫助團隊發(fā)現(xiàn)、減少和衡量他們的技術(shù)債務量。應該在團隊層面利用這些度量數(shù)據(jù)，而不能分享給管理人員。團隊成員需要知道，他們并不會因為對這些技術(shù)債務的度量而接受獎勵或者遭受懲罰。如果我們把這些度量數(shù)據(jù)報告給管理層，并由管理層來追蹤的話，開發(fā)人員很快會找到一些竅門來規(guī)避它們，這樣就失去了本來應有的價值了。
- 當人們完成了他們的培訓或者在技術(shù)上取得了少許提升時，應該得到獎勵。獎勵可以是給予一次認可的表彰或者是一些小小的禮物，但不要直接給予現(xiàn)金獎勵。
- 每兩個禮拜進行一次午餐聚會和一些關(guān)于技術(shù)方面的學習型會議。利用這些會議來促進開發(fā)成員之間的討論。提供午餐可以提高參會人數(shù)。另外比較重要的是需要管理人員每次都來出席，這樣就很清楚的表明他們也一直支持大家提高技術(shù)。
- 維護關(guān)于技術(shù)債務的備忘錄 – 任何時候，如果開發(fā)人員發(fā)現(xiàn)一些無法立即應付的技術(shù)債務時，就需要填寫一份技術(shù)債務登記卡。開發(fā)人員應該優(yōu)先考慮這些技術(shù)債務，并花費10-15%的精力來償還這些技術(shù)債務。大多數(shù)項目中，任何的一些小事都會使問題變得更加嚴重。
基于這樣的立場，你會發(fā)現(xiàn)問題，也會擁有機會。你的問題是：項目的基礎(chǔ)代碼一直在積累技術(shù)債務，但是這些債務已經(jīng)開始下降了。然而，現(xiàn)在跟客戶申請用于處理這些問題的資金會跟處理這些問題一樣困難。你的機遇是：提高了開發(fā)人員的技能；清楚地表達了管理層對這項工作的支持，還有，軟件的代碼質(zhì)量會不斷改善，軟件缺陷的數(shù)目也會不斷減少。同時這也會很好的提高團隊的整體開發(fā)能力。
it知識庫：從經(jīng)理的角度看技術(shù)債務，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
