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

[abcbuzhiming]

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

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

[chenguoyu]

@yoke123 目前我和我 leader 的关系就是第二种，全靠自己下班回去自学。

[wity_lv]

从流程方面入手。建议了解一下 Agile。

TL;DR 实践：

* 每天早上固定实践站会，每个人讲一下昨天的工作内容，以及今天即将的工作的内容，如果有问题当场提出。（切记讨论，以快速 catchup 为主。10 分钟足以）。
* 每天下班前 1 小时进行 Code Diff。每个人过一下今天写的代码。
宗旨：缩短反馈时间，快速定位和修复问题。

可视化工作内容：
用 trello.com 之类的 boards 将工作内容可视化出来。最简单的方式建立 5 列。
TODO, Doing, QA, Ready to Release, Released.


一段时间做回顾会议，比如每次 Relase，大家一次来叫好 /吐槽。整理切实可行的 action 让团队自我垓心。

可视化反馈最好了可以解决大部分问题。 至于能力培养，属于另一个话题，短期不能解决楼主碰到的问题。

[chinvo]

除了敏捷开发（ Agile ），做修改都必须走分支，新代码必须覆盖单元测试，review、ci 过了才能合并

如果是 Git 版本库，善用 Git Flow 可以做到上面的大部分要求

[zenxds]

对新人给一些技术题目，code review，同时团队做技术分享，另外代码风格检查、Lint 等自动化的事情也要做上防止新人犯一些低级错误。但是说实话，作为 leader 只能尽量提供学习成长的环境，在新人有困惑的时候给他们指点一下方向，人的成长终究是自己的事情。

[curdboy]

code review + 一些常见实现的 best practice

[qkline]

降低接口耦合度才是好办法，否则永远有人会犯错，永远有人需要培训，形成树之后，就会最大的保证开发进度以及促进持续集成。

[wangbenjun5]

总结一下大家的发言：
1.采用 git flow 工作流，新功能开发，bug 修改走新分支，leader 负责 review 代码和合并分支
2.项目架构设计方面不好说，但是良好的设计确实可以解耦，从设计上解决修改 A 接口影响 B 接口的问题，这个很难了
3.写测试代码，单元测试或者功能测试，甚至采用 CI （持续集成）这种方式。但是 TDD 这种模式也很难走，耗时不说，对开发人员要求也更好
4.如果真的是开发人员技术问题，那就要谈话了，相互学习，共同成长！

[zj299792458]

建立 Test Case 脚本，跑通才能发布……提高别人的技术水平是老师干的事，提高项目的质量才是 team leader 目的……

[flashback313]

增强约束：
1、代码规范
2、单元测试
3、code review
4、常见问题总结分享
5、恰当的惩罚

[scofieldpeng]

@flashback313 好奇恰当的惩罚是什么？怎么把握“恰当”这个界限

[takato]

根本问题不在“提高”，而是组长和组员认为的高水平是什么？是否一致？

[goldkeyber]

换人

[night98]

这种问题的根本是项目文档不全吧，开发写接口的时候不知道这个数据会复写另外的数据造成的吧，建议添加代码审查流程以及编写完整的架构流程，这样开发过程中可以明确知道当前修改会对其他接口的哪些数据造成影响，避免问题的出现

[iConnect]

1 首先要承认源头上的区别：人的能力是有区别的。国内外大厂挑那些竞赛高手、高学历为的就是找“体质”强的选手，从招聘的时候就抓。
2 能力和岗位匹配：能力（一般是不够）不足硬上，岗位要求高，自然扛不住。
3 预期和工作量相符：一周干完的活，硬要 3 天上线，自然漏洞多。
4 薪资和水平相当：高薪水可以激发员工超水平发挥。
5 最后一个才是培养员工潜力，前提是员工基础能力很强，只是暂时对业务和工具应用不熟练而已，这才有提升和培养的必要，真正优秀的员工根本不用培养，少操这个心。

[notreami]

能力不行的开除，规则制度整起来，指标，绩效，考核黑底白字写清楚。自然所有人能力都上来了。

[SmiteChow]

ut+codereview+presentation

[xy90321]

品质的来源不是开发者的高水平，根本上还是良好且充分的测试
UT 不能暴露的问题 IT 也要能挑出来，否则 commit 以后肯定是一塌糊涂
成本追加是肯定会发生的，看怎么取舍了

[qiumaoyuan]

如果这问题还需要我了考虑，那就直接换人，然后把好招聘关呀。

为啥都觉得成年人是容易被你改变的？直接招一个本来就是好的不就完了。

[ToT]

代码进入 production 之前 应该有 QA env 吧？

[msg7086]

如果我是 Leader，我做的项目没有集成测试覆盖，没有持续集成部署，没有组员间的 Peer Review 或者成立 Review 小组专门审代码，我觉得我这个 Leader 的技术水平有待提高。