軟體發展在硬體時代之後，而許多新名詞也隨之誕生。接觸軟體（任何軟體皆算）也有13年多，除了大一的VB不算外（也真的沒有很認真去學習），從常用的LabVIEW到後來的MATLAB, C/C++, Python以及一些不太被算是程式語言的Mathmatica, Igor等等，對！LabVIEW通常也不太被認為是“正統的程式語言”，不過這是許多熱情者之間的定位之爭(就如同信仰與武學一樣，總是有著，為我正宗的意義)，我純粹是個使用者而已。
回到程式語言的撰寫，與軟體開發過程中，也如同“硬體”開發一樣，講求“可被開發性”，也就是期待軟體也能應用“設計模式“而達到“模組化”、”高維護性“、”可重赴使用“等等。也因此軟體開發管理相關的理論、討論、書籍不斷地產生，從經典老書”人月神話“到”約耳談軟體“、”溫伯格的軟體管理學“、到更多與『設計』、『開發模式』相關的書籍，如『Design Pattern』、『敏捷開發』等，可以列出一長串的清單，而學無止盡。只能說人類喜愛『創新』，但又希望以『管理』規範之。這兩者是個互補互足的共生關係。
而重點的技術債，就是在這些背景下誕生的，因為開發時總是有可能因為『時程』或『規劃的不完整』或『專業度的缺乏』等等，而造成中後期開發上的困難。但！真的是如此嗎？根據所查詢到的資料，技術債最早是由1992年的Ward Cunningham提出，說了這麼一段話(Ref: Wiki中文版，可以連結過去轉英文原文看)：
第一次發布程式碼，就好比借了一筆錢。只要通過不斷重寫來償還債務，小額負債可以加速開發。但久未償還債務會引發危險。復用馬馬虎虎的程式碼，類似於負債的利息。整個部門有可能因為鬆散的實作，不完全的物件導向的設計或其他諸如此類的負債而陷入窘境。我認為技術債是不存在的，但先了解技術債的幾個常見原因：
沒有足夠的預先定義
業務壓力
缺乏過程或理解
緊密耦合的組件，功能不是模塊化的
缺少一個測試套件
缺乏文件
缺乏協作
並行開發兩個或更多分支機構
延遲重構
缺乏與標準的一致性
缺少知識
缺乏所有權
技術領先能力差
最後一刻的規格更改
以上這些都是在任何開發階段中會遇見的，而，是否有完全沒有的可能情境呢？我想也許有，但我沒有見過，就如同沒有完美的架構、沒有完美的理論（若討論在某個特定的時間點，會存在，但不在此討論此狀況）。
每次的新專案開發，都會進行分析需求，撰寫規格書等，然後根據需求去定義與決定設計模式、架構等。但每個專案的大小總是不一樣，小專案若要使用大框架下去建構，是否有其價值？專案可能是“活的“，我的意思是隨著專案的持續開發與發佈，可能會因為新增需求而修改或者重構，但也有可能按照原本的規格書完成後，這個專案就”死了“（結束），也就沒需要擴增或改寫的需求。
如結束的專案，在數年後，因為產線的需求，或者新技術的導入要使其復活，我們可以說當初的專案有技術債的存在而導致後來要擴增或改寫的不便嗎？這是相對的。技術債也許是個債，根據當下的判斷而決定都有可能在未來改變。若已經存在的可能性（技術更新、原有架構不足等），那麼技術債就不存在。所以我並不認為技術債本身是個債務，而是一直存在的本質。
紀錄這點並不是討論文字本身的含義，而是使用上的必要性，也因為碰過喜愛專研技術的工程師，在開發上會過度強調技術的部分，而以技術債或者其他類似的名詞或觀念來堅持，但以整個產品開發週期來說，過度強調哪個環節（技術、供應鏈、業務等）都是過猶不及的。當然，跟人有關的總是複雜～
最後有趣的點是，提出技術債的Ward Cunningham，早期是物件導向開發的貢獻者之一，但他同時也是極限編程的開發者之一。
沒有留言:
張貼留言