网上截取一段代码
addAppUser接口详细实现代码
分析接口做了什么
这么多功能，到底哪些才是addAppUser接口应该实际上要做的呢？也就是说接口设计的准则到底是什么呢？
接口本质是什么
• 接口是需求的体现，需求会经常变化的，简单点说，用户需求经常会变动，前后端协调有协议约定和沟通交互成本，系统之间交互也有协议和约定• 接口是变化点的抽象表示，对外隐藏了实现的过程，需求经常变动，实现越复杂，越难以应对，经常出现的情况是，产品和开发思维冲突，产品经常说的是：这么一个简单的更改怎么就这么为难？• 越离散越难以应对变化，越抽象越容易应对变化，也就是常说的开闭原则，单一职责（keep it simple,stupid），高内聚低耦合• ...... 归纳来说就是：接口=需求+协议+变化点
• 输入参数：用户对象信息• 输出值：用户信息
第一步：输入信息都找齐了吗？
用户名密码，普通的帐号注册
2.手机号还要注册验证
3.邮箱要注册验证4.第三方登录要支持
再看看用户类关键字段信息
能满足上面的4点吗？明显是不行的
第二步：输出是否足够？
这个简单，不多描述，返回能满足上面4点交互需要的信息即可
接口功能
1 创建新用户需要和更新用户耦合一起，违背单一职责，显然不需要，拆成二个接口，新用户还需要角色查询吗？肯定不用了，本来就没有角色值
2 参数校验，应该是在service层来做吗？回到以终为始
1.用户在创建信息时，如果输入错误，前端应该就立即给提示反馈对不对，而不是等用户点击提交时通过接口（尽量早的反馈信息给用户）
一连串的if做了同一件事，就是校验用户名密码是否符合约定的注册规则。
1和校验用户名密码的功能完全可以合并成一个，变成
手机号和第三方注册还需要密码加密吗？显然不需要。那应该把变化点抽象出来，用一个接口或者抽象类来封装变化点，用策略模式实现不同用户注册的方式，下面以接口举例
再回到功能点，第3点对象赋值应该在不同的实现用户创建的方法中，于是变成下面这样了
再看功能点1，用户名密码，手机号，第三方登录的参数校验完全不一样，如手机号和用户名是一样的吗，肯定不是 ，第三方登录又完全不同，变化点又来了，继续接口或者抽象类来封装变化点
总结
最后核心功能点变成：参数校验+创建用户
单一职责本质=拆+抽象（应对变化） 再来考虑问题：实际开发中，资源都是有限的，情况是复杂的，该如何有效能的去拆解。拆到每个方法只有一行代码？极容易形成过度设计，最终走火入魔。
我们再回过头从源头上考虑问题，coding是降本增效，要降本增效就会有时间维度和作用域，让单一职责如虎添翼：
适度超前：根据实际情况，适度满足半年（时间自己定，不低于一个月，但最好不要超过半年）的预估需求，比如新用户注册途径半年内只有用户名密码，手机号，微信号，那就按此设计。
拔高通用，团队赋能：老王写了一个校验手机号的方法，老张也写了......同样的的事重复的做，那就应该抽出来做成公共模块，减少重复浪费本身就是效率的提升，积少成多，而且能大大减少BUG量。在不断拆解的过程中，怎么把自己做的东西抽象拔高成一个通用性和独创性的东西，是大多数开发人员极度缺乏的，点的思维需要提升到线，面，体。
单一职责=拆+抽象+适度超前+拔高通用
技术手段归纳起来就二步：一步一步来+持续不断的改进
绕了一大圈子，也只是正确的做事，那么为何不一开始就做正确的事呢？一开始就把核心需要弄清楚呢？一开始就把需求迅速反馈呢？
所以，测试tdd个人理解就是：
帮你正确的抓住需求点，并及时沟通反馈调整（先实现后期调整所花的时间就多了，变化后更如此）。
以终为始，始终站在用户角度看问题。
设计先行，而不是实现（一上来就先实现就不是正确的做事）。
适度超前+拔高通用，让单一职责如虎添翼。
tdd重要吗？可能重要，但肯定不是最重要的
重要的是：正确的做事+一步一步来+持续不断的优化。
本文分享自微信公众号 - 川聊架构（gh_44ec4115d261）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。