请问各位，如果你是 leader，如何提高组员的技术水平？

[abcbuzhiming]

我现在受困于这个问题，组员的素质参差不齐，导致代码质量不稳定，经常一个接口，昨天测试还是好的，今天就莫名其妙的改坏了，前端抱怨颇多，查找分析后得到的结论是后端人员的水平不够，经常出现捡起芝麻丢掉西瓜，改 A 接口把 B 接口的数据破坏而不自知的行为。这个问题，除了用测试堵，我看网上的说法，需要建立一套培训，审核机制，以一定的标准去审计代码，定期开会培训告知大家某些写法是不应该出现的，以提高大家的编码能力等等等

但是问题是，该使用什么样的标准，或者工具去建立这样的机制，或者说这样的体系该如何具体操作呢，我一点头绪都没有，我自己给自己定位的是技术专家，解决问题还行，但是要带领一群人提高他们的综合水平，我真不擅长，恳请有经验的人赐教

[ioioioioioioi]

团队其他人写代码都在分支上，由我 diff 检阅修改后，再合并，可以减少很多 bug

[tabris17]

如果是 leader 应该提升的不是团队成员的技术水平，而是开发流程的规范，做到任何人都是可替代的。

提升成员技术水平干嘛？等人家学会了跳槽吗？

[suyuanhxx]

你该使用微服务了，微服务从上层代码到底层数据库表结构，都隔离，就不会出现这种问题了，数据的修改只在一个服务中，相似业务逻辑只在一个服务中，一个人负责一个微服务。就不会出现该问题了。
不是组员代码技术问题，是架构问题。我深有体会，从上家公司的架构混乱，总是出现类似问题，到现在微服务，没出现过这种问题

[zzugyl]

小组多去喝几次酒，感觉这样的问题就没了。缺少融洽的沟通。不觉得是技术问题。

[ChefIsAwesome]

人家也不是 sb，自己写的代码写完了肯定会测下，当时他写的 a 接口肯定也是没毛病的。至于为什么 b 会出问题，你们一群人还要找半天才能找到，能指望他一个人写的时候就注意到？换句话来讲，这么个紧耦合的系统，什么样的测试写出来你们能放心？

[hcymk2]

服务化只是把代码的臭味隔离起来， 有问题的代码还是会出问题的。

[jlkm2010]

多写测试，或者强制写测试，单元测试，集成测试，配合 ci 每次提交代码都跑一边测试，不通过不给合并
会有很大改善

[NUT]

那我问 po 主几个问题
1.你是否有足够大的决策权，绩效，人员去留？
2.你是否对团队每个成员有足够了解，他们喜欢、不喜欢的事情，他们的优点和缺点？
3.大家对这个 team 有认同感？
4.是否有搅屎棍？
5.他们中间是否有那种想拼的 鲶鱼？
6.你是否制定了开发流程？
7.你是否曾经过 1 对 1 沟通？

[chuxiwen]

@chenqh 这个要看具体情况，我们是和上层封装一起测。

打个简单的比方，rails 里对 db 的测试就在对 model 的测试的时候完成了

[TommyLemon]

用 APIJSON 吧， [自动化 API] 和 [自动化接口回归测试] 能很好地解决 开发效率 和 接口质量 问题：
APIJSON 能自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
github.com/TommyLemon/APIJSON