gipi的學習筆記-經營管理、數據思考、終身學習

還記得我之前寫過一篇關於軟體開發時應該要注意的幾個面向：
[產品開發]軟體產品開發的五大支柱

其中有一項指的是客製，這個詞在對岸習慣被稱為二次開發，一個商用軟件不可能一開始就能滿足百分之百客戶的需求，因此客製是一定會發生的，而一個產品能否迅速的被客製化，且以低成本、高彈性的方式被實現，講求的就是他對於客製的架構是否有構想好。

這邊指的客製可以分為幾類：
1.透過改Code來達成
2.透過Configuration
3.透過User Custom script或code達成

第一種做法自然是最不好的，但卻是最普遍的，因為一定可以做的到，而SAP、Oracle等大型廠商的客製功能大概是在2.3之間流動，希望能在不修改Code的狀況下，讓使用者更簡單的客製化程式，但這往往也需要經過一段時間的訓練，要對Configuration跟Custom script多做學習，才有可能改出好的客製功能。

讓使用者可以簡單客製，本身已經是個挑戰，若考慮到客製之後的升級問題，就更讓人頭痛了，商用軟件一般來說會有新舊版本的差別，新版本的功能一般是不會回推到舊版本的，客戶若想要新功能，一是客製，二就是升版了，而若遇到核心的修改，那只剩下唯一的路，就是升版。

一般來說客製時並不一定會考量到所有核心的限制，有時候單單只為達到某個特定的需求，因此在版本升級後，可能就會出現不相容的錯誤，這一類的問題不只在商用軟件中會出現，一般的軟體與OS的搭配也常常發生，而解決方案大多是修改程式來解決，架構好一點的可能可以避開此類的問題，讓客製的功能儘量限制在一定範圍內，不去牽涉到核心功能與流程，但這也是說得簡單，做起來困難重重啊。

之前有人提說SOA可以解這一類的問題，因為只要將功能切到夠細，讓客戶只能使用這些Component來做客製，彼此之間的關連性就降低了，關連性降低，因升版而造成的影響就會減少，就有可能達成無痛升級，但...如果SOA真的這麼簡單，現在早就整條街上都是SOA產品了，而且就算真的是SOA架構，只要使用者沒有足夠的Domain思維，那最後的結果仍是一樣的，因為他不會知道什麼叫合理，什麼叫不合理。

還記得過去有幾次被要求當開發的底層平台升級時，不能影響上頭的AP，也就是要無痛升級，而且還要拍胸脯保證，那種體驗真的很艱辛，新版本開發的時程都壓很緊了，還要在修改每個細節實都要設想到升級的問題，不過也因為這樣，讓我對版本變更時該留意的點有了更多的認知。

然而到目前為止，針對客製的部分仍無法保證可以不用改任何的Code或者設定就直接升版，這部分是很值得花時間去構想的。