业余项目用中文命名的舒适

[xuanwu]

早先答过如何看待国内开源项目的不可持续性？。最近做的木兰重现项目和参与的中文代码补全插件都基本使用了中文命名，一些个人体会如下。

基本是用碎片时间做开发维护，少则几分钟，多则一两小时。可以尽量充分利用碎片时间的一个重要因素就是项目使用母语命名。

中文代码补全插件主要参与了代码互评和部分测试、文档等等维护工作。如果用的是英文命名，双方会花更多时间精力才能充分领会，还要花更多时间保证可读性。

木兰项目基本仍是单人进行。Python 代码主要是参考木兰逆向代码并沿用设计，新加的主要是部分重构和测试相关代码。木兰实现的有一些简单的算法和中文数据处理，以及一个针对木兰代码的编辑器原型（高亮、格式化等等），主要是考验木兰编程语言的实用性，这部分基本是自己发挥。

对我来说最大的舒适之一，就是任何稍微有点动力改进的时候，坐下来几分钟就能接续上之前的思路并且找到下手处。再一个就是基本不再需要费劲思量合适的英文命名（项目内用得到的大多数编译器相关术语已经有了中文对应）。并不是任何空闲时间都有动力读写代码，不同的时间点的动力也有大小之分。任何一点增加读写代码开销的因素，都会抵消部分动力，而越是碎片化的时间，原本的动力就会更小（“就那么几分钟，刷个头条吧”）。拿起来的频度越小，再拿起来的动力就越小，这是个恶性循环。母语命名可以一定程度上消减这一“旋涡”。

命名本身在开发过程中是比较“末端”的任务（见一站式 IDE 的构想：从头审视产品研发过程），功能取舍、设计架构都能在更“高”层次决定项目走向，但母语命名绝不是“善小”而已。开发时实际上总是在反复读代码，这就是一个不断对代码逻辑进行重新梳理的过程。很多时候可以发现一些可重构的部分甚至可改进的设计。如果顶层设计可以一步到位，当然最好，但由于业余项目往往是不断地在原型基础上作改进，一个非常全面的顶层设计几乎只能在到一个里程碑、功能稳定时，再重新进行。更多时候，是不断地作小改进。能够更加流畅地阅读代码就成了关键因素。如果读自己代码时的常要被“理解某个命名”打断思路，像是一直在和过去的自己较劲，再去考虑重构、设计就需要更大代价。

回过头说如何利用几分钟的碎片时间。即便没有动力写实现部分的代码，还是有很多“隐形”开发任务适合，代码互评、写测试用例、文档更新、回顾待做事项、回应问题报告、与合作者交流等等。这些任务仍然能从母语命名获得益处。