網頁

2017年7月2日 星期日

關於技術債的why what how


敏捷其實是面照妖鏡,能提早暴露出組織和團隊的問題,好讓團隊能及早進行討論,和思考改善方案(當然前提是有想要改善,有能力改善)。隨著專案越來越大,系統越來越複雜,技術債這個議題已經越來越不能忽視,因此最近團隊時常討論的題目便是"該如何償還技術債",但是如果直接基於這個命題來討論,我們很容易就直接跳到了how 的議題,於是各式各樣的爭論就出現了:

  • 是不是應該要每個 sprint 保留時間解決技術債
  • 技術債不解決,到了後期要解決所花的成本會是以指數倍增
  • 既然是債務,要還債就要考慮是否有盈餘可以還債
  • 我們應該等到有盈餘和餘力的時候再來考慮還債 (謎之音:原來沒賺錢就可以不用還錢~:P)
  • 身為一個快速成長(預期持續會成長)的公司,新需求會越來越多,系統只會越來越複雜,那會有時間嗎?
  • 如果我們不能先養活自己,賺到足夠多的錢,是沒有本錢談還技術債,只能先衝各種商業機會所產生的新需求
上述的每個言論似乎都有些道理,但是仔細想想卻怪怪的,因為背後的前提假設都不一樣,其實根本不是在同一個層面的探討,如果上網搜尋更會找到更多相關的文章:
 
不過我覺得一個好的討論應該參考 - 問題解決金字塔:理清Why、What、How 讓你工作沒煩惱 的順序來討論,也許可以把問題重新定義成:

Why 為什麼會有技術債?
What 是怎樣的技術債(技術債也有類型)?該不該被解決? 何時要解決?
How 如何去解決技術債?

因此我比較喜歡先從 Martinfowler - TechnicalDebtQuadrant 對於技術債的定義開始討論,我們可以把技術債分成產生原因分成四個項限,蠻幹(reckless)和謹慎(prudent),而另一個象限,則是刻意的(deliberate),以及無心的(inadvertent):


這種分類就像之前"Scrum Team 中關於插單事件的視覺化的感想 "中的討論,究竟插單的產生原因是不是長尾造成的,那什麼是長尾?是故意留下的技術債該還了?還是無意且疏忽留下的bug?所以技術債也可以用這四種項限來討論。

無心且蠻幹造成的技術債

我稱之為臭臭/混亂的程式碼,造成這個的原因可能是技術能力不足,沒有良好的開發習慣...
對於這種應該就是只能靠工程師和團隊努力提昇自己的技能,只要有看到不臭臭的code 就順手(花時間)把它修掉....

謹慎且有意造的技術債

這時候通常就是Team也知道,PO也知道,隔壁的老王也知道,但是為了商業考量只好衝了...
這種最容易發現,也最好討論,因為往往是商業考量,也是最有可能不需要還的,很多時候商業需求和時間點一過,搞不好整套都要丟掉。此外因為跟商業考量掛勾,也比較好在將來排進去還債。

謹慎但無心造成的技術債

這個項限最有趣,也最難理解,我的理解是隨著專案進行,或技術進步,突然想到又更好的解法,於是舊的東西就變成技術債了?

故意又蠻幹造成的技術債

時程太趕,又一直被壓時間,這時候工程師的百寶箱內的工具盡出~(怪我摟)
這種通常就是爭論角力的所在點,明知到有問題,但是何時能要到時間還債?

我覺得最容易產生爭論的就在後面兩種,不過知道成因後,比較能針對不同的項限討論接下來的債務償還策略:
  • 直接償還:將視為技術債的程式碼,架構,框架,技術作重構或更換
  • 債務轉換:選擇當前夠好的替代方案,而不是完美的方案
  • 純支付利息:重構代價太高,反正堪用,在只需要維護的狀況下,就繼續使用吧
更多技術債管理的方式可以參考下面的文章:

不知道大家團隊都怎麼處理技術債?
最後只想說....



沒有留言:

張貼留言