商业项目中改用中文命名标识符实例分析

2020 年注定难过，提及来并非改用中文命名的最好时机，由于在压力之下会更倾向于减少风险，包括用老的英文命名方式。

另外一角度说，若是过渡顺利，在这关键时刻，中文命名标识符这一看似不起眼的技术也许会决定企业命运。这里看到的“工期缩短到1/10”也许是个特例，但，综合风险和技术门槛，对比带来的竞争力提高，它还是值得尝试的。

所以，虽然此文迟来了些，但仍但愿能有所助益，为已经巨大的压力減些负。此文主要回顾去年参与一家国内公司进行全栈改用中文命名标识符的技术调研的过程。在入活以前，一点建议：

1. 若是决定要试，早试早好。经济大环境不佳，其实时机已经有点迟。最好不要等到“最后一搏”时再尝试。重压之下，必然会有各类姿式变形、流程误差，而中文命名标识符虽然门槛不高，但与采用任何一项新技术（像是用一个新的库、换用一个新的服务等等）同样，都须要一个磨合过程。固然，这取决于主事人的胆识。

2. 同上，请像对待任何其余新技术同样，采用全部可以下降整体项目风险的手段。包括渐进式修改、在较小项目上试用、避免同时采用其余新技术、避免对项目进行大规模重构等等。

废话说完，开始干货。

调研过程

首先固然是了解需求。该公司一块主要业务是为制造业企业的生产过程定制管理软件（基于内部框架）。去年（2019）四月中与该公司负责人交流时，了解到在定制过程当中，将中文术语翻译成合适英文会下降定制的思路流畅性，因而建议改用中文命名，省去这步翻译，另外一个附带好处是，移交给用户后，用户也能够直接用中文进行开发，对他们的用户来讲也更方便。

接着了解公司使用的内部框架，外部依赖的框架、工具版本号以下：

• java 1.7.0
• mysql 5.5
• tomcat 7.0.77
• eclipse Kepler Service Release 1
• hibernate 3.3.2 GA

因而很快在相似环境下作了个后端演示，在 Java 和 MySQL 中使用了中文命名。（业余搞大约先后三四天）

因为各类耽搁，再次联系到了一个月后。首先对框架的细节进一步了解，现状是，在数据库中，表名是英文名，而对应会有个中文标签，好比SysUserGroupAuthority，中文标签是用户组权限。而中文命名后，表名能够直接用中文名。该公司的内部框架那时在代表命名时做了限制——必须用英文，理想的话，放开这个限制就能够进行中文命名。

在上面的演示后，基本肯定数据库的表名、字段名、索引名，以及对应的 Java 类名、属性均可用中文命名。

接下去开始对前端进行调研。先要来了一个前端的示例（WebPack），其中有一些业务相关部分。

两小时将客户端示例的forms部分中的标识符和字符串中文化，下面是 git log，可见也采用了以前汉化 vue 时的先类名后内部的顺序：

Date:   Tue May 21 00:07:27 2019 -0700
    变量 方法 重命名

Date:   Tue May 21 00:01:55 2019 -0700
    重命名路径 datasource->数据源

Date:   Tue May 21 00:00:00 2019 -0700
    重命名路径 base->基本

Date:   Mon May 20 23:57:04 2019 -0700
    重命名路径 SysUser->系统用户

Date:   Mon May 20 23:08:48 2019 -0700
    表格_系统用户_基本数据源_系统用户 属性重命名

Date:   Mon May 20 23:06:43 2019 -0700
    重命名类 Form_SysUser->表格_系统用户

Date:   Mon May 20 23:04:42 2019 -0700
    系统用户_混合域 属性重命名

Date:   Mon May 20 22:59:51 2019 -0700
    SysUser_FieldsMix -> 系统用户_混合域

Date:   Mon May 20 22:57:07 2019 -0700
    重命名类Form_SysUser_DataSource_SysUser

Date:   Mon May 20 22:51:27 2019 -0700
    重命名类Form_SysUser_DataSourceBase_SysUser

Date:   Mon May 20 22:44:43 2019 -0700
    重命名类FormBase_SysUser

Date:   Mon May 20 22:40:49 2019 -0700
    更改属性名

Date:   Mon May 20 22:34:20 2019 -0700
    修改字符串内容

至此基本完成技术验证，想到的缺失环节是先后端通讯部分。有两个选择，一是相似以前用一个原型作验证；二是在实际代码中用最小代价做全栈验证。

第一个选择的问题是，1）搭建一个先后端通讯原型并验证功能须要必定工做量；2）仍很难彻底达到实际代码验证的效果

第二个选择的“最小代价”是指，在实际代码中，去掉对节点名的命名限制后，添加仅仅一个中文节点，对先后端作相应修改后，检验所有功能是否正常。就看这个工做量和第一个选择的工做量有多大差距。若是没有太大差距，我的认为第二个选择会更合适。这点也获得了公司负责人的认同。

以后，据了解该公司打算在合适的项目中进行尝试。最近一次联系是在去年末，据说在进行技术栈替换，计划今年（2020）加入中文命名的支持。拭目以待吧。

后记

调研过程的跨度虽大，但耗时并很少（加一块儿大概一周多点）。期间发现了一些命名相关问题，也向负责人反映了：

1. 用中文命名从某种意义上比用英文命名更须要推敲一点。由于中文命名词不达意时，视觉效果会比英文更明显。好比“SysUserSetFormType"->"画面自定义类型”， 看英文的话更像”用户定义表格类型“？固然一开始起好名的话之后就方便。

2. 术语尽可能一致（最好把术语表文档化），这与英文命名相似。好比“table”，在几个label中是“表”，但 “importTable”翻成了“数据导入”而不是“导入表”，而”NumSeqTable"中又是“列表”。

如今想，命名应该是源于需求文档。

此文仅做抛砖引玉。若有对细节的问题，或是在尝试中碰到了中文致使的问题，欢迎告知，将尽力而为。