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

[abcbuzhiming]

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

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

[msg7086]

这种和能力没有太大关系的问题，为什么要去追究组员的技术水平？

让一个资深飞行员去开飞机，一个人自己飞 10 年，不知道要出多少事故死多少回了。
Checklist 是干什么的？ CRM 是干什么的？就是解决「人」这种一定会犯错误的生物会犯错误的问题。
一个人会犯错误，但是两三个人互相检查就会大幅减少犯错误的可能，再加上集几百几千人智慧做出的 Checklist，才能把出事故的可能降到最低。

如果一个接口改坏了就是组员水平低，那怕不是全球就没几个水平过得去的程序员了。Linux 和 Windows 内核还经常炸呢，软件包还没事就要修 Bug 呢，微软和 Linux 基金会那几万个工程师那么多硕士博士都是水平低了咯。

[jisi724]

1. 一套成熟的 CI 做检查可以有效的避免很多浅显的代码问题，甚至我会在 CI 里用 ESlint 去保证大家的代码风格都要一样。。

2. 楼上说的 Git Flow，限定初级程序员只能提交代码 然后 ping 你或者其他负责人去 merge，你可以简单扫一眼

3. 如果还有问题就每周抽一个小时 大家坐一起看几个典型的出错案例 一起讨论 老司机带带新手 慢慢就好了。。。 我们 dev team 到现在还有一周一小时的组会 不过已经没有什么 bug 要讨论了 都是聊一聊哪些新技术可以试用什么的

[xiaol825]

以前我觉得出现这种问题首先可能是因为组员不熟悉其他模块的逻辑，但是在和一些印度大哥共事以后我觉得，确实有的开发人员很让人头大。短时间内想让组员大幅提高技术水平，最直接的就是看组里其他大牛的代码，现学现用。

其他方面，加强测试是必须的了。

[Semloh]

开发周期允许的话可以从代码 review 开始做。2 人以上 review 才能 merge （平时不行的由 lead 重点关注），整个组的意识可以慢慢拉平。
成本允许的话不行的直接换。

[chuxiwen]

( 简单说下我的背景，6 年工作经验，其中 3 年是 team lead，我现在负责两个团队，一个是和我在一个地方的 6 人团队，一个是在印度的 5 人外包团队）

说下我们的做法吧

0，TDD

1，git flow + travis ci

CI 包括 unite test

PR 的时候，如果 CI 报错，直接 reject，连 code review 都不会做。

Test coverage 在 CI 里检查，如果低于 85% 也会直接 fail。

2，automated api test

3，automated integration test

4, staging

5，code review，全队一起做

6，pair programming，如果有谁开发的时候问题很多，或者 code review 发现问题很多，我们会和那个人 pair

7， 发现的 bug 会首先被写成 automated test，之后从 1 开始


最后我要说的是，如果出现问题，不是某个人的责任或者错误，而是整个团队的责任和错误

[enlau0912]

1.撰寫規範書，包含編碼要求、產品邏輯、模塊邏輯、常見問題。
2.強迫新人閱讀過去產品 code，起碼讀個三禮拜。
3.automated integration test
4.code review 至少三分之一組員通過，empower 最挑剔的人做 code review 總把關（當然得減輕他平常進度上的負擔)
5.通過的功能一定要寫 documents
6.不要浪費時間開會、報告進度，最多一週兩次即可。
7.實在跟不上要求換人。你又不是他老爸。

[xeneizes]

没水平的直接辞退

[wangcansun]

这个描述不应该是基本的开闭原则么？

[jasperjia]

leader 决定了一个团队水平的 80%

[linkto404]

规范的流程应该能解决部分问题

[afeicool]

那么问题来了，国内有几家公司会写单元测试、功能测试、集成测试的？！

[z1154505909]

额,,,,这种吧,不同层次的丢不同项目,

[tftk]

从招人开始

[gdky005]

开分享会，CI 控制，提取基础工具类，定期组织分享，代码 review。质量嗖嗖嗖

[myAngel]

集成测试 》功能测试》单元测试
单元测试好做但是最不好推进
集成测试最好推进但最不好做，做好了是一本万利

[Khlieb]

组织集中培训或者建立技术资料库

[qinyusen]

我说一下我的观点：

1 招人， 吧台原理，每次进入的人，至少要高于同等职位的人的一半以上的人的水平才能推荐录用，如果不是核心开发人员，那么要高于整个 team 里一半的人的水平，否则再缺人力也不能让他进来，宁可可活儿干不完大家加班，然后帮大家申请加班福利。。 --我记得亚马逊是这么做的。还有一个东西叫做 2 pizza team，感兴趣也可以查查

但是这个需要你能顶住你领导和 HR 的压力。

2.强制分享每个人擅长的东西，如果没有，定下课题，每 1-2 周做 tech share，记住，这个计划，刚开始的时候请让校招的新人开始，用技术分享作为技术团队的破冰，没有更好的了。 同时，这也是个鲶鱼效应，校招的新人的学习能力往往很夸张，尤其你以（除了经验之外）的吧台原理招来的校招新人，往往学习能力爆棚，会让所有的老人非常有危机感。 整个 team 的学习能力也能保持在一个比较高的水平。

3. 工作之外，任何的优化和重构和建议， 合理的有效的要给与反馈， 比如，review 代码出来的 bug 总数， 被 review 的可以不惩罚，但是 review 出来的周、月度最多 bug 的人，要给与适当奖励， 给个 300 块钱的京东购物卡或者走公司采购买个 300 块钱以内的东西，额度可以积攒这样，。，但是要记住，下一周此人要进入 cool down， 也就是冷却时间，是不能参与评比的。当然 review 工作也不要给他太多了。。。

4。上面各位大佬说的很多了，各种标准的研发流程性的保证，具体看个什么敏捷开发之类的，TDD 之类的书。

1-3 点是我个人觉得绝大多数 leader 在最开始不太清楚的， 其中 1 是一个群体上升的招聘策略，2 是群体心理学的鲶鱼效应，3 是普通的心理学的额外的付支出要给予额外的奖励，以鼓励超预期行为。 然后大家确认有超预期回报的短线激励，那么就会一定程度的追逐这点。 另外如果每周大家团队 bug 少于一定量，这 300 块钱拿出来大家吃顿披萨，开个站会提升下幸福感。


就这些， 至于技术上。。。既然你是技术专家我就不多说了。

[jelinet]

定制代码规范，严格执行；
模块责任制，职责单一；
code review，git 一套用起来，pr 一定是相关人员一起审核过才可以；

[lscho]

说句难听话，花多少钱招的什么水平的人，老板心里没点 B 数吗？改 A 接口能把 B 接口改坏，项目架构什么样，leader 心里没点 B 数吗？说什么 code review，模块化，CI，都没用。。先把项目重构了，这些才有用。。烂的一坨屎一样的代码，再怎么搞也只能是越来越烂。特别是多人开发的时候。想要组内水平全部一致根本不可能啊。每个人擅长的点，思路，开发风格都不一样。。leader 就需要先把项目结构规范，代码开发标准规范，提交及审核规范。然后配上 code review，单元测试，就没问题了。。

[chenqh]

@chuxiwen 大佬数据库的测试怎么写