在很多時候，我們都知道如何開發，如何部署，並成功將應用程式上線，但是我們卻忽略了一個重要的部分，那就是上線之後的後續開發，和下線之後的維護。

在上線後的「繼續」疊加功能，我們稱為「攻」；而如果線上的程式要退下來，或替換成新的版本，我們稱為「防」。

「攻」的機制

在上線後，我們會繼續開發，這時候我們會需要一個機制，讓我們可以在不影響線上服務的情況下，繼續開發。

這部分要怎麼「攻克」呢？這應該要在上線前就想好的，因為這是一個很重要的部分，但大部分工程師都會忽略，只管上線，不管後續的開發，或者一句「先上線再說」或者「那不是需求」就把這個問題給拋諸腦後了。

而且這部分的危機都是隱藏的，不會在上線前就出現，而是在上線後，開發一段時間之後才會出現，這時候才會發現，原來我們沒有考慮到這個問題。

上線前，多問幾個如果

在上線前，我們應該要多問幾個「如果」，例如：

1. 如果我們要新增一個功能，但是這個功能會影響到線上的服務，我們要怎麼做？
2. 如果我們要在「A」功能上，新增一個「B」功能，但是「B」功能會影響到「A」功能，我們要怎麼做？
3. 如果...

依照你的應用程式的複雜度，你可以問很多個「如果」，但是你要問的是「如果」，而不是「要」，你可以在腦海中演練如何開發。

弱點發現

在問了一堆如果後，你會發現肯定有一些地方是你在「整個」結構中，存在矛盾的，這種矛盾功能是不可能被兼顧的，這些功能就是這個 AP 的弱點，你必須要找到這些弱點，並且在上線前就解決掉，或者被揭露。

例如有一個購物網站：

1. 需求是，我們必須要登入才可以購物，這樣的情況下，我們就「不可以做」未登入的購物車，因為這樣是矛盾需求。
2. 我們有一個「文章」功能，這個文章功能，必須要登入才可以發文，發文必須要有「作者」，但是我們的「作者」是從「會員」來的，這樣的情況下，我們就「不可以做」未登入的文章，因為這樣是矛盾需求。

「防」的機制

在功能上線後，我們要對每個功能的「下線」做好準備，這個準備就是「防」的機制。

例如我們有一個「登陸」功能，如果我們現在要替換，這個這個功能，應該怎麼做呢？

如果沒有想好，或者沒有做好，耦合就會出現在 AP 的任何一處，要切割也切不乾淨，這種老系統的問題，就是防不勝防的。

SOLID

事實上，這個問題，已經有人想過了，這個人就是 Robert C. Martin，他在 2000 年提出了 SOLID 五大原則，這五大原則，就是為了解決這個問題而提出來的。

因為只要你有可以做好SOLID原則，要做替換和切割，就會變得很容易，而且不會影響到其他的功能。

總結

1. 在上線前，多問幾個「如果」，並且找出弱點。
2. 在上線後，要有「防」的機制，讓你可以輕鬆的替換和切割功能。
3. 回去溫習 SOLID 五大原則，並且實踐。