ARTS 第 12 周

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

Algorithm

Problem： Integer to Roman

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

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 对象。

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 |
+------------------------------+

提取嵌套对象中的值

mysql> SELECT JSON_EXTRACT(@j,'$.c.d');
+--------------------------+
| JSON_EXTRACT(@j,'$.c.d') |
+--------------------------+
| 4                        |
+--------------------------+

Share

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

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

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

{
    "coupon_01":{
        "status":0,//使用状态
        "code":"12345"//优惠券券码
    },
    "coupon_02":{
        "status":1,
        "code":"12345"
    }
}

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

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

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

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

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

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