在项目的开发过程中，很多人都遇到过大量虽有不同，但有着共同规律的代码。比如PetShop项目的实体层，每个实体类中描述的都是对应数据库表的结构，除了表和字段名不一样，规律都一样。如果手动生成和维护这部分代码，表的数量少还好一点，如果稍微多一些，感觉一个工作量比较大，二个感觉很多重复性劳动，拷贝，粘贴，然后覆盖。针对这样的情况，大家都会选择做一个自动生成工具，用于实体层代码的生成，这样可以避免大量体力劳动，而且可以提高开发效率，以及减少数据库设计无法满足需求变化而导致的数据库表结构的变化的影响。典型的代码生成工具如CodeSmith。（安装过，但一直都没有使用，因为我喜欢自己来实现）
代码生成工具是项目辅助工具的一部分，其实，在项目开发过程中，为了减少重复劳动，降低出错的可能性，提高开发效率，我们都会做一些特定功能的辅助工具，比如代码生成，系统配置文件的维护等等。我们始终坚持着一个原则：只要能用程序做的工作，就不要浪费体力。也许实现辅助工具需要花一段时间，但完成之后，带来的方便和快捷是很明显的。（当然，如果这部分代码很简单，写完也就1分钟，修改的可能也不大，结果需要花1天时间实现辅助工具，那也就没必要了，视具体情况而定。）
先说说我所经历过的项目中的一些相对重要的辅助程序，以后会说说管理这些辅助工具在带来高效的同时，所带来的管理问题，以及所使用过的解决方法。
比如项目中有一层是数据实体层，描述了业务对象在数据库中的反映。按照最原始的方式，每一个实体描述类都需要手动去构造。怎么构造呢，就是每一个表写一个类，然后列出这个表的列做为类的成员变量。刚开始的时候，感觉没什么，因为不就是代码的拷贝、复制和粘贴吗，不会太复杂。可是后来在写实体类的时候，发现这样写太复杂了，一堆表，就是不停地拷贝、粘贴，也得一两天的时间。到时候，时间也花了，人也晕了，还无法避免库表结构的改动，这样的工作可真没挑战性。于是，做了一个代码生成工具，原理很简单，根据用户所选数据库和表，按照规则生成实体类。因为当时刚开始接触ADO.net，所以花了一个工作日完成并调试了代码生成软件。此后，不管数据库怎么改动，只要点击代码生成软件的一个按钮，一切搞定。既实现了功能，又获得了锻炼，一举两得啊。
比如项目中涉及到个Xml文件的维护，项目组的每个人只要需要，都可以新增或者修改改配置文件。（使用VSS进行项目控制，保证在某一时刻只能有一个人修改） 刚开始的时候，这样的修改也并没有出现问题，因为信息比较少，手动维护也没什么工作量。可是随着项目进行，所描述的信息量越来越大，大家改的也就越来越频繁，出现了多次从VSS获得最新的配置文件后，导致程序无法解析。因为信息量很大，打开配置文件后根本没法看，查找都不方便，很难快速的排除错误，最多的方式就是用上一个版本的配置文件覆盖。总是这样不是方法啊，没完没了。于是，开发了配置文件的维护程序，项目组统一使用该软件进行文件的配置。使用该配置程序后，就没有再为Xml文件的配置闹过心了。
再就是项目在上线的过程中，存在新老系统的并行，会造成新旧数据的整合问题，需要将原来的一部分数据按照新的格式导入新的系统中。想想，如果手动去转换，那弄完之后，还不得变成机器人了。于是，做了一个数据转换程序，用程序来控制。包括写代码、测试，花了一段时间，但一劳永逸，不用专门的人来手动转换数据，只需要查看日志，就能了解哪些数据转换成功，哪些数据转换失败，然后检查该数据的原始数据，找出原因，然后再次启动转换线程就可以了。（这个程序是最让我难忘的）
这些辅助工具的存在，提高了项目的开发效率，降低了项目的损耗，效果是明显的，而且也是所掌握技术的一种应用。最怀念的是实现的过程，最高兴的是看到辅助功能的使用。
在以后的项目中，都会首先考虑项目中是否有部分可以使用另一个程序来完成的，只要有可能，就尽量用程序来完成。
始终坚持着一个原则：只要能用程序做的工作，就不要浪费体力。
好了，暂时到这，该回去吃饭了。