在我们开发一个大型代码项目的时候，总是会遇到下面这种头疼情况：
小王是一家公司的测试开发人员，领导要求他开发一个可以支持A端自动化测试的测试平台。
于是小王很快便搞定了这个自动化平台，只是代码中的很多变量，命名都是如下：
比如
进入脚本列表的url：/scriptList/
进入环境变量设置页面的url：/set_A_Detail/
进入元素库的url：/objects_A/
项目库表名：DB_Project
...
这种命名乍一看没有什么问题，直到有一天，领导要求小王在这个自动化平台上新增B端的自动化业务。
小王打开代码一看，傻眼了，因为之前的这些A端代码变量命名并不规范，有的直接用了公共名，有的中间包含A，后缀A... 如果增加了B端业务，那么B端要怎么命名才能不冲突呢？
小王想过重构更改A端整个代码，把所有变量命名全部规范，不过这样做的代价太大了，bug一定很多，甚至让本来没问题的A端瘫痪；如果B端直接取新名呢？比如项目库表名叫DB_Objects? 到时候别人一看，谁能知道 DB_Project是A端的表，DB_Objects是B端表？；如果全部按照一个规则，就是都增加后缀_B呢？那也看起来怪怪的，难道/set_A_Detail/ 要改为 /set_A_Detail_B/ ? 这显然也是不对的，总之，按照单一的规则已经行不通了。
事已至此，多说无益，要怪就只能怪一开始的时候，没想到这个平台要承担多端的业务，以为只有A端，于是命名就没有太严格。
于是，小王苦思冥想终于想到了一个好办法：既然没有条件重构，再考虑到今后可能会有C,D,E等等端业务，那就可以创建一个新功能的命名修改规范即可。
规范中对各种情况名称做了严格的要求：
1. 旧名不包含端名的，比如/scriptList/ ，DB_Project ，新功能要全部后缀端名，变为：/scriptList_B/ ，DB_Project_B ，以后只要看到没有后缀的，就可以认定为最早的A端业务代码。
2. 旧名中包含端名的，比如/set_A_Detail/ ，/objects_A/ ，全部把端名进行更改，位置和大小写不变，变为：/set_B_Detail/ ，/objects_B/ 。
这样，在庞大的代码项目开发后，严格按照这个复合规则去改名，直到最终上线都没有出现bug。大大加快了研发新功能速度。
比如你A后端的scriptList，复制代码为新功能后，B后端按照规则就改为scriptList_B。然后写到B前端的时候，你忘记了B后端的名称，找起来太麻烦，直接看看A前端的复制粘贴的代码是scriptList接口调用，那按照规则，B后端就一定是scriptList_B，直接改就行，而不需要去查B后端了。
好，本节分享到此结束，祝大家吸收哦~
