最近同事工作上遇到了一些關於系統設計的問題來找我討論，聽了描述之後我的直覺反應告訴他「會有這樣的問題，應該是設計時少考慮了什麼！」
是的，大多數軟體工程師從初學者階段開始進入到能夠獨立工作的時候，大多會需要自己考慮一個功能的設計，直到一個完整的系統設計。然而，我們總是找不到正確答案。
永遠要看情況
其實，不管是誰提出了怎樣的問題，現在要我給一個「方案」我大多只能告訴對方「這需要看情況」舉個例子，以購物網站來舉例，我們在 PChome 上面購買商品，跟在 LINE 上面購買商品，都是「購買商品」這一件事情。然而會因為商品的類型（實體、虛擬）以及是否能夠退換貨、獲得紅利點數等等不同的「情況」必須將系統的設計做出不一樣的調整。
這就表示，大多數時候我們很很難用書本、網路教學等等提供的方法解決問題，因為同樣的概念，在不同的公司、產品會有無數種變化。
有生命的軟體
除此之外，很多時候我們會覺得當一段程式被寫出來之後，就不會再有變化。其實，軟體是根據人的想法去實現的，因此經過一段時間我們對他增加、刪減功能，這個軟體就改變了！
這就表示，我們的軟體是有生命的。跟生物一樣，會因為時間、環境產生改變，一個小型購物網站成長為一個大型電商需要的系統設計是不同的，因為要負擔的使用者、流量等級不同，用相同的程式碼很難對應這樣差異巨大的情況。
同時，如果所屬公司的計畫改變、所在國家的政策變化，也都會讓我們需要針對各種法律、行銷企劃等等情境，不斷的改變我們的軟體。
在一個軟體停止更新時，會用 EOL（End of Life，終止生命）來描述，確實是非常貼切的用語，因為當我們停止修改、更新，他就不會隨著現實狀況成長、變化，最後變得無法適應當下的時代。
維持軟體品質
如同我們需要運動、健身跟健康的飲食、作息一樣，我們對待軟體也需要思考該在哪裡調整、加入功能的時候是否會造成不良的影響。
這也是當代軟體開發中會對於 CI（Continuous Integration，持續整合）非常推崇的原因之一，因為我們需要持續的驗證今天吃了這個食物（功能）會不會造成不好的影響、這次調整了這個邏輯（穿搭）會不會影響原本的系統表現等等。
尤其軟體的構成在我們撰寫程式時，往往是由小而大的去觀察，因此常常忘記當系統變得極為複雜時相互影響的情況，在這樣錯綜復雜的系統之中，還需要經常性配合功能變化的重構（Refactor）來維持一個系統的穩定。
我們所處的時代變化的非常快，如果沒有小心的評估維持軟體品質的方法，很容易就會讓軟體生病，最後變得緩慢而笨重，最後不得不結束生命。
封面圖片使用 Unsplash 上 Sarah Dorweiler 的作品，有想聽的主題可以透過匿名提問告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。
