iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 18
3

良好程式碼的優點大同小異。
不好的程式碼的糙點卻各有巧妙之處。

今天再加一句

如果你可以聞到軟體的壞味道。
要小心憤世嫉俗的心,將吞噬你的未來。

技術債(technical debt)。

關於技術債的介紹,摘錄自優秀前輩的文章

王建興 在 IThome 抄捷徑的技術債,遲早要還的 有提過[1]

在1992年的時候,Ward Cunningham首先提出了一個名為「技術債(Technical Debt)」的隱喻(metaphor

Ted 的 搞笑談軟工 技術債要不要還? 也有提過

這個說法是Ward Cunningham所提出的一種比喻,它是開發人員針對以下兩種狀況取捨之後的結果:

用比較高的成本寫出乾淨程式碼但可能發生延遲交付的成本。
用廉價成本快速寫出可以動但是亂七八糟的程式,但在產品釋出之後必須負擔較高的維護成本。[2]

Miles 的 技術債(Technical Debt)- 看到 code 寫成這樣我也是醉了,不如試試重構? 是一篇寫得很好的鐵人文哦

Martin Fowler 把技術債產生原因分成了兩種維度,分別是魯莽(reckless)、謹慎(prudent)與有意(deliberate)、無意(inadvertent)。

技術債的種類

依欠債方法來看,技術債有以下種類:

  • 設計缺陷,這也是一般最常見的技術債。
  • 文件不足,包括沒寫註解或是專案文件等。
  • 缺少測試,原本應該要正確的功能,會因為沒有測試好而產生 bug 。
  • 明知該實作,卻沒實作。比方說:明知沒實作快取,會讓服務反應時間過久,但沒實作也能動,就先交貨了。

廣義來說,只要技術上會難以修改的理由,都可以算是技術債。[3]

只要是留給別人修改的 code 都是糙 code。

面對技術債,該用什麼心情?

文件不足

原任開發者: 「這應該看就知道了吧?」
接任開發者: 「這應該看就知道了嗎?」

也許,對於技術學習與熟練度,這是相對的。


圖片來源: 都幾點了你還不敏捷 - Terry, Chuan Yin Wang [4]

軟體開發,會預設每個剛接任的工程師,對工具的熟練度是低,對需求改變頻率是高的。
文件要寫,不寫就要把 code 寫好。

要常思考不足之處,不管是 code 的語意表達 (這件事是用來取代文件的),還是另外寫文件補充。
如果被唸糙 code 麻煩練習寫文件。放棄把 code 寫好的技能

心中的那把尺

程式碼品質的好壞,源自於自己心中的標準。

  • 好的工程師會隨時調整自己的標準,但是要有好理由。
  • 自滿的工程師會不願接受別人的標準,就算有好理由。
  • 無知的工程師會無法說服別人或被說服調整標準,因為用習慣說服別人,也不願意改變習慣。

參考資料

[1]: 抄捷徑的技術債,遲早要還的
[2]: 技術債要不要還?
[3]: 技術債(Technical Debt)- 看到 code 寫成這樣我也是醉了,不如試試重構?
[4]: 都幾點了你還不敏捷


上一篇
過度依賴前置處理器
下一篇
技術債是糙 code ?? (下)
系列文
可不可以不要寫糙 code30

尚未有邦友留言

立即登入留言