cr 是一件非常吃力不讨好的事情。首先 review 的人必须要懂你负责的业务，如果不懂业务背景单纯的只看代码的 review 是没有任何意义的，反而会出现负面效果。
代码风格和结构可以通过静态检查来约束。
团队人员多起来后 cr 是一个非常难以维持的一件事情。
我觉得 cr 最佳实践 符合小团队开发模式

你这些是 封装好的组件 还是东拼西凑出来的 html 模板

@gowk 我并没有杠，你说回复也印证了我上面说的 [适合对外的 api 并且功能单一] r

这种只适合对外的 api 并且功能单一
一个 ERP 查询几十个字段你用 get?

@NUT 产品能用 无码平台开发出来的软件。相比都是一些流程简单，没有任何复杂逻辑的东西。

你和商场对接 你给商场钱嘛？

说怎么多 就是想白嫖不花钱

往多了要就对了。 这种产品经理就是垃圾不靠谱

@optional 那你为什么不直接用 KV 用啥关系数据库呢？
你如何判断出一个应用在开发之前是大流量应用呢？

@no1xsyzy 别人说 A 你答 C 。
首先 http code 仅仅是代表传输协议的上的一种状态标识和业务没有关系。
一个业务接口通讯方式不是只有一种，如果用的不是 http 协议没有 http code 如何标识业务状态
有的业务需要根据后端返回的状态码来进行相应的操作。比如说提现场景，申请提现业务方更改了规则导致业务提现失败，需要根据相应的规则进行不同的跳转，这个时候你不用 code 做标识，难道用 msg? 还是说按照您的逻辑来说这个业务的处理方式不合理？
还有和别人进行交流的时候请不要用一些亚文化的词语和梗

这些玩意都不是核心功能，你花钱雇我就行了我给你监督和倒计时。没完成你给我转账 一秒 100 元。你肯定就有效率了

二本或者二本以下没有任何区别

业务不一样 不需要统一

不看好 太小众了，而且后期没什么盈利可言，或者卖假货

还可以标注一下这个人是否回礼。
给张三随礼 300 搬家时张三回礼 300 可以有个简单的明细

你前端代码就是暴露在外的，顶多就是混淆一下。

ui 还有待改进。有一点需要加一个随礼的备注比较好

华强北就能实现你的愿望

你这个 适合做家里灯管的显示状态