@siteshen 哈哈哈，以前我也用 swagger, 不过现在回不去了

@tairan2006 布吉岛，不过 YApi 还是很好用的

1.统一团队代码风格, 建议基于 google 风格提供的 idea 配置文件定制(4 空格缩进, 120 行宽)
2.在项目没有开发分支是全局格式化掉
这样以后怎么格式化大家都一样了

自定义注解，动态修改注入的 url 地址，可参考: https://github.com/lkqm/spring-api-versioning/blob/main/src/main/java/com/github/lkqm/spring/api/version/VersionedRequestMappingHandlerMapping.java

可搭建独立的文件预览服务，使用: https://github.com/kekingcn/kkFileView

fix bug 流程 new features 流程 发布流程是怎么样？
A: github 工作流，新分支开发修复测试，合并主分支 tag 上线，两个邮件: 提测, 上线, 运维使用 docker 和 ci

对于前期的架构和人员不足或者能力不足该怎么做平衡？
A: 如果让一个应届毕业生去搭建新项目，通常不会好哪儿去？但是如果有标准的项目模板、固定的代码生成器、编码规范(数据库设计、接口设计)、一些公司使用技术的最佳实践文档、一些基础设施和服务(city, sonar, 短信服务, sso 登录等)、适当有经验的员工指点

Q: 现实当中为了需求是否要牺牲一些基础架设？
A: 业务第一，架构第二

gitlab commit 强制规范
A: 我们订了一套规范包括其中包括这一项，大家都应该按着这个来，至于强制主要靠大家自觉和定期检查下

git commit before 强制跑 soner
A: 前提要定义好一套合理相对宽松的规则集，太严成本好，太松又没有意义

测试一个功能一个服务的实例和所有基础服务
A: 基础服务可以做哈单元测试或接口自动化测试，后期收益很大

强制所有模块拆分成为一个，一个 git 远程仓库
A: 前期没必要管理麻烦，后期团队成员增多可考虑

通过 ELK 采集日志集中分析和查看
A: 集中日志这个很有必要，当然不一定是 ELK, 特别是公司多个业务线系统，或者一个系统部署了超过 2 个实例

对新表上线必须模拟日增数据
A: 没做过，感觉中小系统必要性不大

对服务的监控和熔断，限流
A: 发展到感觉需要做的时候再做，线上系统服务监控很有必要

git push master 必须通过所有回归测试
A: 还是看该的什么，小改动没必要吧，另外为什么要直接 push master 了？

所有服务必须有基本的 readme.md 介绍
A: 成本低很有必要，最近将一个单体应用按技术分层，改为业务模块划分，在 readme 中维护业务模块划分说明，这样后续不熟悉新的开发者新代码也知道放哪个模块

所有的服务必须有版本发布管理
A: 版本发布管理是？


所有的部署必须通过 git 钩子自动化部署的
A: 公司运维是 gitlab 上手动点 pipline 部署的，当然自动部署也可以

模块的更新必须共同开发的同学一起 code view
A: 如果整个团队不十分忙，code review 很有必要，对新加入成员前期 code review 也很有必要


模块的调用必须通过 feign 或者 MQ 来完成代码的解耦
A: 既然服务独立了肯定应该这样

我猜是因为 golang

https://github.com/pingfangushi/screw

- 支持自定义导出模板
- 支持多种类型数据库
- 支持编程方式、maven 插件、idea 插件多种方式生成

github flow 下 codereview 是先提 PR, 还是先测试？
1.先测试后再提 PR, 这时候审查代码会变更有风险
2.先 PR 审查, 但是未测试的代码不小心被合并了的风险

提前建立，创建索性时，会自动创建集合吧

YapiIdeaUploadPlugin IDEA 插件基于 JavaDoc 注释生成文档，上传到 yapi 中.

@qile1 mssql 使用驱动包 pymssql，如果包本身时间处理有问题就没发处理了，dbtool 主要简化 dbapi2.0, 屏蔽底层驱动包差异

两个接口，接口层应该专用，对数据安全、权限、后续修改都方便，通常情况下 C 端和管理端是两个应用 xx-admin-api, xx-web-api

@lihongming 不赞成楼主观点，列表页或者导出上万条数据，假设单个 10ms 那么顺序调用总 10s 吧，如果并发执行那不是更复杂了吗，还不如批量组装。总的来说能简单的掉用一次，没有必要调用多次

第二种方式批量获取用户信息，第一种和循环里执行 sql 没有区别应当禁止

用户名模糊查询问题, 用户名变动少可直接冗余，考虑到匹配用户相当多时，不建议先查模糊用户服务的到大量用户 id 。

如果后续订单查询中增加了大量用户相关的查询条件，可考虑使用 es 等数据聚合仓库，冗余了多个服务的数据

如题只能通过数据冗余，满足多个查询键的需求。建议按照楼上老哥说的按照时间纬度分表，或者不分表做个历史归档表，不过需要从业务上面做一定调整