商業項目中改用中文命名標識符實例分析

2020 年註定難過，提及來並非改用中文命名的最好時機，由於在壓力之下會更傾向於減少風險，包括用老的英文命名方式。前端

另外一角度說，若是過渡順利，在這關鍵時刻，中文命名標識符這一看似不起眼的技術也許會決定企業命運。這裏看到的「工期縮短到1/10」也許是個特例，但，綜合風險和技術門檻，對比帶來的競爭力提高，它還是值得嘗試的。vue

所以，雖然此文遲來了些，但仍但願能有所助益，爲已經巨大的壓力減些負。此文主要回顧去年參與一家國內公司進行全棧改用中文命名標識符的技術調研的過程。在入活以前，一點建議：java

若是決定要試，早試早好。經濟大環境不佳，其實時機已經有點遲。最好不要等到「最後一搏」時再嘗試。重壓之下，必然會有各類姿式變形、流程誤差，而中文命名標識符雖然門檻不高，但與採用任何一項新技術（像是用一個新的庫、換用一個新的服務等等）同樣，都須要一個磨合過程。固然，這取決於主事人的膽識。mysql
同上，請像對待任何其餘新技術同樣，採用全部可以下降整體項目風險的手段。包括漸進式修改、在較小項目上試用、避免同時採用其餘新技術、避免對項目進行大規模重構等等。git

廢話說完，開始乾貨。sql

調研過程

首先固然是瞭解需求。該公司一塊主要業務是爲製造業企業的生產過程定製管理軟件（基於內部框架）。去年（2019）四月中與該公司負責人交流時，瞭解到在定製過程當中，將中文術語翻譯成合適英文會下降定製的思路流暢性，因而建議改用中文命名，省去這步翻譯，另外一個附帶好處是，移交給用戶後，用戶也能夠直接用中文進行開發，對他們的用戶來講也更方便。數據庫

接着瞭解公司使用的內部框架，外部依賴的框架、工具版本號以下：後端

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

因而很快在相似環境下作了個後端演示，在 Java 和 MySQL 中使用了中文命名。（業餘搞大約先後三四天）tomcat

因爲各類耽擱，再次聯繫到了一個月後。首先對框架的細節進一步瞭解，現狀是，在數據庫中，表名是英文名，而對應會有個中文標籤，好比SysUserGroupAuthority，中文標籤是用戶組權限。而中文命名後，表名能夠直接用中文名。該公司的內部框架那時在代表命名時做了限制——必須用英文，理想的話，放開這個限制就能夠進行中文命名。bash

在上面的演示後，基本肯定數據庫的表名、字段名、索引名，以及對應的 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"中又是「列表」。

如今想，命名應該是源於需求文檔。

此文僅做拋磚引玉。若有對細節的問題，或是在嘗試中碰到了中文致使的問題，歡迎告知，將盡力而爲。