前言
（本文为搬运，做了压缩） “任何你重复了两遍以上的事情都该自动化。”这是个听起来很有道理的信条，但小心，实现自动化的成本可能比被自动化的部分还高。
下面是一则真实的故事。
一个真实的故事
我们有个移动端的老应用，里面一段代码相当地重复，它主要负责创建一个sql表的模型和一系列CURD方法。每次创建一个表时，开发人员需要创建、同步表的字段并且创建这些CURD方法。
我们最开始开发时，主要需求都在如何将数据存起来，这也就意味着大概率会有更多的表和相关的操作逻辑。如下图所示。
自动化！没我们想得那么难
我们写了个自动化脚本来生成代码，我们输入一些参数，它能输出java代码到项目里，这个脚本运行得不错并纳入到我们的CI中。
当有需求变动……
然而没开心多久，我们发现生成的代码中有需要调整的地方，而且仅某些表的代码需要调整，改自动化脚本是划不来的，这个脚本甚至不是用java写的，所以为了快速上线，我们直接改了那几份生成后的代码。
到后来，这种情况越来越多，生成的代码老是有需要改的地方，导致生成代码与修改后的代码混杂在一起，没人想去维护这块。
自动化比它看起来代价更大
网传一句话：宁花10小时自动化，不花10分钟手动敲。
自动化并不那么的美好，下面是几个代价：
非常规代价
上述例子里，工程师们大多都是移动开发工程师，熟悉的是移动开发那套工作流、工具、语言。然而这个自动化脚本引入了非常规的因素：新的配置文件规则、新的编程语言等等。
这些新因素带来了新的学习门槛，并且由于大家不熟悉，使用起来也可能埋下不少坑。因此自动化时我们应该尽量做到如下两点：
- 最小化引入非常规因素，尽量选用大家熟悉的技术栈、工具、方法论；
- 尽量选择广泛支持的工业化标准，有坑也方便找资源。
维护成本
天下没有免费的午餐，哪怕是自动化，我们很可能是把手动工作的活转移为维护自动化工具的活。不要小觑自动化的维护成本，它可能非常的高。举个简单的例子，以前的持续集成工作流中，通常分为三块：开发、代码检查、部署，后面两块现已大多实现了自动化，那么在各个大公司里，这些被自动化的部分是真的不用再管了？不，大公司是单独开辟了一个部门：DevOps，专人看护。
因此，自动化的成本除了开发自动化的部分，怎么维护它也是个部分，但这还不是全部……
失传成本
按上面的说法，自动化的开发和维护成本越低就应该越好，最好就是一次付出永续收益，再也不用理的那种，那么，真的有这种好事？
试想一下，当这个自动化工具完美地运行几年，连它的开发者和维护者都离职而去，那此时它本身就成了一个黑盒，人人都知道它很重要，但都不知道里面做了啥，这时，这个工具的代码就有了“失传成本”。
简单的可能还好，看几天理解下就捡回来了，那假如这个工具还特别复杂呢？可能重做一个都好过看懂它。
因此，再完美的自动化工具，还是应该定期让人维护，防止它成了没人看得懂的祖传代码。
自动化其实也是一种软件开发
面对自动化，最好还是将它等同于一般的软件开发，要明白开发它的代价只是冰山一角，还需要多重考虑来降低自动化的代价：
- 减少引入非常规因素
- 降低自动化的复杂度
- 定期维护，保证它的资料完整
搬运者的话： 其实感觉是把一个本来“能用就行”的东西当成了基石的后果，一个工具如果好用到人人都要用的地步时，确实应该重构一遍，以更加长远的目光重新设计。当然了，多快好省的大背景下，说啥都不好使……
因此选用开源方案也是个出路，作者那个例子里，以前的java开发经常遇到，mybatis generator也是这个德性，后面大家发展出了“隔离生成代码与业务代码”的模式，再后来是mybatis-plus直接把基础的CURD封装了。
当然开源也有开源的坑，比如文档不是很详细什么的，总之引入新东西时大家一定要三思，别老觉得“小狗狗又能有什么坏心思呢？”万一你引入的是个二哈，等他长大后，呵呵。
