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

今天再加一句

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

技術債（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]: 都幾點了你還不敏捷