2020 年註定難過，說起來並不是改用中文命名的最好時機，因為在壓力之下會更傾向於減小風險，包括用老的英文命名方式。
另一角度說，如果過渡順利，在這關鍵時刻，中文命名標識符這一看似不起眼的技術也許會決定企業命運。之前看到過的“工期縮短到1/10”也許是個特例，但，綜合風險和技術門檻，對比帶來的競爭力提升，它仍是值得嘗試的。
因此，雖然此文遲來了些，但仍希望能有所助益，為已經巨大的壓力減些負。此文主要回顧去年參與一家國內公司進行全棧改用中文命名標識符的技術調研的過程。在入活之前，一點建議：
- 如果決定要試，早試早好。經濟大環境不佳，其實時機已經有點遲。最好不要等到“最後一搏”時再嘗試。重壓之下，必然會有各種姿勢變形、流程偏差，而中文命名標識符雖然門檻不高，但與採用任何一項新技術（像是用一個新的庫、換用一個新的服務等等）一樣，都需要一個磨合過程。當然，這取決於主事人的膽識。
- 同上，請像對待任何其他新技術一樣，採用所有能夠降低總體項目風險的手段。包括漸進式修改、在較小項目上試用、避免同時採用其他新技術、避免對項目進行大規模重構等等。
廢話說完，開始乾貨。
調研過程
首先當然是瞭解需求。該公司一塊主要業務是為製造業企業的生產過程定製管理軟件（基於內部框架）。去年（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 時的先類名後內部的順序：
<code>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
修改字符串內容
/<code>
至此基本完成技術驗證，想到的缺失環節是前後端通信部分。有兩個選擇，一是類似之前用一個原型做驗證；二是在實際代碼中用最小代價作全棧驗證。
第一個選擇的問題是，1）搭建一個前後端通信原型並驗證功能需要一定工作量；2）仍很難完全達到實際代碼驗證的效果
第二個選擇的“最小代價”是指，在實際代碼中，去掉對節點名的命名限制後，添加僅僅一箇中文節點，對前後端做相應修改後，檢驗全部功能是否正常。就看這個工作量和第一個選擇的工作量有多大差距。如果沒有太大差距，個人認為第二個選擇會更合適。這點也得到了公司負責人的認同。
之後，據瞭解該公司打算在合適的項目中進行嘗試。最近一次聯繫是在去年底，聽說在進行技術棧替換，計劃今年（2020）加入中文命名的支持。拭目以待吧。
後記
調研過程的跨度雖大，但耗時並不多（加一起大概一週多點）。期間發現了一些命名相關問題，也向負責人反映了：
- 用中文命名從某種意義上比用英文命名更需要推敲一點。因為中文命名詞不達意時，視覺效果會比英文更明顯。比如“SysUserSetFormType"->"畫面自定義類型”， 看英文的話更像”用戶定義表格類型“？當然一開始起好名的話以後就方便。
- 術語儘量一致（最好把術語表文檔化），這與英文命名類似。比如“table”，在幾個label中是“表”，但 “importTable”翻成了“數據導入”而不是“導入表”，而”NumSeqTable"中又是“列表”。
現在想，命名應該是源於需求文檔。
此文僅作拋磚引玉。如有對細節的問題，或是在嘗試中碰到了中文導致的問題，歡迎告知，將盡力而為。
