重构之重与敏捷之轻---身份证号重构回顾

寻找重构的案例

重构的案例很差选取,咱们本身实际的项目固然有很多重构的状况,却不适合做为文章阐述出来。并非由于保密的考量,而是业务自己的内容太复杂。固然，这个复杂是相对的,对短短一篇文章来讲,那怕是最小一部分的业务逻辑拿出来,也显容量不够。并且,过多的阐述业务逻辑,致使喧宾夺主,掩盖了重构的注意力。因此,要选取一个你们都熟悉的东西,身份证号偏偏中了我第一个要求。

即然是重构,必然要有个原始的版本,并且,要完成了实际的功能。开源中国的代码分享也恰好为我提供了一个资源库。代码分享这个平台,真是太理想了,代码规模不大不小,每个分享又有一个明确的目标功能。
看起来,确实是个金矿。但是随着深刻的搜索查看,能进入我目标范围的倒是寥寥无几。大部分代码只是粘合剂,把外部库的调用综合起来,完成一个任务而已。还有些代码,方法体太大,而代码倒是简单重复,彷佛重构的必要,却未能展示出重构该有的不一样侧面,并且也有前面所提到的毛病,是粘合剂代码块。
（本文版权属于© 2012 - 2013 予沁安 ）

而当我看到身份证这三个字,才眼睛一亮,看似简单的身份征号包括了太多内容:

1. 它是一个典型业务域的Value Object(不要与C#语法概念的Value Object混淆),咱们本身的系统中,恰好也有作一个身份证号值对象的想法。以前咱们已经做一个月份对象(YearMonth),很是好用,可是,由于功能多代码量大,不适合做短篇。
2. 它没有对外部库的依赖。不是说,我只能对这种独立的代码重构,而是限于篇幅和重点突出的考虑。
3. 它的业务逻辑很大众化,谁没有身份证呢?
4. 分享代码已经把足够的业务逻辑包含进起,我所作的就是保持这个不变全力集中在重构上。再完美不过的重构案例了。

敏捷的方式重构和做文

让子弹飞

定下了目标,当开始作的时候,满脑子都是想法。原代码是Java,要改为C#; getXX能够用属性方式,更为简捷;既然是Value Object,彷佛用Struct比用Glass更合适;做为Value,它应该是个不变类(Immutable),所以不该该动态解析,在构造器中解析,更为恰当; Validation的实现也不太合适……
是的,像我这样资深的敏捷实践者,在第一时间仍有这种冲动,太多想法立刻实现的冲动。这实际上是人的一种天性,不要紧,我就让思惟的子弹先飞一下子。
子弹乱飞以后的寂静,我想到的第一件事情就是补测试。说到测试,我用MSpec曾屡屡想为MSpec作个入门介绍,却一直未能成文，而直接使用MSpec的博文我却已经写了很多, 你们就在实际用例中学习Machine.Specification吧。
说是补测试,其实从Java到C#的编泽错误修改已经开始了很多改动。测试这一块是原代码彻底缺失,补上这个,能够说是重构的一部分。

迭代一：

准备工做作了很多，到最后,真正测试只写了一个GetAddress()。而这成为了个人第一天。第一个测试成为我第一天的目标,围绕这个目标,我放弃一切与此无关的工做,特别是以前子弹乱飞的内容。

迭代二：

次日,要作的事情一会儿很是明确,循序渐进的把其它的功能测试一一补全：生日,性别等等。几乎不太用脑子,有时候,事情就是这样,有波涛汹涌,有风平浪静,惟有测试是船舵。
从测试的条数来看,次日进展很快。写出来的内容也显丰富。

迭代三：

第三天的进展就顺利多了。把各个功能测试一一补全经过，如生日，性别和验证。其中有个小插曲，验证逻辑提炼成独立的类。总结起来没有什么好说的，重构自己却有看头。

迭代四：

到了第四天，才真正开始作我想要作的事情，整理逻辑，清理代码。再加上代码覆盖工具DotCover的帮助，VS的复杂度分析，从另外一个侧面对重构效果加以验证。其实应该在重构以前也分析一下代码，两相比较一下，效果会好不少。

今后，xx和xx过上了幸福的生活......

个人博文算是结束了，但是做为代码的改进，其实并无结束，甚至我最开始的想法，有一部分都尚未完成，如struct。我还丢掉了一部分业务，如15位号码转换18位。这是做为重构的展现已经足够。最重要的是，我已经创立了一个健壮的<测试-实现>对，这个基础上你能够继续完善。

代码自己的技术含量并很少，但重构的流程，任务细分，小步前进的理念，却表达的很是充分。做为体验，若是你能按照我走过的流程，再踏踏实实走一遍，会有彻底不一样的感受。敏捷是实践，重构是实践，惟有实践才能体验实践。（本文版权属于© 2012 - 2013 予沁安 | 转载请注明做者和出处）