反向思考

最近寫程式很容易碰到瓶頸，已經逐漸稀少的頭髮開始岌岌可危。最主要是三個個大麻煩，一是複雜的資料結構，二是有著數不清邊角條件的 UI 模式，然後中間還有長時間累積下來連結兩端，亂結成一團球狀電線的邏輯，解 bug 還勉強可以，一旦要加一個新功能進介面模式，總要盤算個老半天要怎樣才不會讓這一團脆弱的結構塌下來。

沒辦法，只能繞開主體，從旁邊加進去: 做了一個分離的資料結構，而使用者的動作事件則用攔截的方式接下來，處理的邏輯與原來的那一團分開；這樣等於是做了一個圍牆，圍住不想去動的舊核心。一開始還沾沾自喜，這樣的設計看起來好像可以用。

萬沒想到，一路做下去，原來應該只是輔助用的資料結構越來越龐大，而攔截使用者動作的地方越來越多，更糟糕的是，新的處裡邏輯模組因為是加在外圍，所以要處理很多原來舊核心已經處理的地方。等於是圍牆越蓋越肥大，舊核心還沒塌，外面反而撐不住，先垮了。

最後只好舉白旗投降。深切反省，如果一開始不是依本能的反應想躲開棘手的雷區，而是相反的直接切開核心把手弄髒，就不會繞這麼大一圈，最後還是功虧一匱。

回想在前東家也見過類似的例子: 原來以為雲端架構不過就是一堆伺服器的集合，只是把管理和運營造好一點就可以。但是當規模越來越大，維運成本始終壓不下來，而效能一直上不去，才警覺到方向根本錯了: 發展的方向應該是先做符合雲端定義的技術架構，當確定可以用了，再摘取子集合成為伺服器的版本，思考的方向反了。

我的心得: 當腦筋打結的時候，在去運動、吃甜食、淋浴或是吃甜食麻痺自己的同時，可以考慮把思考方向反轉過來，也許會有驚喜。