我想重構程式碼可是主管跟團隊不支持怎麼辦？

[Jian-Min-Huang]

• Legacy Code 換個角度看可以稱為祖產，而祖產迄今產生的價值可能超過你職涯的所得
• 切記！沒有測試保護的重構不叫重構，叫做搞破壞
• 要重構就要確認好做好測試的保護
  • 不影響到業務
  • 不影響到其他系統
  • 評估影響範圍，就算發生的錯誤也能即時挽救
  • 然後勇於承擔責任
  • 那這樣的重構才有意義
• 那如果你確認你擁有上面的要件還是不給做，那就是老話一句，改變不了環境，就改變自己
• 留下來看淡或是離開

[jimwayneyeh]

如果有好的理由，重構可能會更容易推行。例如有辦法量化出重構後的 effort 降低多少的話，可能就會更容易獲得主管或團隊的支持。

我之前估計的方法是衡量 dependency 數量減少多少，以及新增一個相似的功能可以減少多少程式碼。不過我自己覺得這個量化方法沒有很好，也希望有大大提供更合適的量化方法 XD。

[Jian-Min-Huang]

如果有好的理由，重構可能會更容易推行。例如有辦法量化出重構後的 effort 降低多少的話，可能就會更容易獲得主管或團隊的支持。

我之前估計的方法是衡量 dependency 數量減少多少，以及新增一個相似的功能可以減少多少程式碼。不過我自己覺得這個量化方法沒有很好，也希望有大大提供更合適的量化方法 XD。

你這段蠻好的，我應該補一下為什麼要做重構 #8

[bruce770405]

如果確定要重構，是要以function的粒度，小步漸進的分段規劃嗎？
時常碰到一個情況是，想太美好，一次把一塊程式做了新的 design pattern 之類的，造成許多 unit test 也要大改一番，要加新的unit test ，有經驗後發現這樣風險和成本也好高

[jimwayneyeh]

如果確定要重構，是要以function的粒度，小步漸進的分段規劃嗎？ 時常碰到一個情況是，想太美好，一次把一塊程式做了新的 design pattern 之類的，造成許多 unit test 也要大改一番，要加新的unit test ，有經驗後發現這樣風險和成本也好高

小步漸進地分段進行比較好。可以參考 Martin Fowler 的書，他認為大型的重構是由很多個小型的重構所組成的。透過這樣有規劃的步驟，才有辦法確保重構完的商業邏輯跟重構前是一樣的。

[Jian-Min-Huang]

如果確定要重構，是要以function的粒度，小步漸進的分段規劃嗎？ 時常碰到一個情況是，想太美好，一次把一塊程式做了新的 design pattern 之類的，造成許多 unit test 也要大改一番，要加新的unit test ，有經驗後發現這樣風險和成本也好高

推薦去上課，真的會有收獲

[rayshih]

重構應該要配合對於 problem scope 的 insight，沒有 insight 重構容易沒有方向。有 insight 也比較好說服團隊為何要重構

如果 unit test 跟 insight 衝突，那 unit test 應該要修正或是捨棄