这次代码重构大赛，我们团队没有上榜。
反思：
（1）一定要知道验收人的真实需求。表面上是重构代码，实际上做的是需求。
业务验收人的依据是，简单好找，具体是：把所有逻辑中与taskName相关的操作都抽出来，做为工厂方法的输出
【注意：没有提逻辑结构，没有提抽象层次。仅仅是简单，好找】
这些处理类，是一个处理流程中，不同环节，不同条件下的一个处理类。
一个流程走完会用到2个以上的业务处理类。

（2）扩展性好的定义。
业务验收人的认为的扩展性好是指：在上一个基础上，把taskName和version作为工厂类的入参，输出处理类。
【注意：这个扩展性好，是业务层面的，不是代码层面的。】其它团队也使用了工厂，唯一不同的地方是没有满足（1）

（3）最后一定要“罩面”。
要输出漂亮的PPT或Word文档。
要把部门中强调的重点：复杂度、覆盖率、CI（在重构过程中，代码怎么一步一步变好【展示这个有毛线用处？不懂】）

反思：
表面是重构的代码，实际展示的东西在代码外。
大哥，那个Leader或用户仔细看过你代码，就是看过了，那个知道好在哪，不好在哪。代码好与不好，见仁见智

反思：
要先把要点梳理出来，以点带面。