@yuandj 谢谢 合并冲突那个确实用不习惯 凑合着用 说不定习惯了就好了

这个很强

@echoechoin 长撒样 有图吗

颜值很高 精致的不像开源软件 之前用 medis 很多开源软件刚开始都做的很好 慢慢因为没有盈利就没有更新下去了 希望作者能尽快找到盈利的模式， 可以考虑苹果版本上架付费版本合适的价格，然后海外推广，毕竟有收入才能持续更新。

服务拆分后各个服务之间通过 http 接口调用，那么第一个问题考虑的是要不要提供客户端?
第一种: 服务分为多个 maven 模块, 例如: user-api, user-provider, 优点代码复用, 缺点就是版本兼容，适合大量接口调用.
第二种: 调用方写代码调用，优点是按需写、灵活，缺点就是代码重复，适合少量接口调用.
第三种: 单独写一个 sdk 项目，优点是复用，缺点单独维护，也可根据 openapi 文档自动生成.

回到你的问题，如果使用第一种方式：
1. API 包种每个接口返回 VO/DTO, 不要直接返回数据库实体类，实体放在实现模块中，实体转换用 mapstract 即可。
2. Feign 中每个接口建议入参和返回都包装一个实体: UserAddReq, UserAddResp 以后便于扩展而不影响调用方，部分原子接口可不用包装比如根据 id 获取用户信息: Result<UserDTO> getUserById(@PathVariable("id") Long id);
3.因为我们是 bff 模式，原子服务的 service 层尽量返回实体，控制层包装转化为 DTO/VO;
4.目前我们是返回的 Result<?>, 然后 Result 里有个 tryThrow()方法，由调用方控制，灵活性更大，也可以用 Decoder 方式;

另外一个小地方命名冲突: 一般会在 bff 服务中请求响应都叫 XXxReqVO, XxxRespVO, 而在原子服务叫: XxxReq, XxxResp 。

我们实际中采用第一种和第二种混合: bff 服务调底层服务用第一种，相对独立或外部的服务调用使用第二种。

根据个人遇到的情况来看，大致是项目没有约定规范、不同开发按照自己的命名和风格随意、新人对项目不熟悉、偷懒对第三方返回数据没有转换，说白了还是技术水平问题，但是归根结底还是管理问题。我的建议了就是提出问题和后端人员，讲道理方式沟通。

领克 03 中配，15.几应该能拿下

@Emptyh Zara, 优衣库, Gap ，美邦 风格都比较好看，相对 Zara 风格更潮一点，可以都试试看

@Goooooos plantuml 好像没这么好看

@LeegoYih 请问下用的什么画图工具

才从 lastpass 切换到 google chrome 的密码管理器,如果真是如主题所说的那样，又得切回去了

@bitmin smart-doc maven 插件 自己扩展下上传到 yapi 可以实现，但是有个问题，多分支开发怎么弄，yapi 本身的文档管理功能没有多分支，多版本的概念

如果是用的 spring ，可以用这个 Idea 插件，从标准 Java doc 生成代码: https://github.com/jetplugins/yapix

在公司内部写了一个 IDEA 插件，定义了代码风格文件，安装插件后会自动设置代码风格，并且在代码提交时候，每次默认勾选 `Code format` `Optimize import`,

梳理一份常见字段命名(业务和非业务)，数据库评审阶段可以卡

坚持使用番茄计时工具，强制锁屏休息，保护眼睛。上次会议 Code Review 大家愣是等了 5 分钟

一年过去了，楼主单元测试有值得方向的经验吗

犹豫就用自己喜欢的那个，自从用了 mongo 就喜欢用枚举，数据库映射就是字符串，可读性高

感谢各位最后用了 Stretchly ，和 JustFocus 功能几乎一样