# How to rewrite, a bit at a time
###### tags: `ddd`
###### 參考: [How to rewrite, a bit at a time - Sabrina Leandro - DDD Europe 2019](https://tinyurl.com/y4jnmhso)

## 如何開始計劃
有些專案像 monolithic 系統, 把很多功能放在一起, 沒有把物件做很清楚的抽象化. 或者是區分成太多的 feature, 抽象化的物件太細過於複雜.


### How to start it?
對於這些現有的複雜系統, 要如何使用 DDD 的技巧來改善呢？
首先要針對幾個問題, 來判別改善的時機跟方法是否正確？

### Is it the right time?

當目前的 product 專案對於 business 是有價值的, 是值得花時間投資在上面去改善它.

### Is it the right reason?

確保自己有良好的理由去改善一個舊有的專案的架構. 如果對於這個專案的 business case 的需求不了解, 最好要先去了解它在進行改寫.

還有一個重點就是公司要能夠有足夠的資源, 人力和時間提供你來改善它.

### How to sell it?
找到一個好的 business case 可以有效地訂出一個明確的目標, 當之後要決定一些決定性的問題也可以幫助你決定.
展現如果專案改善後, 可以有哪些好的益處? 例如, 大幅改善測試流程的效率, 新的框架更好開發之類.

#### Make Pain visible
列出專案目前遭遇的問題, 不需要太深的技術細節, 但是需要讓其他人看得出來遇到的點, 幫助其他人理解, 願意花時間與資源來改善它. 在不斷的溝通下建立出一套對於此專案的通用的語言, 讓技術與非技術人員可以理解彼此的想法.

## 如何執行
首先需要在團隊中討論出未來改善的架構是如何？ 一開始不需要太深的細節, 只需要對於訂出一些準則與改善流程, 確保團隊人員都知道最後的要達成的目標, 其餘細節會隨著改善的時間推進來持續反覆檢視與修正.


### 流程

#### scratch

一個 team 繼續維護就有的專案, 另一個 team 進行改寫, 直到新的專案改寫完成, 舊有的專案就可以丟棄了.
但是這種開發流程有很多問題. 因為這樣的開發只有在完成新的應用出來, 價值才會被顯現出來. 而且有可能在開發過程, 公司新的方針改變有可能需要回頭修正與改寫, 需要花費許多的時間.

#### stranger
**strangler fig** 是一種寄生植物, 以附生來開始它的生長，然後通過根莖的成長成為獨立生活的植物，並採用擠壓、攀抱、纏繞等方式盤剝寄樹營養，剝奪寄樹的生存空間，從而殺死寄樹.

作者用這種植物作為比喻, 來解釋另一種開發流程:

繼續維護原有的專案, 慢慢把裡面重要的 feature 抽出來改寫. 每改完一個 feature 舊專案都能使用其帶來的優點. 直到所有 feature 更改完成, 舊有的專案也已經變成新的改良的專案了.

這種開發流程也是演講者所推薦的,下面用兩張圖來解釋:


針對 customers 的 feature 進行改寫 new/customers並且進行相關測試.


經過完整的測試後, 就可以直接轉移到使用新的 customers 功能.
接下來就是依照這個過程不斷的改良舊專案.
:::info
1. 建立要改善的功能
2. 驗證
3. 取代舊有功能
4. 刪除舊有的功能
5. 回到第一步
:::

### Cut features to move faster
檢視功能的重要性讓開發更快推進. 必要的功能 ,有時間可以做的功能, 無用的功能直接移除. 有時刪掉直接重寫還比較快.

* Must haves: main proportion
* Should haves: if there's time
* Won't haves: remove completely

:::warning
If we were starting over, what would we build today, Knowing what we know now?
:::

再重複這些過程中, 我們應該知道我們現在在幹嘛.

## 改善的過程
### How to run it

:::info
Do one thing at a time
:::

找出專案的問題點, 以此制定一個主要的目標, 並有一個實際的計畫去完成它.

**1. Find the biggest blocker
2. Remove it completely
3. Repeat**

和業務團隊與客戶了解哪些是必要的功能, 哪些不必要可以移除.

### complete feature
:::success
**經過漫長的改善終於完成改善計畫, 別忘了好好慶祝**
:::


演講者團隊設計師還設計出幾個有趣的徽章, 給完成項目的團隊員工.

## 如何完結

### 如何不再需要改寫

* **Make the cost visible**

當程式開始運行後, 別忘了還需要繼續維護. 維護也是需要花費精力, 所以需要定時和 PM 討論哪些功能需要繼續維護, 哪些可以屏除.


我覺得這點很重要, 就是沒用的 code 要刪掉, 而不是註解放在那邊, 那些通常會讓程式碼變得更難被解讀. 有些過渡期的 feature 和產品需要被移除也是常見的.

* **Make it part of your day-to-day**
保持每天持續檢視專案與小小改善, 這樣就不會又需要重新改寫.

:::success
A refactor a day keeps rewrite away!
:::

* **A little bit and often**
* **Get used to inconsistencies**
使用 version control 工具去不斷改善 code, 要習慣code 在 merge 後有時會有不一致的情況發生,去解決 code 的衝突.