大家好，我是肖哥 shelwin, 一个游走在开发，测试，CI，DeveOps 的软件工程老鸟。一直以来，做的事情蛮多蛮杂。但是一路走来，觉得测试开发这一名称似乎才是最贴近我的工作内容的。很高兴在 testerhome 遇到这么多同道中人。下面这篇文章是我写的 2019 年上半年个人总结，希望大家喜欢。

前段时间读到一句关于敏捷的格言，大意是如果把敏捷的所有流程都去掉，只保留一个的话，它应该是回顾，即 retrospective。相信实践过敏捷的朋友，对这句话多少会有一些共鸣。

在我看来，回顾的意义在于及时总结经验教训，并以此指导工作的改进。这里，我借鉴敏捷中的回顾思想，做下这半年的个人工作总结，包括三部分：做得好需要坚持的，做得不好需要改进的，以及改进计划。

先聊聊做得还行的。一个是我完成了持续集成 (CI) 数据监控平台的开发工作。在项目中，研发团队使用的是一个跨产品线，设备组成复杂，任务多样的 CI 系统。由于开发人数多，代码提交和发布频繁，CI 每天都会产生大量数据。如何高效监控 CI 数据，及时掌握 CI 整体和局部运行情况？用人力去做，成本高，效率低，而且容易疏漏。

自动化的监控平台则可以低成本地采集，处理和存储来自 CI 各个组件和任务的数据，然后基于这些数据生成信息量大，样式丰富，用户友好的图表，供大家在 web 端访问。

一开始我以为只有 CI 同事会感兴趣，后来发现研发团队几乎每个成员都在日常使用它。我想，CI 监控平台之所以受大家欢迎，可能是由于 CI 的特殊角色。CI 不是一个孤立模块，而是将软件开发，测试，交付，管理等连接在一起的"中枢"。CI 的监控结果，对每个人都是有意义的。

从实现角度看，平台是一个全栈开发项目。后端是 Python 轻量级 web 框架 bottle，前端是组件化 UI 库 React JS，数据库是 MySQL。这半年来，我基本上每天都会花一点时间在该项目上。经历多，收获也多。感受比较深的有两点。

一是技术选型蛮重要。得益于 Python 和 React JS 开发效率高和生态丰富的优势，我完全利用业余时间，一个月就实现了平台上线。二是代码重构不能少。这个项目大大小小的重构次数有许多，我最近甚至花了一周时间重写了 70% 左右的代码。持续重构维持了平台的生命力。

另一件做得不错的事情，是在大家共同努力下，我们明显提升了 CI 的稳定性。CI 之所以难，难在研发团队对 CI 的期望非常之高。大家希望CI 既要覆盖全 (包含多级别测试)，又要效率高 (尽可能缩短执行时间)，还要稳定 (不发生中断且结果具有一致性)。然而，资源的有限性，框架的约束性，技术的瓶颈等，让 CI 难以同时满足需求。

我们只能有所侧重，影响最大的 CI 稳定性成为首要提升的目标。具体来说，我们采取数据驱动的工作方式，利用 CI 监控平台，将 CI 中出现的中断和不稳定的情况完整识别与记录，并根据问题程度确定改进优先级，同时根据必要性引入软件开发或测试协同改进。

有一类改进工作我的印象比较深。那就是针对 CI 框架存在的易受人为影响的漏洞，从技术上进行封堵。例如，当发现有 CI 中断是因为存在依赖关系的代码改动由于提交者遗忘没有同时合入而导致的时，我们就开发了将依赖性改动同时合入和发布的自动化脚本，同样的 CI 中断就再也没有出现。

类似的例子很多。做 CI 以来，我有一个感受越来越强烈，那就是自动化程度越高，CI 通常就越稳定。一个不稳定的 CI，往往存在着一个或者多个环节依赖人工干预的。人的可靠性远不如机器。一个几百人的开发团队，即使每人每年只犯一次让 CI 中断的疏忽，CI 也可能一整年都是瘫痪的。我们坚持提升 CI 的自动化水平，结果没有让我们失望。

还有一点做得好的，就是我坚持技术写作。写文章对我来说，是一个运用"费曼学习法"进行总结的方式。对于一个概念或技术，懂了还是没懂？是真懂还是假懂？在写作中，我不断自我质疑和完善。另外，我写作的内容来自实际工作。这样有一个好处，那就是在整理资料和写作时，我经常会产生一些新的改进工作的想法，而工作的改进又为写作提供新的素材。这是一个正反馈的模式。

那么，这半年有哪些地方做得不够好？又如何去改进呢？一是我们 CI 的运行效率仍然较低。随着项目推进，一方面，软件功能在增加，这意味测试用例数量在增长；另一方面，包含新功能实现，bug 修复，代码重构等的代码提交频率在增长或者维持高位，而每次提交通常要触发所有测试。两方面叠加下，CI 的执行负载增加，反馈时间变长，制约着团队开发和交付效率的提升。

如何改善这一状况呢？一种最直接的做法是增加资源。由于我们某一级测试用的是专有硬件，价格昂贵。我们耗尽预算增加了几套设备， 却连"塞牙缝都不够"，不能带来实质改变。除此之外，我们还尝试了优化用例，合并执行，并行执行，自动修复测试线等手段，虽然提升了 CI 的运行效率，但是距离大家的期望还有距离。

一个继续改进的计划是实现选择性 CI 和选择性回归测试。具体来说，我们可以基于代码改动的具体内容和每一行代码与 CI 任务或测试用例之间的依赖性关系，来动态地去选择可能受代码改动影响的一部分 CI 任务和一部分测试用例来执行。

另一个做得不够好的是团队建设方面。作为小团队的负责人，我这半年差不多只花了两三成的时间在团队工作上。得益于小伙伴们良好的自我驱动意识，我们的工作完成得还不错。但是在我看来有两点不足，一是大家维护性工作偏多而创造性工作偏少，二是个人单打独斗的成果多而团队协作的成果少。

为此，我计划花更多精力在建设团队方面。一个是从技术角度，引导大家加强框架优化和工具自研工作。框架优化不用说，是我们一直在做的。工具自研之所以要加强，是因为在我们持续改进一段时间以后，许多剩余问题指向了第三方工具。通过自研来取代部分第三方工具，我们的工作有望更进一步。

从非技术角度，对大家的工作计划制定和工作执行过程中遇到的障碍，我需要更多关注。另外，各种敏捷会议，技术分享会，代码评审会等，还需要坚持组织。还有，各种改进措施的落地情况和效果评估，也需要我密切关注。

以上就是我的个人半年度总结。做得好的，希望自己能够坚持下去。做得不好的，目前也有一些改进的计划，希望这些计划能够落地并产生效果。

最后，发现写个人总结比写技术文章难多了。这篇文章，大概比平常多花了几倍时间。啰嗦了这么多，感谢大家的阅读！另外，想看一些测试开发，持续集成，Python 编程等领域原创文章的同学，欢迎关注我的个人公众号 [测试不将就] 或同名博客，谢谢。