[RD日常] 不禁在思考也許系統設計的本質只是減少人類認知的複雜度
但系統之間的複雜度無論怎麼設計都是不會改變的

於是追求設計後的複雜度簡化本身一個錯誤
因為提升了認知的簡易程度後，系統複雜度絕大多數也是跟著上升

本質上最後還是回到管理問題

我覺得近幾年我都有一種會寫軟體但又不會寫軟體的感覺
真奇妙

如果再加上軟體只是為了產品服務的這種認知
我就又更不知道答案了

好迷惘阿~~~~

或許高內聚低耦合是有其代價的 (儘管結果來說他是個好的方向)

本質上也許都是管理和合作問題

或許還有維護和效能的問題

(但我猜越往效能推那個內聚力會越低

然後又回到了一個很重要的觀念就是
實務上所有東西都是 trade off

我覺得我常常就像是在下一盤看不清手排也看不清 trade off 的棋

疑問: 怎樣是在寫軟體? 怎樣是在寫產品?
我認為爛的軟體架構和程式碼如果還是能夠被維護(頂多是差 1~5 天的程度)
是不是其實根本就沒差
有沒有可能我在追求的根本是不必要的負擔

追求極致的簡化是錯誤，但這也是一般人沒機會實際面對的奢侈，一般光是去除冗餘的複雜度就有很多空間可以發揮

tradeoff有點像爐石之類的策略遊戲的怪物交換，你拿自己的牌撞別人的牌，自己的血一定也會少，選項方面很少有絕對的上位互換，但高手和新手幾輪交換之後的牌差依然是顯著的

技術債也可以把它當作一種投機，我就賭未來的需求不會需要擴充這一塊模組，以省下這些時間。投機就是有輸有贏，在外部環境可預測性極低的情況下可以視為機率問題，那麼問題就是怎樣的下注贏面比較高

一般人對legacy code和技術債的仇恨度那麼高我覺得是"社會"問題，也就是一個domain由很多人來分工的時候，一個人可以把責任轉嫁給另一個人，零和遊戲。對於留下技術債的人來說，不管這投機的結果是輸或者贏，反正承擔風險的人不是他，從他的角度來看就是必勝賭局，那當然幫他賠錢的後進就會很賭爛