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

　　2020 年注定难过，说起来并不是改用中文命名的最好时机，因为在压力之下会更倾向于减小风险，包括用老的英文命名方式。
　　另一角度说，如果过渡顺利，在这关键时刻，中文命名标识符这一看似不起眼的技术也许会决定企业命运。之前看到过的＂工期缩短到1/10＂也许是个特例，但，综合风险和技术门槛，对比带来的竞争力提升，它仍是值得尝试的。
　　因此，虽然此文迟来了些，但仍希望能有所助益，为已经巨大的压力減些负。此文主要回顾去年参与一家国内公司进行全栈改用中文命名标识符的技术调研的过程。在入活之前，一点建议：如果决定要试，早试早好。经济大环境不佳，其实时机已经有点迟。最好不要等到＂最后一搏＂时再尝试。重压之下，必然会有各种姿势变形、流程偏差，而中文命名标识符虽然门槛不高，但与采用任何一项新技术（像是用一个新的库、换用一个新的服务等等）一样，都需要一个磨合过程。当然，这取决于主事人的胆识。同上，请像对待任何其他新技术一样，采用所有能够降低总体项目风险的手段。包括渐进式修改、在较小项目上试用、避免同时采用其他新技术、避免对项目进行大规模重构等等。
　　废话说完，开始干货。调研过程
　　首先当然是了解需求。该公司一块主要业务是为制造业企业的生产过程定制管理软件（基于内部框架）。去年（2019）四月中与该公司负责人交流时，了解到在定制过程中，将中文术语翻译成合适英文会降低定制的思路流畅性，于是建议改用中文命名，省去这步翻译，另一个附带好处是，移交给用户后，用户也可以直接用中文进行开发，对他们的用户来说也更方便。
　　接着了解公司使用的内部框架，外部依赖的框架、工具版本号如下：java 1.7.0mysql 5.5tomcat 7.0.77eclipse Kepler Service Release 1hibernate 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）加入中文命名的支持。拭目以待吧。后记
　　调研过程的跨度虽大，但耗时并不多（加一起大概一周多点）。期间发现了一些命名相关问题，也向负责人反映了：用中文命名从某种意义上比用英文命名更需要推敲一点。因为中文命名词不达意时，视觉效果会比英文更明显。比如＂SysUserSetFormType＂->＂画面自定义类型＂， 看英文的话更像＂用户定义表格类型＂？当然一开始起好名的话以后就方便。术语尽量一致（最好把术语表文档化），这与英文命名类似。比如＂table＂，在几个label中是＂表＂，但 ＂importTable＂翻成了＂数据导入＂而不是＂导入表＂，而＂NumSeqTable＂中又是＂列表＂。
　　现在想，命名应该是源于需求文档。
　　此文仅作抛砖引玉。如有对细节的问题，或是在尝试中碰到了中文导致的问题，欢迎告知，将尽力而为。