复杂度

做了这么多年软件，我越来越觉得工程问题的核心其实就三个字，复杂度。怎么管住它，怎么不让它吞噬掉团队的精力和信心，是我每天都在面对的事情。23年我和一位同事合译了《敏捷开发的艺术》第二版，24年春节后上市，自己来回翻了好几遍，翻译和校对也都认真，对内容和质量都算满意。但比起"翻了一本书"这件事本身，真正让我觉得值的是翻译过程中对敏捷实践的重新理解。

软件工程里的复杂度分两种，一种是技术复杂度，系统的规模、架构、算法，这些硬的东西；另一种是人员复杂度，团队怎么组建、怎么协作、怎么沟通，这些软的东西。敏捷方法论在技术层面靠持续集成、TDD、重构这些实践来压住复杂度，在人员层面靠团队协作、迭代交付让事情推得更顺畅。

道理都对。

但在我过去经历的大大小小的项目里，坦白讲很多实践并没有切中要害，反而作为一种新的变量给团队带来了更多的困惑和冲突。敏捷做得不好的时候，它本身就是复杂度的来源，这是我见过最多的反模式。这本书的作者和我们一样是实践派，他对这些困惑感同身受，所以这本书不是在讲"敏捷是什么"，它讲的是每一项实践到底为什么要这么做。它列出了每一项实践的具体行动项，提示了过程中可能出现的反模式与困难，整理了度量指标，甚至为每一项实践面对的问题推荐了替代方案。经典的软件工程著作《人件》说过，失败项目中没有一个单纯因为技术问题而失败。工程失败大多败在人的层面，而这正是这本书花了大量笔墨去处理的事情。

翻译此书的过程使我受益匪浅，其中很多实践在我后来的项目里的确用上了。

如今AI来了，很多以前需要人做的工序开始可以被自动化。持续集成的流水线更加智能，代码审查可以实时完成，测试用例能自动生成，架构设计都能让AI给出建议，效率的提升的确是实实在在的。但我想说的是，这本书里讲的那些原则一点都没有过时。AI能加速工序的完成，但它替代不了人对"为什么要这么做"的理解。一个不懂TDD原理的工程师，哪怕有最好的AI帮他写测试，他也写不出可测试的代码；一个不理解持续集成逻辑的团队，哪怕部署了最先进的CI/CD，该堵的地方照样堵。工具从来不是瓶颈，理解才是。

这本书的开篇这样说："敏捷无处不在，但矛盾的是，它又无影无踪。"翻译了它之后我才真的体会到这句话的分量。很多团队在做"敏捷"，但真正理解敏捷背后那些实践为什么要这样做的人，其实很少。在AI时代这种理解变得更加紧要了，工具越强大，使用工具的人就越需要清楚自己在做什么。我在译者序里写过一句话，"开发者在编码时如何沟通协作是软件生产活动效率的决定性因素"，到今天我仍然这么认为。

编程是个手艺活。工程的本质从来没变过，控制复杂度。不管手里的工具是白板上的便利贴还是AI pair programming，手艺在人身上。

24.02.28