工程师文化vsKPI文化浅谈-国内

基于以上事实，我们做出一个假设：如果系里的学生都是美女，那大家都会很幸福！

基于这个假设，我们得到事实3：美女满堂的部门业绩一定是毁了（这个推导过程只能想象，无法解释）。

基于以上假设和三个事实，我们得出结论：一个部门应该有美女，但不能太多！ 极端的工程文化造就了一些极其成功的公司，但大多数公司都悲惨地消亡了。

工程师文化与 KPI 文化

浅谈工程师文化

工程师文化的先决条件

信任：对工程师和产品的绝对信任是工程文化最基本的条件。 如果他说他想以更优雅的方式解决一个问题，但需要更多时间，请相信他。 一个好的工程师是很懒的。 他必须这样做，才能提高以后工作的效率。

优秀技术领导者的存在：如果领导者对技术没有信心，只把技术当作工具，很难说团队会有工程文化。 说白了，并不是每一个不懂技术的领导者都懂得如何欣赏优雅代码之美及其对未来的深远影响。

技术被列为KPI：我参加晋升面试时，50%以上的技术人员谈的是产品（什么）而不是技术（怎么），而且都被晋升了……这要归功于业务BU业务始终被视为衡量KPI的唯一标准：技术好不好又有什么关系呢？ 如果今年不出意外的话，明年我就升职了。 如果没有技术 KPI，技术将永远被置于次要地位。

工程师文化的特点

小团队：7-12人的团队是比较合适的团队规模。 有人用披萨团队来形容一个团队的规模，即一两个披萨就可以养活整个团队。 而往往2-3人的团队，小团队有以下特点（中文是个人即兴翻译，可以选择忽略）：

技术创新：团队要坚信技术可以给业务带来不同的可能性。 如果你现在看不到它，并不意味着它不存在。 技术挑战产品是因为也许你不知道有更好的技术和架构可以更简单有效地完成业务任务。 该团队鼓励不纯粹基于性能的技术创新。 例如，每个工程师可以花20%的时间研究他或她喜欢的技术而不是相关业务。

强大的技术决策权：尊重技术决策的前提是信任技术决策，而不是简单粗暴地说：“为什么完成不了？叫任何一个程序员就可以完成”。 工程师可能没有能力对所有产品功能的定义做出决策，但可以从技术角度做出优先级和调度的决策。 所有的业务倒置都会迫使技术在一定程度上做出妥协，而这些妥协慢慢变成正当理由：我的代码不好的原因是因为业务压力太大了。 注意：工程师不应该为自己的马虎代码找借口。 代码对于软件工程师来说是尊严。

技术数据可视化：可视化技术相关数据，包括圈复杂度、测试覆盖率、重复率等火炬之光2工程师属性点，给数据好的工程师鼓掌。 然而，好的数据带来的是掌声而不是奖金。 所有数据都可以创建。 这是一个充分但不必要的条件——好的代码和数据一定是好的，有好的数据的代码不一定是好代码。

多分享，少开会：我宁愿少开会去争论谁应该做这件事，谁应该背这个P1，多听技术专家谈论技术细节。 每个人都应该静下心来积累自己的专业知识。

敏捷

敏捷——一个饱受批评和争议的术语。 今天提起来不是为了辩解，其实是想讲一个高个子女生的故事：我有一个高个子女生同学，身材很好，178cm。 她人到中年坚持锻炼，身材高挑，想穿什么就穿什么。 广告。 她告诉我，小时候，她奶奶只敢在路坎下行走。 邻居和朋友走在路坎上，这样奶奶就显得矮了。 当时，高个子女孩被嘲笑：150厘米的女孩指着奶奶的背说：“你看这个愚蠢的大家伙！” 但今天我想对同学们说：“你的女儿最好和你一样高。 ，我儿子就去看看他能不能赶上并优化我家的身高基因。”

很多人一听到敏捷就会说：“你还讲敏捷，已经过时了！” 虽然今年流行网红，高个子女生不流行，但她还是比你高。 那些嘲笑敏捷的人，你们到底在坚持什么？ 至少那些坚持敏捷实践的人心里有信念。 这是他们作为工程师的信念。 他们依然坚持练习每一行代码减少一个if else，坚持思考完整的自动化测试，坚持解决两个模块。 夫妻俩绞尽脑汁。

即便如此，今天我们不谈敏捷，就像今天我们不谈“身高”，我们谈“苗条身材”一样。 基于这个前提，敏捷与否并不重要：敏捷与否、是否有所谓的工程文化都无关紧要。 重要的是找到适合团队的开发方式，让团队开发更高效，系统更健壮，功能更易用。 扩大。

盒马基础技术团队实践

注：在这篇文章中，我只描述了我自己的两个小队。

设计

一个软件技术团队的最终产出就是可交付的软件本身，所以无论使用什么花哨的管理方法，都不如安全稳定运行的代码来得强大。 好的代码应该有设计的痕迹：简单粗暴地还原业务或多或少都会给未来埋下陷阱。 在我们团队中，大部分微代码设计都来自于我们自己定制的一套领域模型设计例程。 该例程必须包括每个工程师对每个功能的精心设计。 同学们的设计原则是：设计可以不完美，但一定要思考设计； 即使系统已经上线，只要出现问题，代码随时可以修改。 但前提是有完整的自动化测试保障。

自动化测试

不要低估自动化测试对软件质量的深远影响：无论是当前质量、未来添加功能还是简单地重构代码。

不要低估编写自动化测试的难度：测试代码质量的标准之一是是否容易为这段代码添加有效的自动化测试。

测试的一些原则：

持续集成/持续发布

持续集成其实没什么。 它只是随时编译、打包、部署、测试你的代码，不停地运行，不断告诉你代码质量是否满足你的测试要求：

分支策略

我们采取的分支策略一定是和大多数学生的分支策略相反的。

Daku：每个人都在同一个库上工作，所以我不会在这里解释原因。

分支：保留尽可能少的分支。 分支越多，持续集成的意义就越小。 合并成本越高，团队的分支最多不要超过下图。

结对编程

在阿里巴巴这样繁忙的公司里，两个人一起写代码是难以置信的，但我坚持让团队实践这种做法：

代码

很难说哪种做法比这种做法对代码质量更有意义。 然而，每个人的做法都不同。 我们的做法是：

审查会议

总结上一次迭代中所做的好和坏的事情，并为下一次迭代制定自己的改进计划。 如果觉得没啥用，再仔细看看图中记录的点点滴滴：

IPM迭代计划

IPM 计划会议是必要的。 团队可以借此机会了解接下来两周要做什么，谁负责什么，什么时候完成？

敬拜神

手段再好，也还是需要关公的保护。 废话不多说，把三兄弟都放上来吧。

集成开发环境

IDE对编程效率的影响是永远不能忽视的。 IDE是工程师每天面对的工作环境。 任何与工程效率相关的想法都应该以 IDE 的形式每天为工程师提供并受益。 它之所以作为JAVA神器而存在，是因为它简化并使得每一个能够帮助工程师的操作都变得异常简单方便。 团队使用IDE的技巧是否精湛，一定程度上体现了团队的编程效率是否高。 这是结对编程的另一个重要好处：一个团队使用同一套快捷键来编写代码，而这套快捷键是整个团队每个成员的快捷键使用经验的集合。