在程序开发的世界里，各路前辈们为了提高所谓的编码速度，搞出了各式各样的代码生成器，来避免所谓的重复的人为机械地粘贴和复制代码，以此来提高生产力。
早几年前，我可能会认为这样的做法真得有用，特别是在编码速度上。
是的，有时候代码生成器是可以帮助我们开发者生成模板化的，规范化的，大批量的机器代码。
但许多人就将它当做了程序开发的利器，没有代码生成器完全没法写代码了，也没办法工作了。
觉得自己会用几款代码生成器好像很牛的样子。得意的在老板们，或是不懂技术的技术经理们面前炫耀：“XXX们，你看我的工作效率多高，你们的需求，你们想要的功能我只需要简单的代码生成就可以快速地搞定。”。
这种做法就好比别人把一头宰好并切好的牛肉放到你面前，再问你：“把这些牛肉放进冰箱需要几步？”
答案你也许知道了吧？没错，三步。
1.打开冰箱门；
2.放牛肉进冰箱；
3.关上冰箱门
很简单是吧？
那么，如果别人给你的是一整头牛，而不是切好的牛肉，再问让你把这头牛放进冰箱，你又怎么办呢？
上面的这个案例其实与开发者（特别是初级开发者）使用代码生成器有着同样的道理。
使用代码生成器的时候，这生成器就好比切好的牛肉，开发者在使用时不关心代码生成器的底层是如何封装的，也不知道内部逻辑是如何处理的。就好比不知道也不用关心那头牛是怎样被宰的，如何解剖的一样。
庖丁解牛是怎么来的？是屠夫们经过反复的实践，掌握了牛的结构、经络之后达到的一种境界。
在开发的世界里也是同理。
我见过不少开发者（绝大多数是.NET开发者，因为笔者主要专注.NET的开发）都是习惯并喜欢使用代码生成器来生成项目，甚至整个解决方案都能为他们生成就最完美了。
他们中有些人已经有5，6年或者7，8年的开发经验，不再是初学者了，但却还在用着传统的某某的代码生成器生成着传统的三层架的解决方案，在前端UI代码中充斥着各种DataTable和DataSet，各种if...else...逻辑判断，各种SQL语句拼接。。。
不知道看到此处的你是否正经历着相同的处境或者是经历过相同的场景？
也许你说：”我不是这样的开发者啊。“
那么作为热衷于开发的我感到很欣慰了，但这样的朋友应该不在多数，不然国内的.NET开发环境不会成如今这个要死不活的样。我的观点准确吗？
究其原因，不外乎是这样的：
在早年前，很多接触程序开发(本文主要是C#)的人中，都是看中互联网的高薪而加入到开发者这个大军中的，他们为的是钱途，而不是前途。他们不是真正意义上喜欢，或者说是热爱编程。
他们的骨子里或者根本就只是把程序开发当作多赚点钱的捷径。
他们在想：”我就在程序界里混几年，等资历老了，有个几年的开发经验或者是不停地跳槽，薪水自然就会不断地往上涨。等混到了30岁，就有资格做高级工程师，做项目经理，做项目主管了。有没有过硬的技术都不重要的。“
所以，如你，我，他所见到的如今的国内开发环境，真正热爱编程这份事业的，愿意深入研究技术的人很少，因为他们的目的根本不在于此。
他们只想通过简单的代码生成器来”赚快钱“，他们在编程界里呆了几年之后，还是不知道C#的面向对象编程思想，不知道泛型是什么，更没听说过反射，委托，事件，不知道还有设计模式，领域驱动设计。。。反正他们就知道有个叫“代码生成器”的东东。甚至还惊讶地问：”原来C#还有这么些啊？“
试想一下，如果代码生成器都能搞定我们的编程工作，那像Microsoft,Google,百度，阿里，腾讯等等这样的以技术为驱动的科技公司为什么不直接写一堆代码生成器就好了，何必每年养成千上万的开发者呢？
再说得具体一些，比如我们使用某某代码生成器来生成三层架构(这是很多C#初学者在入门或者开发生涯的前几年中最熟悉的套路)，这个架构中包含三层：实体层，BLL，以及DAL。
随着一个项目需求的不断变更，你的数据表结构是不是也会变更。那么，问题是不是来了，每次变更表结构，你是不是需要重新生成这三层的代码，然后把原来的代码替换掉。
如果你在这三层的任意一层中添加了自己的代码，替换时是不是又会遇到问题呢？
那你有没有想过，有没有办法能解决这些问题呢，而不是一味地抱着代码生成器过日子。代码变更完，对应修改UI中的逻辑判断后就万事大吉。
笔者描述了这么多，想表达的是（特别是对于C#初学者来说）：刚入门或者初级阶段，更多地要手写代码，多熟悉.NET Framework中的类库，老是想着：“代码生成器能帮我搞定的”是学不到真正的高级编程知识和技术的。
如果你执拗地喜欢利用传统的代码生成器去解决你项目中大部分工作，那么恭喜你，你入错行了，请趁早离开以免被坑得越来越深，因为你不热爱这个事业，你迟早也会走的，这样只会浪费你的宝贵的青春。
结束语
如果选择了.NET这条路，请用心，认真对待，因为这是你的事业，你的付出也会得到回报。