开发一些自动编写代码的工具可以增加效率吗？

　　我所在的公司这段时间计划着开发一套或者几套代码自动生成的工具，其中包括 Actionscript、JAVA web的后台逻辑、也许还包括一些前端HTML或JS的逻辑等等。

　　我被挑选成为 Actionscript 这一块的负责人，哎呀真是与有荣焉，但实质上心里感觉这真是要了我的命。

　　公司主营是ERP项目的开发，在我的Boss看来，我们做的事情全都是在重复劳作，当我们用FLEX开发一个前端模块的时候，我们无非就是在：开发界面；向服务器请求数据；将数据绑定到界面元素上；控制权限（其实只是将某些按钮隐藏或者无法交互）；添加事件监听，编写业务功能逻辑（包括实现前端的CURD逻辑）；将最终数据提交到服务器保存等等。我们甚至将每一个开发过程中的技术点比喻成了“工艺”，将开发整个模块所需要用到的技术点的合集称之为“工艺路线”，这样的命名已经写在了公司的WIKI上，成为了我们交流中统一概念的名词。

　　而我，则负责将这个“工艺路线”，编写出一套能按照配置文档自动生成所有“工艺”并最后编译成能部署运行的SWF的工具。到时，我们所谓的“软件开发”，就只需要按照项目需求去维护那一份强大的配置文件，不写任何代码或者只需写极少代码（我的Boss认为超过3行就是多了），就可以产出到达交付预期的产品。这时候，我们所需要的“开发员”门槛将极大的降低，对计算机专业知识以及学历经验都将没有任何要求，他们就只是一个个流水线上面的装配工人，经过以小时为单位的简单培训马上就可以上岗。“这将是IT行业的一个革命”，我的boss深情的说。

　　按照我Boss的尿性，他甚至会希望我做出来的东西能适应目前还没出现的需求，一次成型，永无后忧。之前就曾试过因为我某个模块没有适应到某个新遇到的需求而称之为“bug”，是的，他并不认为这是程序功能上的某种提升或拓展，这只是对漏洞的修复，是亡羊补牢。

　　目前的我，既认为这是个不可能的任务，也认为做这个没有多大的意义。

　　说不可能，其实是对于未知的一种尊重。抽象，能将复杂的事物变得简单，但过度抽象的最终结果，则是虚无。画画有什么难的？无非就是沾上颜色在画布上涂涂抹抹；音乐有什么难的？无非是各种音符的排列组合。我们确实可以将某些业务、某些功能抽象成简短的几句话，但并不意味着我们真能将这些话语转变成代码实现。程序的抽象是有极限的，不管是面向对象，还是面向切面，都试图厘清程序开发的边界，我们不应该（实际上也无法）开发万能的类或者模块。同时，囿于人类头脑的局限性，即便是同一个功能下，我们也终将不能把所有方面都考虑周全。

　　说无意义，则是从代码的角度来说的。在软件设计中，有一个DRY原则，do not repeat yourself，不要重复你自己。讲的就是相同逻辑的代码不应该不断重复出现在你的代码里，它应该被重构。但自动生成代码的工具将反其道而行之，无他，工具生成出来的代码必然是每次都一致的，它本身并不具有创造性，甚至连错误也都一并复制。在这样的情况下，不断重复的代码将散落在系统的各处，除了对性能的极大影响之外，对于系统的健壮性也是严重的考验。

　　实际上，这款工具的编写过程，就是不断将原本写在代码里面的各种条件判断语句或者方法参数，放到了配置文件当中，也是将某部分的逻辑，在配置文件中编写。最终的配置文件的编写过程，也就是换了语法的代码编写的过程，这个所谓的生成工具就是将配置文件翻译成Actionscript语言的工具，这个过程，甚至可以创造出一门语言（为了达到已知与未知功能的覆盖，是不是甚至需要图灵完备呢？）。这就是我认为无意义的所在。

　　其实我也并不是真是觉得开发一些粗略提供部分代码的工具一点用处没有，主要是现在要求真是太高了。。。

　　那么，提高编程效率的真正途径是什么？

　　我认为是用软件工程的思想去开发、维护我们的代码。计算机诞生已经好多年了，在这门学科上，我们已经有很多前人的经验可以借鉴，不管是oop、aop、函数式编程、软件设计模式等等各种经验总结都是为了提高效率，为什么不去使用它呢？

　　我们是一家技术公司，但是我觉得它太不尊重技术了。

　　是的，现在很多程序员在网上会自称“码农”、或者“程序猿”来自嘲，但我从来没想过，在自己的公司里，程序员的定位竟然跟传统劳动密集型工业里的工人定位如此接近。