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

[abcbuzhiming]

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

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

[Charkey]

核心业务必须有相关测试的代码咯，CI 流程用起来，测试跑不过了就无法提交了。
我这就针对文中的具体问题给个想法。

[hcymk2]

sonar 配合插件可以找到些简单的问题。
但是找到了不改，或者今天改了明天有另外的地方一样的问题.......
当然你可以上 ci 那一套自动化。

[barbery]

没有代码 review 吗？“改 A 接口把 B 接口的数据破坏而不自知的行为”这些错误就应该在 review 阶段提出来让其改正，培训那些我觉得没多大效果，做开发的都应该明白，真正的修炼靠个人，那些培训的知识网上都能找到和学习，如果他们都不愿意自己去学习，你觉得强制培训就有效果？

[parkcg]

TDD，回归测试，部署 CI

[Akiyu]

LZ 这样的 TL 不多见了啊
很多都是选择了最直接的方法，换人

[Jeremial]

出现 1 次, 指导改进
出现 2 次, 谈话
出现 3 次, 全组通报
出现 4 次, 换人

[gamexg]

@Charkey #1 +1
>改 A 接口把 B 接口的数据破坏而不自知的行为。

我前几天完成新需求时就碰到过这种问题，由于有测试覆盖，接口 B 测试直接失败，问题被提前发现。
这不是水平高就能够解决的，某个函数对外提供的是 interface，但是接口 B 由于特殊原因却依赖于 interface 的底层实现，实现改了照成接口 B 失败。

[lorcanluo]

code review + 持续集成跑单元测试+绩效算 bug 量 哈哈哈~~

[abcbuzhiming]

@hcymk2
@Charkey
你们说的 CI 流程是指的什么？

[nullcoder]

把你解决问题的方法教给他们，而不是帮他们解决问题

[lizz666]

对不起,我司老板只想开发个模板，然后招应届生进来传入数据页面自动生成。
想涨工资？走吧，每年应届生这么多，不缺你一个。
所以也就不存在提高组员技术这一说了，巴不得你技术菜没实力没资本谈条件。
所以，更多靠个人了。

[Charkey]

@abcbuzhiming CI 就是持续集成，https://baike.baidu.com/item/%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90

[ioth]

水平提高关你什么事？
开发做得好不好是管理问题，不是能力问题。

[q397064399]

管理复杂度，，每个人每次只接手一小块，，良好的代码隔离

[monsoon]

<del>让他们都玩玩像你头像里那样人设的 galgame，提升下自我如何</del>
感觉楼主这个问题比较难……

[misaka19000]

楼主头像亮瞎我的狗眼

[ke1e]

每个人单独负责自己的模块，或者说是服务。这也是微服务就行的原因。隔离性强

[ke1e]

@ke1e 流行

[HuHui]

及时 review，真的能解决问题

[UnknownR]

开除，换人

[thundernet8]

前端怎么破 迭代快 UI 代码多 不像后端 API 强逻辑性

[sorra]

请去掉“如果”，免空谈

[luoyou1014]

@ioth 部门领导没有责任带领整个部门的水平上升吗？

[chenqh]

你们都有单元测试？

[leslie000666]

素质这东西，难。即使制定了，执行还是一个问题。

[chnhyg]

和我之前带团队的时候一样，耐心指导都不听，真的是心力交瘁。无奈。~

[wspsxing]

CI + Review

[wekw]

“改 A 接口把 B 接口的数据破坏” 这是架构问题，说明你们系统的代码治理有问题。

[TheBestSivir]

同意楼上的说法，重新做服务拆分和分层，目前的情况是在代码的组织和业务的架构上存在可改进的地方。组员的代码能力目前看只是一个方面。

[vincenttone]

同样觉得是管理的问题

[jason19659]

代码规范，同一个标准，严格执行

[archknight]

进来看了楼主的头像亮瞎了，闪 /

[torment5524]

单纯针对团队里面有经常出问题的新手：
审核代码版本变更；
针对频繁改动的接口和功能做好 testcase，或者针对经常出问题的同事负责的部分写 testcase，每次修改就跑；
周会啥的统一对近期问题进行交流；
把经常改代码出问题的同事调到测试部门一段时间，培养下测试思路和意识（他的工作最后有经验的人给再过一遍）；
组队模式，一个技术好的和一个差的互相检查代码，或者是共同完成任务。将提高新人的工作交给团队里技术好的人。

如果是业务理解不到位，就去学习业务。
如果是编码基础不行，或者是就没有编程思维的，这种是真没办法，只能找 hr 调整分工或者组织培训。。

[winglight2016]

虽然技术水平提高了可以解决很多问题，但是也很容易让人跳槽啊，楼主三思

——理想做法是：告诉组员严禁事项和鼓励事项，不要告诉他们为什么，这样才是长久之计，楼主看在我这么卖力的份上，发一下头像番号啊

[shakoon]

找几个技术好的人，成立代码评审小组，大版本上线前需要通过他们的评审

[abcbuzhiming]

@winglight2016 这不是什么番，这是伊里野的天空的同人图，你用百度识图就能发现原版

[yoke123]

你带领组员一起成长 或者 撒手不管自生自灭

1. 带领组员一起成长 你提升了 他们也提升了 虽然最后免不了 跳槽 跑路
但双方都有收获 关系好了没准以后还会拉你一把

2. 自生自灭 双方零成长 赶紧扔下这烂摊子跑路吧
傻逼才去帮他们提升呢 费力不讨好的 人活着就是为了自己和家人

[yjxjn]

@ioth 你这话语也是服，block 了

[wampyl]

好 TL，我们的根本不管

[repus911]

你这个问题上单元测试和持续集成就可以了
组员的素质...绩效和招聘...督促个人提升要做的事情就多了去了，而且还是长期的事情（当然也是必须的，不然你招的人的水平会被慢慢拖下来）

[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 的技术水平有待提高。

[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 大佬数据库的测试怎么写

[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