英文原文：Technical Debt a Perspective for Managers

　　作者：Mark Levison 譯者：賴(lài)勤毅 發(fā)布于 2010年11月5日

　　現(xiàn)在已經(jīng)到第十次迭代開(kāi)發(fā)周期了，你的項(xiàng)目開(kāi)發(fā)速度開(kāi)始變慢。在之前的幾個(gè)迭代周期中，團(tuán)隊(duì)沒(méi)有像以前那樣完成很多的“故事場(chǎng)景”（stories）。此外，最近在新的故事場(chǎng)景和回溯中卻發(fā)現(xiàn)更多缺陷(bug)。項(xiàng)目經(jīng)理知道，團(tuán)隊(duì)成員沒(méi)有變，他們也花同樣的時(shí)間工作。但是，客戶(hù)會(huì)發(fā)問(wèn)：“發(fā)生什么事情了？這個(gè)團(tuán)隊(duì)還在努力工作嗎？”

　　很多敏捷團(tuán)隊(duì)的產(chǎn)品改進(jìn)率為150-500%，可是你們的項(xiàng)目看起來(lái)卻貌似只有20-40%左右的改進(jìn)率。這到底是怎么回事呢？在此我們找不到什么大問(wèn)題；相反，只是有無(wú)數(shù)的小問(wèn)題。有時(shí)，這些只是一些為了方便而使用的捷徑（開(kāi)發(fā)人員沒(méi)有時(shí)間去清理這些修改），有時(shí)開(kāi)發(fā)人員僅僅是不熟悉這中語(yǔ)言。還有一些問(wèn)題就是，代碼跟灌木叢一樣凌亂，需要大幅度的修整。所有這些都屬于“技術(shù)債務(wù)”。

　　什么是“技術(shù)債務(wù)”？

　　它就是“那些內(nèi)在的事物，現(xiàn)在你不去解決，遺留下來(lái)（不干完），它就會(huì)阻礙未來(lái)開(kāi)發(fā)”[Ward Cunningham]。 表面上，應(yīng)用程序看起來(lái)質(zhì)量很高且狀況良好，但是這些問(wèn)題卻隱藏在下面。 QA（質(zhì)量保證部門(mén)）甚至可能告訴你說(shuō)，這個(gè)應(yīng)用程序真是不錯(cuò)，幾乎找不到缺陷，但是其中仍然存在“技術(shù)債務(wù)”，如果我們沒(méi)有很好地管理并設(shè)法降低這些“技術(shù)債務(wù)”，那么，程序編寫(xiě)和維護(hù)的代價(jià)最終將會(huì)超過(guò)它對(duì)客戶(hù)的價(jià)值。

　　技術(shù)債務(wù)就像信用卡一樣，會(huì)有很高的利息率，就如同給團(tuán)隊(duì)留下了大量的帳務(wù)開(kāi)銷(xiāo)。這種情況下，開(kāi)銷(xiāo)將會(huì)體現(xiàn)在時(shí)間花費(fèi)和解決問(wèn)題所需的努力上面。開(kāi)發(fā)團(tuán)隊(duì)拖延債務(wù)的時(shí)間越長(zhǎng)，所積累的利息就越多（會(huì)額外增加很多工作），付出的成本也就越高。

　　另外，這還增加了實(shí)際的財(cái)務(wù)支出：開(kāi)發(fā)團(tuán)隊(duì)處理技術(shù)債務(wù)所花費(fèi)的時(shí)間，可以用在對(duì)團(tuán)隊(duì)有價(jià)值的其它工作上。同時(shí)，這些難讀的代碼引起的技術(shù)債務(wù)也讓我們難以找到軟件的缺陷。再且，理解代碼所損失的時(shí)間還可以用來(lái)做其它更有價(jià)值的事情呢。

　　我們?yōu)楹我鄯e技術(shù)債務(wù)呢？

　　項(xiàng)目編碼初期，不整理代碼，不寫(xiě)單元測(cè)試，也不做測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，整個(gè)團(tuán)隊(duì)粗制濫造出更多的“故事場(chǎng)景”。 這些問(wèn)題通常都不會(huì)馬上暴露出來(lái)，而循規(guī)蹈矩地編寫(xiě)代碼往往需要更多的時(shí)間，特別是在早期階段。

　　技術(shù)債務(wù)來(lái)自哪里？

• 沒(méi)有經(jīng)驗(yàn)的開(kāi)發(fā)人員 —— 有些項(xiàng)目里面，編寫(xiě)Java/C#/Ruby的開(kāi)發(fā)人員沒(méi)有接受過(guò)培訓(xùn)，或者沒(méi)有面向?qū)ο蟮挠^(guān)念。結(jié)果呢，他們會(huì)一直編寫(xiě)適用于他們?cè)?jīng)習(xí)慣的編程語(yǔ)言——像Visual Basic等——的代碼。
• 項(xiàng)目工期的壓力 —— 那些來(lái)自于經(jīng)理或客戶(hù)的顯性壓力和其它一些潛在的壓力。“我們承諾在以后迭代（發(fā)布）的故事場(chǎng)景中做到這些”。開(kāi)發(fā)團(tuán)隊(duì)會(huì)發(fā)現(xiàn)他們不會(huì)交付這些承諾的發(fā)行版本（迭代版本），而是采取便捷的手段。“我們不得不把事情做完；我們無(wú)法承擔(dān)修整代碼所耗費(fèi)的時(shí)間。如果這不是新特性/缺陷，那么就不用去做”。 不幸的是，這些觀(guān)點(diǎn)還會(huì)得到管理人員的支持，特別是在管理層沒(méi)有意識(shí)到這些成本的時(shí)候。
• 凌亂而難讀的代碼。當(dāng)一個(gè)方法或類(lèi)中存在一些難讀的代碼，下一個(gè)開(kāi)發(fā)人員繼續(xù)這些工作的時(shí)候，就覺(jué)得他也沒(méi)有必要迫使自己編寫(xiě)清晰的代碼。所以，每次有人接手這些代碼的時(shí)候，一小段臟亂的代碼將會(huì)變成一大堆亂七八糟的代碼。
• 專(zhuān)業(yè)領(lǐng)域的代碼 —— 往往有這樣的觀(guān)念：這些代碼看起來(lái)就是很差勁，但是這不屬于我的領(lǐng)域，所以我不能或不會(huì)改變它們。另外，對(duì)于修改專(zhuān)業(yè)領(lǐng)域的代碼，開(kāi)發(fā)人員也會(huì)覺(jué)得力不從心。
• 過(guò)度復(fù)雜 —— 開(kāi)發(fā)人員經(jīng)常趨向于在需求之前設(shè)計(jì)解決方案。而且，很多情況下他們的代碼沒(méi)有找到正確的方向，還會(huì)寫(xiě)一些沒(méi)有用處的代碼。或者，這些代碼沒(méi)有真正地符合需求，因?yàn)榇a在問(wèn)題還沒(méi)有完全明白的時(shí)候就已經(jīng)寫(xiě)完了。還有另外一種情況，過(guò)度設(shè)計(jì)花費(fèi)了額外的時(shí)間，產(chǎn)生的代碼不是不能使用就是不符合項(xiàng)目的需求。
• 糟糕的設(shè)計(jì) —— 有些解決方案只是設(shè)計(jì)不佳。但在設(shè)計(jì)不好的代碼上面繼續(xù)擴(kuò)展，而不去解決這個(gè)問(wèn)題，會(huì)使問(wèn)題更加惡化。

　　解決問(wèn)題

　　這個(gè)問(wèn)題的并不是一下子可以解決的，解決方案需要通過(guò)幾個(gè)迭代周期。并且，你需要耐心，并要從多個(gè)角度尋找解決途徑。

　　解決方案中的要點(diǎn)

1. 讓開(kāi)發(fā)人員接受語(yǔ)言方面的基本培訓(xùn)并教授他們面向?qū)ο蟮脑恚瑥亩阉麄兊睦斫饬μ嵘寥腴T(mén)階段。要想既成功又有效的話(huà)，這需要花幾個(gè)禮拜的時(shí)間培訓(xùn)，還需要有精通這方面的人員來(lái)跟進(jìn)和支持這一系列培訓(xùn)。
2. 告訴開(kāi)發(fā)人員和管理人員，當(dāng)前的這些問(wèn)題都是需要花費(fèi)企業(yè)資金的。這點(diǎn)尤其重要，因?yàn)樗鼤?huì)使解決這些問(wèn)題的意義更加明確。你要清楚地告訴他們，管理人員會(huì)重視這些問(wèn)題，并且已經(jīng)開(kāi)始著手償還這些技術(shù)債務(wù)了。不斷支持這些工作使之成為常規(guī)的原則之一，這樣整個(gè)團(tuán)隊(duì)就會(huì)信任這個(gè)準(zhǔn)則。
3. 提供一些培訓(xùn)，包括代碼的壞味道，重構(gòu)，單元測(cè)試和測(cè)試驅(qū)動(dòng)開(kāi)發(fā)等。還可以結(jié)合課堂會(huì)議，基于網(wǎng)絡(luò)的材料和書(shū)籍來(lái)進(jìn)行培訓(xùn)。
4. 在工作的時(shí)候，給他們一些空余時(shí)間去研究和練習(xí)他們的技能（一個(gè)禮拜兩個(gè)小時(shí)應(yīng)該是達(dá)成這個(gè)目標(biāo)的最小的時(shí)間量）。練習(xí)的代碼應(yīng)該被丟棄，這樣，他們就能無(wú)拘無(wú)束地嘗試和試驗(yàn)一些事情，不管怎么樣，他們不用在基礎(chǔ)代碼庫(kù)上面進(jìn)行練習(xí)。花點(diǎn)時(shí)間練習(xí)和研究應(yīng)該是最有用的建議了。假如沒(méi)有為他們提供空閑的時(shí)間，就壓根不會(huì)發(fā)現(xiàn)真正合理的敏捷開(kāi)發(fā)方式。這種組織方式也被稱(chēng)為“道場(chǎng)”-Dojo（更加詳細(xì)的資料可以參考 TDD Randori Session 和 TDD Randori Workshop）。
5. 使用工具（靜態(tài)分析，單元測(cè)試，持續(xù)集成，自動(dòng)化可接受性測(cè)試）來(lái)幫助團(tuán)隊(duì)發(fā)現(xiàn)、減少和衡量他們的技術(shù)債務(wù)量。應(yīng)該在團(tuán)隊(duì)層面利用這些度量數(shù)據(jù)，而不能分享給管理人員。團(tuán)隊(duì)成員需要知道，他們并不會(huì)因?yàn)閷?duì)這些技術(shù)債務(wù)的度量而接受獎(jiǎng)勵(lì)或者遭受懲罰。如果我們把這些度量數(shù)據(jù)報(bào)告給管理層，并由管理層來(lái)追蹤的話(huà)，開(kāi)發(fā)人員很快會(huì)找到一些竅門(mén)來(lái)規(guī)避它們，這樣就失去了本來(lái)應(yīng)有的價(jià)值了。
6. 當(dāng)人們完成了他們的培訓(xùn)或者在技術(shù)上取得了少許提升時(shí)，應(yīng)該得到獎(jiǎng)勵(lì)。獎(jiǎng)勵(lì)可以是給予一次認(rèn)可的表彰或者是一些小小的禮物，但不要直接給予現(xiàn)金獎(jiǎng)勵(lì)。
7. 每?jī)蓚€(gè)禮拜進(jìn)行一次午餐聚會(huì)和一些關(guān)于技術(shù)方面的學(xué)習(xí)型會(huì)議。利用這些會(huì)議來(lái)促進(jìn)開(kāi)發(fā)成員之間的討論。提供午餐可以提高參會(huì)人數(shù)。另外比較重要的是需要管理人員每次都來(lái)出席，這樣就很清楚的表明他們也一直支持大家提高技術(shù)。
8. 維護(hù)關(guān)于技術(shù)債務(wù)的備忘錄 – 任何時(shí)候，如果開(kāi)發(fā)人員發(fā)現(xiàn)一些無(wú)法立即應(yīng)付的技術(shù)債務(wù)時(shí)，就需要填寫(xiě)一份技術(shù)債務(wù)登記卡。開(kāi)發(fā)人員應(yīng)該優(yōu)先考慮這些技術(shù)債務(wù)，并花費(fèi)10-15%的精力來(lái)償還這些技術(shù)債務(wù)。大多數(shù)項(xiàng)目中，任何的一些小事都會(huì)使問(wèn)題變得更加嚴(yán)重。

　　基于這樣的立場(chǎng)，你會(huì)發(fā)現(xiàn)問(wèn)題，也會(huì)擁有機(jī)會(huì)。你的問(wèn)題是：項(xiàng)目的基礎(chǔ)代碼一直在積累技術(shù)債務(wù)，但是這些債務(wù)已經(jīng)開(kāi)始下降了。然而，現(xiàn)在跟客戶(hù)申請(qǐng)用于處理這些問(wèn)題的資金會(huì)跟處理這些問(wèn)題一樣困難。你的機(jī)遇是：提高了開(kāi)發(fā)人員的技能；清楚地表達(dá)了管理層對(duì)這項(xiàng)工作的支持，還有，軟件的代碼質(zhì)量會(huì)不斷改善，軟件缺陷的數(shù)目也會(huì)不斷減少。同時(shí)這也會(huì)很好的提高團(tuán)隊(duì)的整體開(kāi)發(fā)能力。

it知識(shí)庫(kù)：從經(jīng)理的角度看技術(shù)債務(wù)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。