ARTS 第 12 周

阿拉伯数转罗马数、LinkedIn的高效代码审查技巧、MySQL JSON 的操作、优惠券存储问题。

Algorithm

Problem:Integer to Roman

毫无思路,看了一个简单的思路

1
2
3
4
5
6
7
public static String intToRoman(int num) {
String M[] = {"", "M", "MM", "MMM"};
String C[] = {"", "C", "CC", "CCC", "CD", "D", "DC", "DCC", "DCCC", "CM"};
String X[] = {"", "X", "XX", "XXX", "XL", "L", "LX", "LXX", "LXXX", "XC"};
String I[] = {"", "I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX"};
return M[num/1000] + C[(num%1000)/100] + X[(num%100)/10] + I[num%10];
}

Review

LinkedIn的高效代码审查技巧

理解修改原因

每次代码更改提交都应包含一个设计概述,简要说明更改背后的动机。这样避免了从源码中去推测其更改意图,提高 Code Review 的质量和速度。

给出正面反馈

在进行 Code Review 时不应是仅仅只对代码中的问题进行反馈,如果遇到优雅的代码应该指出原因,提倡大家学习。这样可以激励开发人员,有助于提高团队的编码水平。

言简意赅的 Review 注释

不管是正面还是负面的反馈,审查人的注释都应该是言简意赅的,但前提是开发人员能理解。

对提交者表示感谢

不管结果如何,对努力工作的人表示感谢,这将出培养强大、积极进取的团队。

删除无用的注释

如果你认为这个注释是无效的,请删除它。正视 Code Review,它是帮助开发提高能力的工具而不是徒增工作复杂度的琐事。

保证充分的测试

每次代码更改提交都需要强制性的完成其测试。对于一些复杂的情况或者自动测试无法覆盖到的地方,需要进行手动测试,并提供有关测试场景和输出的信息。

Code Review 文化

在进行 Code Review 时有明确的期望、示例注释、充满积极有吸引力的文化是避免冗长、耗费精力的好方法。

总之,拥有良好的 Code Review 流程有助于提高代码质量、团队学习、知识分享。当团队每个成员都意识到,我写的代码会被大家看到,就算现在随便写,在 Code Review 时,还是会被提出来返工的时候。开发人员都会尽力一次性写出更好的代码。当 Code Review 成为日常习惯,团队会每天都会收到正面的反馈,这样团队不可同日而语。

Tip

MySQL 通过 JSON_CONTAINS 判断 JSON 中是否存特定 KEY 的 JSON 对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mysql> set @j = '{"c":{"d":4}}';
mysql> SELECT JSON_CONTAINS(@j,'{}','$.c');
+------------------------------+
| JSON_CONTAINS(@j,'{}','$.c') |
+------------------------------+
| 1 |
+------------------------------+

msyql> SELECT JSON_CONTAINS(@j,'{}','$.d');
+------------------------------+
| JSON_CONTAINS(@j,'{}','$.d') |
+------------------------------+
| 0 |
+------------------------------+

提取嵌套对象中的值

1
2
3
4
5
6
mysql> SELECT JSON_EXTRACT(@j,'$.c.d');
+--------------------------+
| JSON_EXTRACT(@j,'$.c.d') |
+--------------------------+
| 4 |
+--------------------------+

Share

最近有个优惠券的需求,要求是给用户发优惠券。如果按照原来用关系表的方法来存用户优惠券信息的的话,那数据量成倍数增长。假如有 10 万用户,发 1 张优惠券就 10 万条数据,发 2 张就 20 万条数据。

我们使用了 MySQL 5.7 新加入的 JSON 类型来解决这个问题。

一个用户所有的券都存在一个 JSON 里面,格式如下:

1
2
3
4
5
6
7
8
9
10
{
"coupon_01":{
"status":0,//使用状态
"code":"12345"//优惠券券码
},
"coupon_02":{
"status":1,
"code":"12345"
}
}

以优惠券的唯一标识(我们用的优惠券主体的 CODE)作为优惠券信息 JSON 对象的 Key。这样存储的话,每次发送的优惠券只是在 JSON 中追加一个优惠券信息的 JSON 对象即可。

但是这样设计有几个问题:

  1. 同一张优惠券没有办法给同一人发多次

  2. 汇总所有优惠券使用情况比较麻烦

所以当没有这些需求的时候,可以考虑这么设计。

如果你有更好的设计或想法请告诉我一下。

(完)