卖二手的，有 24 期免息分期吗？

@snappyone 这不是打日志的问题，是你的系统启动慢的问题

打印日志不仅不傻乎乎，还是正确的 debug 方法。很多分布式算法都很讲究时间，哪里能让你停下来的？

你信不信再继续下去，老板把你们两个都开了？
损友啊

@lihongjie0209 产品需求不能相对稳定，那当然是没法做。产品需求本身也是接口文档的前置条件。但题主的情况是“产品需求文档以及设计稿已经具备”，这就和你说的折腾需求不是一回事。

我从来没有表达过“需求不变的情况下，前端因为其他问题需要后端改接口是不能的”这种意思。前端如果有需要，后端可以提供协助，可以加接口，可以加字段。我是说先出接口定义，哪有说过不能改动？

其实吧，如果前后端全程参与产品讨论，定个接口也就几分钟的事情，你需求变化再快，几分钟都拿不出么……

@lihongjie0209 你拆开也可以，合并也可以，你的设计选择你负责就行。现在问题不是接口粒度或者接口怎么设计的问题，是接口应不应该先设计出来，前后端达成共识再开发的问题。

有前置的你就先把前置的设计了啊。你也知道前置的没做，就不提前做。现在楼主的情况是，他把“接口定义”看作是前置任务，结果后端说不给，那楼主只能在前置条件还没达成的时候，就上手做。他只能猜测前置会是怎样的，不能确定，那后面会怎样，你能理解了吧？如果前置的实现有偏差，你说是不是会多了无谓的工作量？

@lihongjie0209 那就塞进去啊，有什么问题？不想写到一起，就用钩子、埋点。可以异步的，就起异步任务。依赖关系复杂，就用依赖注入自动解决。对外的接口哪来什么“单一职责”？你发个短信，运营商做了再多事情，对你来讲，就是“发短信”这个职责。前端也一样，他知道你这个接口会 doX，会发通知，就行了。我没看出你说的这些，用一个接口实现有什么问题。

@lihongjie0209 所谓的“给接口定义”，就是你把 Response 类的定义写出来之后，就给前端看，让他知道这个对象长什么样，就这么简单，后面你再实现。这样前端后端就可以达到题主说的“并行开发”。

@lihongjie0209 你这个接口的逻辑，可以用一句话概括：doX，然后根据条件判断是否需要发通知。一句话能概括，那当然能一个接口实现，加个条件判断而已啊。前端有的用户想发短信，有的不想发，你也拆两种接口？有的用户想发短信，有的用户想发邮件，你也拆两种接口？这是一个功能，不是两个功能。

我觉得你根本就没有理解，我说的是接口的参数和返回，从来没有说“数据库的结构”，接口字段和数据库字段，不是必须对应的。代码生成有什么用？你前端用了 gender，结果后端接口用了 sex，代码生成怎么直到这两个字段是对应的？还不是要一个个对。

@lihongjie0209 “套一个 DTO 的事情”，说得轻松，假如有上百种类型，每个类型平均 10 个字段好了，那就是上千个，一个个手工适配？本来不需要干这种活的，就因为后端不肯先约定接口，就要做无谓的工作。

@lihongjie0209 谁和你说要这样拆了？事务当然是一个接口啊。

你钱多或者接口少，当然可以一种终端一套接口。后端完全没有文档的不也有么。

别作死，系统 libc 不要随便升

用一个隔离的环境跑 tensorflow 吧

8G*2 或者 16G*2，成对最好

@AngryMagikarp 我希望你能理解“能写出来”和“下一秒就应该出”的区别。

@AngryMagikarp “大部分简单的接口后端也能在前端需要之前就给出”，这不就是楼主想要的吗？？问题就在于楼主连这个都拿不到，完全等后端开发完接口了，才有！

@ety001 就事论事，连设计稿都出了的情况下，如果谁还说需求不明确，那这个团队的开发能力，绝对有大问题。

@AngryMagikarp 我可没有说完全不顾，像一个页面需要三个接口的数据，那一起发过来，一起返回，甚至做更复杂一些的处理，都不是什么大问题。一次请求对应多个接口调用，这个可以实现成通用的机制。

内部调用和外部调用的方式可以有不同，但基本的参数和返回字段，难不成还用不同的？总得提前决定吧，后端之间也等实现了，才来改字段名或者加适配层？

接口可以有通用的，就是一堆 CRUD 的，可以有非通用的，例如只给某些页面或者终端用的。通用的，在初期就给出文档，不难吧？非通用的，可以在后面根据需求增加。至于前端还是后端写，需不需要讨论，这些都不是重点。楼主说的是后端在“实现”了接口之后才给文档，你真的觉得这样合适？

要加个格式化的时间字段，也不是大问题。注意是“加”，不是“改”，后端加了，你想用就用不想用就不用，不影响协作。

这一套流程不是我发明的，这里其他人一样有使用同样流程的。我们用得轻松愉快，不然楼主也不会发帖了对吧？