读《Software Engineering at Google》（23）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（23）—— Continuous Integration

• 📖：@通用定义（Generally Definition），作为软件开发的一种实践，以较高频率集成大家的工作，且采用自动化构建集成品，尤其包括自动化验证。

  🤔：持续集成（Continuous Integration），不就是打包嘛，需要每天都编译一遍、链接一遍、打包一遍嘛？这个困惑一直在我心头，如果再补刀个低碳，没必要的重复就是在浪费电力，更让我难以说通自己，为何要费时费力，名其曰持续集成？再看一眼定义，吸引我的关键字：“大家”、“高频率”、“自动验证”。这里所谓的大家，如果 1 个人，那就是胡扯；如果是 10 个人，有那么点感觉，可是 10 人的开发工作，至于再搭进去 20 人的持续集成团队嘛，看到数量，就知道自己没有持续集成的实战经验；如果是 100 个人，配比上 20 人的持续集成团队，如果是 1000 个人，配比上 20 人的持续集成团队。也就是说，这里的大家，指生产代码的开发方，大家的人数必须跟持续集成的人数，有明显的规模优势和收益。不得不说的一个误解，那就是，经常把持续集成团队当作天使团，随要随到，完工就走，随时呼来改进，听起来就是天使般的幼稚感。至于为何“高频率”，还是得放入 100～1000 开发人的规模背景下看，如果半个月到个把月做个集成，说不定编译都成问题。所以如何能够掌握好集成的频率，就是在低碳和返工之间动态平衡，大家代码质量较高，团队都规矩契约式开发，就可以把集成的频率降下来。最后的关键字，也是压垮持续集成的最后一枚钢针，那就是自动验证，说白了就是要有完整的可自动化验证的用例，不只是能够自动化运行的例子，更是要能够自动化判定结果的例子，而且这些例子在开发过程里持续在补充和改进，即所谓的完整自动验证。就像看到 TDD 的初步理解，不就是通过测试用例来取得开发嘛，如此粗浅的理解的后果就是，测试用例烂得拿不出手，只有测试用例重构，才能称得上 TDD 入门。

• 📖：@Google，持续集成是持续组装和测试，谷歌的整个复杂又快速发展的生态系统。

  🤔：看到“整个”，而且是谷歌的“整个”，忽然间呼吸屏住，不自觉紧张起来，这可是整个谷歌，这个动作是不是把太平洋当作一个汤碗，再配合另一个空碗，左边右边反复倒，可以让汤快速凉快下来，而且这过程里，还不能让汤里的水草搅乱，鱼啊、虾啊还得活得自由自在。这样的持续集成，玩得超过我的想象力。能做出这样的决策，绝非技术因素，更多来自曾经的苦难精力。只有在持续的 BUG 针扎，只有在持续的向往面前无数次立正稍息，只有在持续流失大量针扎中信心粉碎的开发，也只有留下了持续改进勇敢的心，才会走出持续集成的坚定脚步。

    —— By 术子米德 @2022.05.01