如何在团队建设工程师文化?阿里资深技术专家这么做

作者 : 开心源码 本文共4235个字,预计阅读时间需要11分钟 发布时间: 2022-05-11 共59人阅读

摘要: 人人都在说工程师文化,90%的同学们向往工程师文化,然而95%的同学们觉得自己的部门没有工程师文化。但关于工程师文化,事实告诉我们两件事: 事实1是:我们定义工程师文化的标准不一样。这就跟美女一样,每个人心中的美女都不一样, 但我们都爱美女。

人人都在说工程师文化,90%的同学们向往工程师文化,然而95%的同学们觉得自己的部门没有工程师文化。但关于工程师文化,事实告诉我们两件事:

事实1是:我们定义工程师文化的标准不一样。这就跟美女一样,每个人心中的美女都不一样, 但我们都爱美女。

事实2是:工程师文化还是能客观感觉出来的。假如你真是个美女,大家还是都会认为你漂亮的。标准再不一样,敢说奥黛丽赫本丑的人还是需要莫大并且不要脸的勇气。

基于这个不恰当的比喻以及事实1得出:90%同学们都爱美女;基于这个不恰当的比喻以及事实2得出:95%同学们部门真的都没有美女!

基于以上事实我们做一个假设:假如同学们部门里都是美女,大家肯定都很开心!

基于这个假设得到事实3:都是美女的部门业绩一定完蛋了(这个推导过程只可意会不可言传)。

根据以上一个假设和三个事实,我们得到结论:一个部门要有美女,但不可以多!极端的工程师文化产生少数几个极端成功的公司以及大多数死得很惨的公司。

工程师文化 vs KPI文化

工程师文化是由内而外的引导和自然发生, KPI文化是由外而内的信仰和强行注入。

工程师文化着眼未来, KPI文化活在当下。

工程师文化痛恨KPI,我不爱的我不做,我爱的我疯狂。 KPI文化唯KPI说话,爱不爱都要像战士一样完成。

浅谈工程师文化

工程师文化的前提条件

信任:leader和产品对工程师绝对的信任是工程师文化的最基本条件。假如他说要使用一个更优雅的方法处理一个问题,但要花更多的时间,请你选择相信他。好的工程师非常懒惰,他这么做肯定是为未来的工作提高效率。

卓越的技术领袖存在:领导假如对技术没有信仰,只把技术当成工具,就很难说这个团队会有工程师文化。说白了不是每个不懂技术的领导都懂得欣赏优雅代码产生的美和对未来产生的深远影响。

技术列为KPI:在我参与晋升面试的时候,50%以上的技术人员讲的都是产品(what),而不是技术(how),并且他们都晋升了…..这源于业务BU总是把业务当成KPI的唯一衡量手段:技术好不好有什么关系?今年不出事,明年我已晋升。假如没有技术KPI,技术就会总被放在次优先级。

工程师文化的特征

小团队:7-12人的团队是比较适合的团队大小。有人使用pizza团队来描述一个团队的大小,就是一两张pizza能喂饱这支团队。facebook和google经常有2-3个人的团队,小团队有如下特征(中文为个人即兴翻译,能选择忽略):

1. Move Fast and Break Things(不破不立);

2. Huge Impact with Small Teams(以少为多,精准打击);

3. Be Bold and Innovative(勇敢追求卓越);

技术创新:团队必需深信技术能为业务带来不同于现在的可可以性,现在没看见不代表它不存在。技术挑战产品是由于也许你不知道还有更好的技术和架构能更简单更有效地完成一个业务任务。团队激励不单纯以业绩为主的技术的创新,比方:Google每个工程师都有20%的时间能使用于研究自己喜欢的技术,而不是跟Google相关的业务。

技术决策权大:尊重技术决策的前提就是信任技术决策,而不是简单粗暴地说:“为什么完不成?随意叫一个程序员即可以完成。”工程师未必在所有产品特性的定义上有决策的可以力,但在优先级和排期上是能从技术角度给出决策。所有的业务deadline倒排都在肯定程度上逼迫技术做出妥协,并且这些妥协慢慢变成合法理由:我的代码不好的起因是业务压力太大。Note:工程师们不要为自己邋遢的代码找理由,代码对于一个软件工程师就是尊严。

技术数据可视化:可视化技术相关数据包含圈复杂度、测试覆盖率、重复率等等,对数据好的工程师给予掌声。但是,好数据给予的是掌声而不是奖金,所有数据都能被造出来,这是个充分但不必要条件——好的代码数据一定好,数据好的代码不肯定是好代码。

分享多会议少:宁愿少开会掰扯这个应该谁做,这个P1应该谁来背,也要多听技术高手讲一个技术细节,大家都应该沉下心来沉淀一下自己的专业知识。

敏捷

敏捷——一个饱受非议,饱受争议的名词。今天我提它不是想为它正名,其实是想说大个子女孩的故事:我有个大个子女孩同学,身材非常好,178cm,人到中年坚持锻炼,身材高挑,穿啥都是给啥做广告。她告诉我,她外婆小时候走路只敢走在路坎的下面,邻居朋友走在路坎上面,这样能显得她外婆矮点。那时,高个的女孩是被嘲笑的:150cm的姑娘指着她外婆的背影说:“看这傻大个!”可今天我想对我同学说:“你女儿最好也像你这么高,我儿子去看看可以不可以追上,优化一下我家族的身高基因。”

很多人一听到敏捷就说:“还说敏捷,早过时了!” 尽管今年流行网红脸,不流行高个姑娘,可她就是比你高。那些听到敏捷就嗤之以鼻的人,你们在坚持什么?至少坚持敏捷实践的人心中有信仰,这是他们作为工程师的信仰,他们还在坚持为减少一个if else修炼每一行代码,坚持为一个完整的自动化测试不停思考,坚持为了两个板块的解耦绞尽脑汁。

即使如此,今天不谈敏捷,就像今天不谈”身高“,我们谈”身材修长“。基于这个前提,敏捷还是不敏捷就不重要了:是不是敏捷,是不是所谓的工程师文化都不重要,重要的是找到适合团队的开发方式,让团队开发效率更好,系统更健壮,特性更易扩展。

盒马基础技术团队实践

Note:本文,我仅对自己的个别两个小分队进行形容。

设计

一个软件技术团队的最终产出物是可交付的软件本身,所以不论什么花里胡哨的管理方式都没有一份安全和稳固运行的代码来的给力。好的代码应该要有设计的痕迹:简单粗暴地复原业务或者多或者少给未来埋坑。在我们团队,大部分微观代码设计源自我们自己定制的一套领域模型设计套路。套路里要有每个工程师对每个特性的精心设计,同学们的设计准则是:能设计得不完美,但不可以不思考设计;即便已经上线了的系统,只需有问题,代码永远能修改,但前提是有完善的自动化测试保护。

自动化测试

不要低估了自动化测试能给软件质量带来的深远影响:不论是当下质量,还是未来加特性,或者是单纯的重构代码。

不要低估了编写自动化测试的难度:检验代码好坏的一条标准就是——能否很容易对这块代码增加有效的自动化测试。

测试的少量准则:

代码提交前通过所有测试:测试就是验收标准,是需求验收的代码转换。准则上一条验收标准能对应至少一个断言(assert),没有断言的测试被视为无效测试;

使用given/when/then语态写单元测试;

要让测试代码更容易写必需分离代码逻辑与数据库读写;

正当用mock/stub技术,测你要测的,让你的测试更有效;

异步测试不要使用sleep;

最好的debug手段就是测试;

单元测试耗时最短,多使用单元测试覆盖代码逻辑;

越是集成测试数量应该越少,由于代价很大,性价比不高;

静态代码质量分析应该伴随每次持续集成。

持续集成/持续发布

持续集成其实什么都不是,它只是随时把大家的代码编译、打包、部署、测试,不停地跑起来,持续地告诉你代码质量能否满足你的测试要求:

测试应按测试运行时间长短分级编排在不同级别的持续集成中,时间短的测试应该跑得更频繁,比方:代码的每一次push,时间长一点的跑的频度低点,像是每隔3个小时,每天晚上11点开始……

一次编译屡次部署,在持续发布的环节中,只有第一次编译打包,后面的环境都是只部署不编译打包。

check in and pray vs check in and play:

每次提交代码要有足够的测试,并交给持续集成反馈结果,代码提交越频繁,你越容易play,代码提交时间间隔越长,你越容易pray。

持续集成的反馈要立刻修复,别让持续集成dashboard红着。

持续发布是你的终极目标

开发分支要少,不然你的持续集成容易没了方向,失去意义。

分支策略

我们采使用的分支策略肯定跟大部分同学们的分支策略背道而驰。

大库:大家都在一个库上工作,理由不在这阐述了

分支:分支尽量的少,分支越多持续集成越没意义,merge成本越高,团队分支最多也不可以超过下图

结对编程

两个人在一起写代码在阿里这么繁忙的企业应该是件让人匪夷所思的事情,但我坚持让团队践行这个实践:

一个主机,两个键盘,一个显示器

新老员工pair是新员工get实践的最快手段

pair让员工有机会互相学习对方良好的编程方式,形成团队独有的代码风格,而不是个人代码风格

时不时的pair不会降低开发效率,会提高学习热情

code review

很难说还有哪个实践比这个实践对代码质量更有意义,不过,大家codereview的方式不尽相同,我们的方式是:

团队code review,总共最好1个小时左右

每天code review

每个人的代码都要review,每个人都要讲解

发现的问题当天就改掉

看官们不要质疑,由于这件事情真的每天在发生

standup站会

站会是团队沟通的重要手段,阿里其实大部分团队都有站会习惯。

不要超过15分钟

一次只有一个人说话

只说三件事情:昨天干了什么,今天要干什么,需要什么帮助

technical session

不是每个session都跟业务相关,纯技术的session是同学们提高技术的良好手段。

retrosepctive回顾会议

总结一下过去一个迭代做的好的和不好的,做出自己下一个迭代的改进计划。假如你觉得没有使用,仔细看看图片里记录的点点滴滴:

IPM迭代计划

IPM计划会议很有必要,团队能借这个机会理解接下来两周要做什么,大概谁负责什么,大概什么时候能做完?

拜神

再好的方法也需要关公守护,废话不说,把三兄弟都放上。

IDE

永远不可以忽略IDE对编程效率带来的影响。IDE是工程师每天面对的工作环境,任何跟工程效率相关的思想都应该以IDE PLUGIN的方式让工程师们每天可使用,每天受益。Intellij作为JAVA神器存在有其必要的起因是由于它把可以帮到工程师的每一个操作都简化和方便到极致。团队用IDE的技可以能否出神入化肯定程度反映了这个团队的编程效率能否高。这是结对编程的另一个重要好处:一个团队用同一套快捷键写代码,而这套快捷键是整个团队每个成员快捷键用心得的合集。

本文作者:辉子

原文链接

本文为云栖社区原创内容,未经允许不得转载。

说明
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » 如何在团队建设工程师文化?阿里资深技术专家这么做

发表回复