尽早抽象和持续重构

程序员在日常开发新的功能或重构已有功能时常会预见两种选择：
1）可预见的抽象，尽早抽象，自顶向下推进重构；
2）不可预见的抽象，持续迭代重构；
当发现了可抽象的点时，应该尽早抽象——这是基于时间和精力成本来说最优的选择。但是囿于业务不清晰或抽象能力、看不到抽象点时，此时选择踏实的实现功能，然后持续重构也是大数路径。

一、可预见抽象时，尽早抽象

在开发一个功能时或多个相似度很高的功能时，此时如果能预见性或预先识别出或抽象出他们的公共逻辑。

1. 优点：

1）高度的抽象可以简化功能流程和模型；
2）节省开发时间；同样逻辑写一处即可；
3）节省后期修改时间；抽象合理的话代码逻辑也会比较清晰，代码更易于修改和重构；

NOTE：开发加后期修改的时间可能相差数倍。

2. 难点：

1）对抽象能力要求较高

二、不可预见抽象时，选择持续重构

若一个功能当前无法预见或看到共同逻辑，则需要持续迭代重构；在看不到抽象的可能时，持续重构是当前最好的选择。

1. 优点：

1）易于上手

2. 缺点：

1）后期重构耗时较多；
2）如果不足够抽象，会导致业务逻辑不足够清晰和易于理解；

三、有意识提高抽象能力

这两种选择往往和抽象水平，开发经验和具体功能相关。不可一蹴而就，但需有意识提高抽象能力。