Enum引发的血案,反思

前几天公司产品更新版本,更新完后不少用户反应原先保存的report的一些表在新版本打开后设置突然变了,本来选的第六个,现在打开变成第四个了。领导要求赶紧查出原因修改好,发紧急补丁。啊啊。。发紧急补丁可是影响team的performance的,年终奖要打折扣了。。

问题是很容易就查到了,那些设置是用Enum表示的,如下:

 1 public enum PeergroupRanks
 2 {
 3     VSBenchmark,
 4     VSBenchmark2,
 5     CalBenchmark,
 6     PeersBeaten,
 7     NumPeergroupBeaten,
 8     PeergroupRank,
 9     NumPeergrouprank,
10     PeergroupPercentile,
11     PeergroupDecile,
12     PeergroupQuintile,
13     PeergroupQuartile,
14 
15     PeergroupRankOfCount,
16 }

一位同事做新feature时加了上面红色的两个,由于存report的时候对于这个Enum只是简单的转成int存起来,大家都知道Enum默认是从0开始,按顺序来,原先存的第6个是PeergroupPercentile,report里存的就是数字5,新加了两个在上面后,数字5就解析成PeergroupRank了。

分析这个问题,觉得这个应该算是代码本身有漏洞,同事不小心踩到了,因为这位同事想法也不能说错,把同一个类型的放到一起,都是Benchmark,代码可读性强。

其实项目里大部分代码对Enum是有所防范的,如:

 1 public enum DisplayBenchmark
 2 {
 3     None,
 4     Benchmark1,
 5     Benchmark2,
 6     CategoryAverage,
 7     CalcBenchmarkId,
 8     CalcBenchmarkType,
 9     CalcBenchmarkCdp,
10 }
11 
12 public static class DisplayBenchmarkCode
13 {
14     const string BENCHMARK1 = "bm1";
15     const string BENCHMARK2 = "bm2";
16     const string CATEGORY = "ca";
17 
18     public static DisplayBenchmark Parse(string code)
19     {
20         switch (code)
21         {
22             case BENCHMARK1:
23                 return DisplayBenchmark.Benchmark1;
24             case BENCHMARK2:
25                 return DisplayBenchmark.Benchmark2;
26             case CATEGORY:
27                 return DisplayBenchmark.CategoryAverage;
28         }
29         return DisplayBenchmark.Benchmark1;
30     }
31 
32     public static string Convert(this DisplayBenchmark type)
33     {
34         switch (type)
35         {
36             case DisplayBenchmark.Benchmark1:
37                 return BENCHMARK1;
38             case DisplayBenchmark.Benchmark2:
39                 return BENCHMARK2;
40             case DisplayBenchmark.CategoryAverage:
41                 return CATEGORY;
42         }
43         return BENCHMARK1;
44     }
45 }

在report里存的是DsiplayBenchmarkType.Convert成的字符串,解析时再Parse,这样更安全,增加Type的同时也要增加相应的Code,一一对应。

当然,在Enum里写上具体值也是可行的,如:

1 public enum PeergroupRanks
2 {
3     VSBenchmark=0,
4     VSBenchmark2=1,
5     CalBenchmark=2,
6     PeersBeaten=3,
7 }

还有人觉得直接用const string就好,个人以为Enum的强类型还是比string好,string的可能性比较多,直接用字符串比较也行,用其他同样string的变量比较也行,没有唯一性,而Enum只能是相同的Type进行比较。

类似的问题的还有hashcode,hashcode会不会变也是依赖于.net framework的算法,谁也不能保证以后算法不会变,所以hashcode也不要做为key存起来,否则后期要改会变得很困难,因为还需要兼容以前存的档案。

另外多语言下的数字也是值得注意的,欧洲那边很多国家的小数点是用逗号表示,分隔符用点号,和我们正好相反,如: 123.456,78  ,这种情况就需要以固定格式存下来,比如ToString时用CultureInfo.InvariantCulture,这样跟区域语言无关,解析时也一样是固定格式解析,double.Parse(value, CultureInfo.InvariantCulture)。显示在界面时就需要用当前的语言格式来显示,总不能给西班牙人看我们常用的小数格式,CultureInfo.CurrentCulture这是当前线程的语言格式,用这个就可以了。

总结起来,要持久化存起来并且需要解析还原的东西是不能变的,保存前是什么状态解析后也要还原这个状态,所以Enum一定要写上值或做转换再存,同样还有hashcode,情愿存长一些的字符串也不要存hashcode(自定义的算法无所谓哈),多语言应用下的小数也需要注意保存和显示的区别。

然后就是上面看到的,同样的项目中绝大部分Enum都做了防范,小部分因为代码规范问题,没能保持一致才出了问题,所以个人觉得这些问题属于基本代码规范问题,在项目设计时就决定好了,每个人不管是老同事还是新进来的同事都需要遵守规范,这样的项目代码更安全,可持续性也更好。

规范的目标是让项目的代码看起来像是一个人写的,团队好的coding风格也会积极影响所有成员。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏haifeiWu与他朋友们的专栏

复杂业务下向Mysql导入30万条数据代码优化的踩坑记录

从毕业到现在第一次接触到超过30万条数据导入MySQL的场景(有点low),就是在顺丰公司接入我司EMM产品时需要将AD中的员工数据导入MySQL中,因此楼主负...

1204
来自专栏机器人网

技术猿 | 室外移动机器人组合的导航定位系统设计

---- 对于在室外环境工作的移动机器人通常使用惯导/卫星组合导航方式。惯性导航系统[1]具有完全自主、抗干扰强、隐蔽能力好和输出参数全面等优点,但它的鲁棒性...

2565
来自专栏Android 开发者

玩转全新的 Android 8.0 Oreo 后台策略

2544
来自专栏葡萄城控件技术团队

Visual Studio 2015速递(1)——C#6.0新特性怎么用

系列文章 Visual Studio 2015速递(1)——C#6.0新特性怎么用 Visual Studio 2015速递(2)——提升效率和质量(VS20...

1768
来自专栏CSDN技术头条

解析大型.NET ERP系统 20条数据库设计规范

数据库设计规范是个技术含量相对低的话题,只需要对标准和规范的坚持即可做到。当系统越来越庞大,严格控制数据库的设计人员,并且有一份规范书供执行参考。在程序框架中,...

2277
来自专栏世界第一语言是java

微信扫码支付、网站接入微信支付-java

8764
来自专栏WeTest质量开放平台团队的专栏

Android P专区免费开放 -- 同样的Android,不同的体验

原文链接:http://wetest.qq.com/lab/view/376.html

4743
来自专栏小樱的经验随笔

基于AOE网的关键路径的求解

【1】关键路径 在我的经验意识深处,“关键”二字一般都是指临界点。 凡事万物都遵循一个度的问题,那么存在度就会自然有临界点。 关键路径也正是研究这个临界点的问题...

4516
来自专栏腾讯IVWEB团队的专栏

那些年我们踩过的坑

没有一个程序员一开始就能写出高抽象,复用性高的代码,和一世人流流长,总会爱上几个人渣一样,程序员总会遇到各式各样的坑,关键是遇到坑之后是视若无睹还是努力学习改进...

6170
来自专栏苦逼的码农

加锁还是不加锁,这是一个问题

上次我说过, 我们这个线程的世界是个弱肉强食的地方, 大家为了争抢资源大打出手,时不时闹出些内存数据互相被覆盖的事故, 给人类带了无穷的烦恼。

1175

扫码关注云+社区