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

面對技術債，該用什麼心情？

設計缺陷

原設計者: 「原本沒想到可以這樣做，原設計被事後諸葛，也無話可說，虛心接受吧」
再設計者: 「這技術債是無心之過，不是人為，是當時最佳決定了」

也許，當時世界頂尖技術還沒發展到至今，AngularJS 一開始也沒有單一資料流、狀態管理...，用 $scope.on('event') (廣播功能) 來解決非同步更新畫面的問題，也是理所當然。
也許，前端框架還沒有發展 Virtual DOM 所以把前端框架拿來當模板語言使用也是理所當然的。
也許，async/await 還沒有支援 node.js 時只能用 generator 寫類似的語法，用套件 co 也是時代的眼淚，再加上 co-express、co-functional...相信專案已是時代的淚流滿面。

也許有太多的也許？

設計缺陷，一定是某個接任者沒有決定調整方向！而這個就是糙點。
設計缺陷要自己擦屁股!!不然就留下待擦屁股的文件。

過氣的套件

有機會拔掉過氣套件，要拔掉!!

這種情況就像是，你使用了不良的命名。

看到這種東西，要弄懂它

1. 查一下它是什麼
2. 要學一下它是什麼
3. 原來是做一些現在已經有替代方案的東西呀
4. (對於這個問題，他現在才跟你有相同的認知，但是已花費了不少的時間，這些是不會讓自己進步的花費，就只是為了要消滅當初沒做的技術債)
5. 然後計劃把它拔掉

如果你的專案，還是用bower 安裝套件？你要怎麼拔掉它？

缺少測試

原任開發者: 「這應該看就知道了吧？」
接任開發者: 「這....是什麼功能？」

有寫測試，在這個時代算是一個門檻，另一個境界的工程師。
除了可以滿足「定義自己已完成工作」，還可以給予接任工程師足夠的勇氣，繼續改下去。

常見的情況，是自己給自己勇氣。
自己補上自動化測試，是幸福。(還補得上)
有另一個人寫測試給自己，是奢華的幸福。[1]

不寫測試，不算糙 code ，算是沒有給予勇氣。
但是，可以的話，寫測試吧！都二十一世紀了...

若程式碼寫得不好，就該學測試來自我訓練，程式碼的可測試性提高，程式碼品質也會提高。
程式碼最接近規格的語意，就是用測試框架寫的程式碼了。

明知該實作，卻沒實作

這是要給誰擦屁股？

原任開發者: 「這...當初就是....所以就沒做了？」
接任開發者: 「所以，算我倒楣？要怎麼做？」

所有自己寫的程式碼，都應該要收尾擦屁股。一開始都會寫髒 code 沒錯。
學習任何技能都要知道，不要怕手髒。寫程式也是，不要怕 code 髒。(也許寫髒 code 的人就是不怕到一種極致了...QQ)

但是，等你熟悉問題，了解問題前因後果，並且將會動的程式碼放上去之後，請務必將程式碼整理、該做的最佳化要做。

如果這一切都有這麼多理由不做，這一切都有這麼多的原因，讓你斷了手無法將這份 code 的品質維護到一定的程度，那麼就寫文件吧。

意思是說，自己的實作要自己擦屁股!!不然就留下待擦屁股的文件。

這一切與消費者無關

若買到的 iPhone、車子導航系統 有哪並不完美，消費者會覺得，這是沒關係的嗎？
還是消費者覺得這是瑕庛品？

當然這是一個不專業的說法，但是消費者就是如此。

參考資料

[1]: CHIMEI 2010 新奢華的幸福