由运营同事提出的一个问题引发了我对开发需要理解需求的思考。为了业务的保密，我把问题简化为：某个用户下的数据能否迁移到另一个用户下。
仅从技术的角度，这个迁移肯定时可以迁移的。如果回答可以，并帮运营同事去做了，看上去也没有什么问题。
回到运营同事提的需求本身，我们看一下，我要迁移一个人所属的数据到另一个人下面，我要找到所有被迁移人的数据，这需要涉及到系统中各个功能产生的用户数据，本身涉及的表就会比较多，操作起来会也就会比较容易出错（可能会漏掉某些功能产生的数据），且通过运营同事的沟通，我认识到这种迁移操作可能会高频出现。
问题分析到这里，好像我们通过脚本就可以解决了，一次找到所有的表，写完脚本，后续的迁移只需要传入两个人的 ID，就可以把数据实现迁移了。
如果仅从当前看，上述想法没有任何问题，如果我们把时间再拉长一些，我们后续业务又开发了一个新的功能且此功能也会产生用户数据结果是怎么样的呢？
那我可能就需要在原来写的脚本里加上这个功能的迁移逻辑，那么这个迁移脚本的维护成本如下图所示：
作为一个开发来讲，这样的模型当然不是我们所希望的，我们都不想给系统添加了一个新功能还需要去维护和修改以前的功能，才能保证系统的平稳运行。
我意识到上述问题后，问了一下运营同事：“为什么会有这种迁移的需求？"，经过和运营同事的更进一步的交流后发现，运营同事要解决的问题其实可以通过其他方式解决，而且这种方式，在系统加入新功能后，不需要改动和维护任何的已开发功能，开发成本如下图所示：
到此即解决了运营同事的问题，也减少了开发的维护成本，可以说是一举两得。
在职业生涯中，我们不乏碰到一些人并不认真去理解需求，甚至会说出：“你直接告诉我怎么做”，这样的话，最中导致的解决可能就是：
- 没有按照需求实现功能
- 实现了需求的功能，但是影响到了其他已有的功能模块
- 实现了需求代码写的复杂、难懂。
往小了说会造成个人开发效率的下降，且 bug 相对较多，往大了说会对团的和公司带了负担。
因此在开发过程中，了解需求是很有必要的。有时候我们会与不同的人讨论问题，有时是运营，有时是产品，有时也可能是老板，但是作为开发，我们除了完成需求交付之外，我们也有责任让他们了解，他们所提方案的成本，以及该方案下会产生哪些潜在的风险。
clean architectrue 里面有一句话非常受启发分享给大家：
The goal of software architecture is to minimize the human resources required to build and maintain the required system
软件架构的目标是用最少的人力成本去构建和维护所需系统
