今天带领部门重构团队参加无线院深圳地区代码重构的现场评比，并勇获第一名的好成绩，大伙对结果都很满意！我也履行了带着大家拿大奖的承诺，很开心：）
下面对整个过程进行回顾：
重构对象：简单来说就是一个”大泥球“O(∩_∩)O哈哈~
WELL:
-
- 最好的结果
- 赛前预计可能会得奖，但没想到能得第一，个人感觉还有不少重构点，结果有点超出预期！
- 增加部门后续参与重构的积极性，让大家对代码质量重视起来。
- 多维度重构
- CC：主要涉及命名、注释、格式、函数这四个方面，强调消除冗余，增强意图表达。这里值得注意的是在对大函数进行抽取时，对于不熟悉的人来说会觉得拆得过细，常常会提出”每行都要用一个函数来表达吗？“这样的疑问，因为他们还没掌握不同的抽象层次划分要领。
- 设计原则：运用了策略模式和简单工厂，实现了开闭原则，消除了重复的逻辑过程；遵循单一职责，将上帝类进行了合理拆分。
- 代码度量：当完成CC和设计原则后，往往是代码度量大显神威的时候，它会为迷失的重构者指明方向。这次我们使用的度量工具是比较轻量级的SourceMonitor，让志得意满的程序员们再次绷紧了神经。其实重构就是这样的，永无止境！
- 业务深度梳理
- 这次在业务梳理方面也下了不少功夫，并且发现了原始代码的若干问题。这也是不小的亮点。
- 新需求的实现
- 成功的完成了并行的新需求，实现过程和方案清晰、明了。
- 业务沟通澄清
- 在重构过程中，多次找业务接口人进行了澄清，保障了重构方向的正确和新需求的理解。
- 代码实现接近原始风格
- 这点我觉得做得也不错，客户满意度会最大化。当然如果违反了基本原则，还是应该引导客户进行修正。
LESS WELL:
- 测试用例
- 短板，用例设计不是太合理，用例覆盖肯定是不太够的。
- 用例代码冗余，我提供一个BDD模板也没使用，想想GTest都不太熟悉的话也不好提更高的要求了。
- 领测试用例任务的同学，太小看测试用例了，哈哈！如果是TDD方式的话，这块就是核心！就算是测试后行实现起来也不简单！
- 重构过程
- 会出现耐性不足的情况，”差不多“心态会出现。其实真正好的代码是需要反复锤炼的，每一次对代码重构的绝望都是提升能力的好机会，要有耐心和信心去克服它。
- 现场讲解
- 现场讲解的逻辑性有待增强，还需要勤加练习！演说能力的修炼跟重构一样也是”深坑“，永无止境的。
- 人员成长
- 本次重构采取分工合作的模式，有”能者多劳“的情况，每个人的收获自然也不会一样。怎么让大家都得到较大提高是后面需要深入思考的问题。
PUZZLE:
- 还是结果
- 好的结果会让人麻痹，下一次该如何应对呢？
- 简单设计
- 简单设计的滥用，现在只要做设计就打着”简单设计“的旗号，实际上做着背道而驰的设计，”不多不少，刚刚好“说起来简单做起来还真不易！
- 版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！
