工程師碎碎念 1

想不到標題只好亂寫。跟這篇有點相關，但講點別的。

因為某些邏輯有點複雜，修改程式很容易會改壞東西，而且改的那個人也不見得會測到所有該測的條件。

這種問題的解法之一是 unit test，用充分的測試保護那個 module，就能確保之後的修改比較不會改壞原本好的東西。但是那個 project 還沒裝 unit test framework，我也不熟，而且有點時間壓力，我認為先做出一個堪用的版本比架起 unit test framework 重要。

不過我也真的覺得要是之後改了一點 code，就可能會山崩，阿不是，是壞一堆沒想到的地方啊啊啊。光想到可能會 bug 相連到天邊、牽一髮動全身就覺得可怕。

後來我用比較彈性的做法，讓之後可以用新增 class 或一小段 code 而不修改原本 code 的方式加新的邏輯。咦？好眼熟喔！阿不就OCP？真是突然體會了為什麼那些 principle 那麼討厭「修改原有 code」，因為改原本的 code 就有風險、有可能造成意想不掉的 bug。這種事就是工程師最討厭的──我明明沒動那裡為什麼那邊會壞。

修改意味著可能有 bug，而且蠻高的機率需要修改，來不及架測試安全網，至少以遵守 OCP 的方式避免之後生 bug，也是一個方法。無法降低風險至零，但應該要能降低到能夠掌控。

設計原則也好，自動測試也好，它們只是方法不同，最終的目標是一樣的──完成一個有品質的軟體、系統。漸漸覺得，好像是看情況使用，而不見得非得如何。當然，有好設計以及自動測試的軟體是更好的。