用工具解决问题

2年前写的工程师文化

谢东升Forest，公众号：架构栈说说我们的工程师文化

2年前，写了一篇工程师文化，2年后，回过头来看这篇文章，工程师文化对企业最大的价值之一（也许没有之一）就是“工具解决问题”。

只有全面工具化，建立起杠杆的作用， 放大每个工程师的生产力。能用工具解决的问题， 就不要让工程师上。

一个团队基础设施做的好不好的唯一标准，就是工程师离职去了另外一家公司以后，会不会怀念前团队的工具：现在公司的工具没有以前公司好用啊。

从产品开发生命周期来看每个环节都很重要，文档管理、问题追踪、代码管理、持续集成、代码质量检查、移动APP打包、测试开发环境、部署上线、监控报警，选择最适合自己团队的。如果现有的产品都无法满足需，求那么我们就做二次开发。

敏捷

用了差不多10来年的Jira。 Jira 的好处是它功能强大可配置， 配套的 Confluence 等设施完善。每个产品线有自己的敏捷面板， 每两周一次迭代，周一计划会，下周五回顾会。 每天早上晨会，大家除了过一下昨天的进度和今天的计划， 还会主要把一些小的疑问/困难放在晨会里说出来， 10 个人的晨会控制在15 分钟内就结束了，这才是我们要的效率。

什么是迭代？其实迭代就是我们每天坐的地铁，这个迭代能做完什么就做完什么。 车又不等人，做不完的等下一班地铁呗。

版本控制

5年前在顺丰的时候，用的版本控制工具是私有部署的 GitLab。 除了 Repository，还用上了里面Merge Request/CI/CD/Wiki 等功能。

比如我们加一个新功能大概流程是这样的：

• fork 项目到本地开发

• push 到自己的 repo，提一个 merge request

• 触发了 CI 检查

  • 静态工具检查一波有没有基本错误问题，比如没有关闭连接、存在NPE问题等

  • 版本工具检查一下有没有 migration 上的问题

  • 跑完全部UT，看看单元测试能不能过

• @ code owner 来 review 代码

  • 会有线上评论，不好解释的线下1vs1

  • 有问题就打回去修改，重新 push

• approve + merge

• 自动触发了自动构建

• 构建完成以后自动触发了发版，发版完成

整个过程中 contributor 需要 fork + coding + merge request， code owner 需要 review + approve + merge， 剩下的单元测试、code构建、版本更新都是一条流水线做完。

监控

再举一个几年前自研的例子，当时公司的监控系统实际上使用好几个开源组件加上自己的一些代码粘合，监控系统统一了日志格式、自动化了日志收集、自动化创建监控模板，相当于任何一个新的（微）服务，在上线时就已经有了基本的监控图表，想定制直接创建图拖监控项上去，一个完整的 监控控制台就有了。

写在最后

所谓的工程师文化并不是高喊着口号，走走形式就可以让所有人可以感受到的，是需要通过我们日常工作中持续地一点一滴来渗透，怎么提升工程师的产出效率，那么就这么做。

描二维码或手动搜索微信公众号【架构栈】：ForestNotes

欢迎转载，带上以下二维码即可

              

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓