前言
《小酌重构系列》是我在博客园的第一个系列文章，这个系列历时一个多月终于完成了。
完成这个系列后，心里有一些感慨想和大家分享一下。
初衷
写这个系列的初衷是为了团队培训，为什么要做这个培训呢？
是因为在项目的开发过程中，我们遭遇了一些“代码的痛苦”。
代码的痛苦
写代码是程序员的基本工作，但写出好的代码不是一件容易的事情。
写不出好的代码，就可能产生痛苦。
代码的痛苦包含哪些方面呢？
一般来说，包括可读性较差、不够简洁、缺乏可扩展性、缺乏可维护性等等。
简单地说，就是代码质量不高。
“代码的痛苦”也是开发者的痛苦，低下的代码质量可能会降低系统的稳定性。
系统最终是要交付于客户的，系统如果不稳定，客户用的时候会痛苦会抱怨，维护时你不仅要忍受客户的抱怨，还要痛苦地去维护“代码的痛苦”。
痛苦的诱因
这些痛苦并非是无根之源，痛苦的产生是多方面的，不仅和编码有关，也和管理脱不开关系。
在这里，我仅从编码角度去分析这些痛苦的原因。
编码风格的差异
在项目开始前，我们是约定了一些编码风格和规范的。
但实际做下来，由于各成员的编码风格差异，使得有些代码看起来“五花八门”。
为了统一项目的代码风格，一些成员不得不返工去修改代码，并且返工不止一次。
编码习惯的不同
每个人已经形成了一定的思维方式和编码习惯，即使是一些不好的习惯。
这使得一些曾经发生过的问题，在后续的开发过程中仍然反复地发生。
编码意识的匮乏
有些成员专注于功能开发，对代码的规范、整洁度和质量看得较轻，也没有意识去思考如何写出优秀的代码。
当然这也和编码习惯有关，习惯性的不去思考代码质量的问题。
代码审查的匮乏
限于时间和资源问题，在项目中我们只能花费较少的时间来进行code review。
虽然每次code review能发现一些问题，但每次代码问题的解决方式都只到表面，内里没有得到根本性地解决，这也是一些问题反复发生的原因之一。
期望的目标
代码的痛苦就好比一个慢性疾病，现在我们已经知道了自己得的是什么病，以及病发的原因。
接下来要做的就是如何科学有效地治疗这个疾病，让自己渐渐康复起来。
于是在团中，我就做了这个培训，这个培训主要有以下几个期望目标：
- 提高团队成员的编码质量
- 促使团队成员形成统一的编码风格
- 提高团队成员的编码意识，养成思考和自主code review的习惯
- 希望最终的交付物不仅能满足客户的需求，还具备良好的维护性
仅经过一时的培训，是不能够解决代码的痛苦的，于是我们采取了培训+实践的方式来解决痛苦。
在经过大约2周的培训，以及近2个月的反复实践后，团队成员整体的代码质量已经有所提高。
关键的是，一些缺乏意识的团队成员已经产生了自主思考的意识，知道去思考代码的一些细节了。
关于这个系列
草稿和大纲
在开始这个系列之前，我使用Onenote基本打好了所有的草稿，这些草稿的内容大多是一些文字和图示，代码则单独地放在VS解决方案中。
所以在开始正式写第一篇文章时，我就列出了整个系列的大纲。
草稿终归是草稿，真正动键盘时，还是发现草稿中有很多瑕疵存在，以致于草稿中的文字我基本没有用到。
草稿并非没有作用，每次我都会站在第三者的角度去审视和思考草稿的内容，它指引我向更深处去思考一些问题。
限于本人浅薄的知识和穷乏的描述能力，有些深入思考的内容没能在文章中表达出来。
计划和坚持
如果只有一天的计划，让自己按时做完这一天的事情，我相信绝大多数人都能够做到。
生活和工作每一天都在继续，我写这个系列，是想让自己每一天都能按计划进行下去，更是想让自己长期地坚持下去。
在开始这个系列时，我乐观地计划每天应该完成一篇。
诚实地讲，我知道自己不可能100%的完成这个计划，能有80%就不错了。
因为每天都会有不同的事情出现，有些事情你是不得不去优先处理的，其他的事情很可能导致完成这件事情的周期被拉长。
定这么个计划，是为了时刻督促自己要坚持完成这个系列，不要半途而废。
很多事情要做就做完，做一半还不如不做。
我个人比较欣慰的是，虽然中间因为假期暂停了将近10天，但假期一结束后，我立即接续完成了最后的几篇文章。
收获
这个系列带给我的收获主要有两点：
- 写文章是希望能教一些东西，写文章的过程也是再思考再学习的过程，就像《暗时间》里所说的“教是最好的学”。
这个系列完成后，不仅可以分享一些知识，也使得自己对重构的认识又上升了一个台阶。 - 本人的文字描述能力一直比较欠缺，特别是文字占了较大篇幅的文章，这样的文章更考究作者的思路和逻辑。
通过这个系列自我感觉文字能力有所提升，在团队的一些会议中，个人的现场描述能力也有所提升。
后续
关于重构这个系列并没有完结，之后我会挑一些项目中实践的代码作为示例为大家解释重构的过程。 接下来我还将写几个系列的文章，近期应该会写JavaScript系列或ASP.NET MVC系列的，尽请期待。