軟體擴充性

這個人又來胡言亂語了，不是什麼正經筆記

最近寫某個邏輯或定義常常不清楚或者 ambiguous 的東西（因為資料來源是給人看而且也沒整理過），但程式需要清楚的邏輯，感覺在試圖把模糊不清的東西轉成邏輯清晰的程式。似乎，在原本是人工作業而且沒有特別統一或整理過邏輯或步驟的事情上可能就有這種現象。

工程師很喜歡「找 general 的方法」跟「確認出清楚的邏輯」，畢竟這樣程式比較好寫。但是這東西不只原本的邏輯可能不清楚，還「一定會變動但無法預期會如何變動」，以至於後來我放棄找 general 的方法，而是把問題切得更細再組起來，其實就是 divide and conquer。 甚至稍微放寬對清晰邏輯的要求，改用擴充性比較好的做法。只要變動的時候可以用比較低風險──不會影響到其他部分──的方式因應就好，如此，無論是現在邏輯可能再修正或者之後增加目前沒有的東西都能處理。

這讓我更能體會為什麼很多設計都希望增加程式擴充性跟降低修改風險，這讓工程師在面對模糊或高度變動的狀況可以好過一點，不然會改到崩潰。

至於，不能邏輯清楚了再寫嗎？不是不行，但有時候等回應實在太慢，要搞清楚完整邏輯需要花很多時間，而且仍然無法避免「找不到 general 方法」，那就弄個可以微調的辦法之後再慢慢調就好啦！

另外，最近看了一篇文章讓我覺得相對於機器世界的邏輯分明，人類世界本來就沒有那麼清晰跟確定，而工程師剛好是兩者的翻譯官。