从事代码重构已经很多年，特别是目前手头维护的几个软件，在开始接手时，面临着没有交接、代码基本没有注释、代码风格各种各样，接手该软件的人员也是已经换了2,3波了。
总体来看，代码是没有开发经验的人员写的，虽然是用C++编写的代码，但是风格还是C风格。基本没有Class，更加没有面向对象的思想在具体代码中的应用。整个代码逻辑是面向过程的，99%都是结构体的数据结构。维护的人员，可能没有弄懂代码逻辑，所以在改造点，会拷贝一份代码进行修改，再强行添加一个分支。虽然这样做，可以确保以前的功能基本不受影响，但是重复代码非常多，并且如果后面如果需要修改的功能涉及到所有地方时，由于拷贝的地方多，会很容易造成修改的地方遗漏。
其次，后面维护的人，在添加新功能时，当用到旧模块的数据时，为了调用方便，就会定义全局变量。这个全局变量，会在很多地方使用。同时又不考虑多线程，数据的的保护机制基本没有，造成软件的稳定性很差。并且由于采用了结构体，数据的隐蔽性没有，很多地方之间使用结构体的内部成员，当需要修改内部成员时，也会造成遗漏修改。
最后，整体代码没有逻辑层次的概念。从这个软件的应用场景来说，我觉得应该分为驱动层、数据层、业务层（服务层）、外部接口层。而我接收的代码，在驱动层有些弄巧成拙，把各种设备都建立一个Dll工程，导致工程数量达到7个之多；而且，这些Dll实现的代码，90%都相同的，造成过度设计。数据层的管理采用数据链表结构，并且考虑到多线程的使用，采取了锁保护，基本能达到使用，但是因为数据结构都是结构体，数据的拷贝和查询并不简洁。而业务层与外部接口层没有分开，相互间没有清晰的划分。并且外部接口会直接渗透到业务层，有些接口甚至到达驱动层，造成非常紧密的耦合。
而客户端页面，可能人员的开发经验不足，竟然各种Dialog都是自己写一套代码描画出来，使用Hook构造一套鼠标、键盘消息。明明使用的是MFC工程，为啥不适用MFC的Dialog呢？更加奇怪的是，页面的各个组件的布局，在多语言中，都是用宏写死，当修改某个语言时，还需要不断修改宏。更可怕的是这些宏还是相互关联的，要不断修改、测试才能达到页面布局显示正常的效果。而后来维护的人，也知道这种代码维护性差、效率低。但是由于没有重构的勇气，仍然“照猫画虎”，继续拷贝、修改。后来我问他：“这样的代码为啥不重构呢？”。他说：“我觉得这种代码结构很简单啊，拷贝一份，再修改，也不需要花太多时间。”。看来他已经被同化了，他完全不知道“重构”到底是什么？能够释放出多大威力。
我接收的这些代码，总量大概有30~40万行代码，基本都是C++编写。开始开发人员有8个人，下一篇我将讲解怎样重构这套代码，敬请关注。