极限编程和命名
Wed 12 March 2025
最近的工作过程中，在命名这块遇到比较多的问题，如果只谈命名的一些抽象原则，可以长篇大论聊个没完。
在朋友的介绍下，我恰好了解过一些极限编程的概念和原则，因此，我想通过一些极限编程的原则来谈谈编程中命名的问题。
极限编程
极限编程是一种软件开发的方法，如果说到更高层次，那就是软件工程的蓝图和指导原则。
我们先看看极限编程的目标，他解决一些什么问题：
极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更（而这样的需求变更在一些发展极快的领域中是不可避免的）将导致开发成本急速增加。
极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
引自：极限编程 - 维基百科
为了达成上面的目标，极限编程提出了一些原则，其中有一条原则是：
代码集体所有
这区别于 代码责任田 模式，它要求每个人都对整体的代码库有或多或少的理解，这意味着：
- 更大的责任，你需要知道自己在做什么
- 更加全局的视野，你的修改可能会对整个代码库造成影响
- 让
code review更有意义，可以帮助你的队友考虑到更多的情况
另一条实用原则：
简单设计
换句话说，不要过早优化和抽象，忠实实现当前的业务，不要过度设计，不要过度封装，不要过度抽象。
尝试去应对变化，而不是预测变化，因为你永远不知道明天的需求是什么。
测试驱动开发
这个原则是说，你应该先写测试，再写代码，这样可以保证你的代码是可测试的，也可以保证你的代码是可维护的。
当你尝试写测试的时候，你就会去改善你的代码结构，以便他们可以很好的被分别测试。
重构
重构，是一个持续的过程，代码应该随业务变化。
当处理初始场景时候，你的代码可以很 naive，非常具体，无需抽象；
当场景变得复杂的时候，就是重构的时机了，基于业务的重构，永远是最好的重构。
业务需求推动的重构，能让你拥有更好的抽象模型，不然会限于你的经验和见识，做出不合理的设计：过度抽象，过度封装，过度设计往往都发生在这个环节。
命名，以及极限编程
让我们结合上面的原则，来谈谈命名的话题：
代码集体所有
为了达到这个目标，几个原则：
- 基本原则：具体化，不用担心过长的名字，只不过留意一下 namespace ，可以减少 namespace 在 function 名字中的重复
- 如何应对很难起的，具体用途很难描述的名字？
- 提高或降低抽象的层级，以便有一个具体业务可以描述它的用途
- 用 TODO 标注，让大家知道这个地方需要重构，需要更好的命名
简单设计
- 保持简单，不用过度抽象，不用提前优化
- 先保证外 API 的简单，比如一个 module 的 export，再来考虑 private API 的简单
- 简单的基础上，命名就会相对容易
测试驱动开发
- 从测试中反推名字：某些难以描述功能的函数或者类，通过测试和测试用例，就可以描述清楚他的功能
- 通过测试拆分功能：你的名字可以通过这种方式保持边界清晰，功能单一
重构
- 业务驱动的重构，会让你的命名更加合理，更加具体，名字不好？持续改进就好 : )
拓展阅读
一篇很好的，关于命名的文章，也是关于软件工程的: Software Complexity: The Art of Naming