开发业务层的时候是先写接口后实现还是先实现后提取接口

Question

1.是否有必要弄个业务接口
如果弄的话,添加一个或删除一个方法要到两个地方改
2.在开发前项目所能用到的方法能否在事前都预料到

Answer 1

兄弟我站在一个开发人员的角度来回答你的问题。永远不要相信产品的需求业务层和PRD规则等定型了，即便是给你说的再好听也别相信，时刻保持一颗把代码写的够通用够灵活记住千万不要写死，接口更是要如此做的足够灵活给自己留条后路。

• 为了减少自己后期的麻烦，我强烈建议你去搞个业务接口，哪怕产品需求说的再死，如果时间充足你自己也私下里弄个以备不时之需

• 一般情况下只要你把业务需求和对应产品提供给你的规则分析明白之后，对应的方法；对应的接口；对应参数；对应的接口文档等等都可以定义好

总之时刻提醒自己多做一点。希望对你有帮助

Answer 2

一定是先写接口：
1、接口是相关子系统（如网站前后端、后端不同业务系统）之间交互的约定，应该提前制定；别人的设计有可能依赖你的接口；
2、整理接口本身是你梳理设计的一个过程，在TDD（测试驱动开发）的实践中，甚至会先针对这些接口写测试用例，然后在写实现；这些暴露出去的接口应该是精炼的，绝对不是后期联调的时候别人临时要一个，你就开放出一个；
3、在比较规范的项目运作中，接口要求文档化，并且后续对接口的增、删、改都要记录下来并升级接口文档的版本；
4、接口中会所涉及的一些类似错误提示、返回码等都应该在整个项目统一，所以要提前规范；
5、题主顾虑的先期考虑不全肯定是存在的，但要尽可能避免，出现过多的话通常是需求或设计没想清楚，这样往下走，我的经验是越急越慢；

Answer 3

开发一般采用的分层设计的思想。根据产品需求设计接口；根据接口，设计对应的实现；后期后端重构时，不用改接口，只需要改实现。

1. 如果产品需求确定了，后端架构后期有可能会调整，那有必要弄个业务接口。否则的话就没有必要了。

2. 需求变动的话，需要增减接口。这个需要技术Leader来根据对产品的理解和经验来决定接口如何设计。

Answer 4

肯定是先写接口后实现啊