一线大厂老司机谈大数据代码走查专题

1.什么是CR(代码走查)？

Code Review（CR）即代码评审，又名代码走查，是一种通过复查代码来提高代码质量的过程，一般体现在一个团队的开发过程中。CR要求团队成员有意识地、系统地检查彼此的代码，从而验证需求、发现错误，同时指出其中不合规范的“低质量”代码，从而提高整个团队的代码质量。一次CR可以是一次Commit，也可以是一次Merge Request。

2.为什么要CodeReview？

（1）旁观者清。对于同一段业务代码，由于看待问题的角度不同，评审者可能会比开发者更容易发现其中的问题，或是找到更有效的解决方案，共同维护团队的代码质量。提高代码质量和可维护性,可读性等。查漏补缺,发现一些潜在的问题点等。最佳实践,能够更好更快的完成任务的方法。知识分享, Review他人代码时,其实也是一个学习的过程,自己也会反思&总结。

（2）快速了解业务。理想状态下，团队中的每个人都需要对整个项目的各个部分都很熟悉，当然，在项目很大时这是不现实的。通过代码审查至少可以让每个人了解更多的业务模块，同时也能达到人员互备的目的。人员互备：通过CR，评审者也相当于参与了这次开发，相当于一种人力“备份”，当你休假或正在忙别的需求的时候，这时“备份”或许就能帮上你的忙了。

（3）开发者能够获得什么？对需求的理解得到加深。表达能力得到加强。逻辑能力得到训练。心理承受能力得到提高。

（4）评审者能够获得什么？快速上手业务需求和全局的架构。统一大家约定俗成的代码风格。优秀的设计思路和业务逻辑。

3.CodeReview的原则

（1）CR是必要的，但也需要结合团队现状。当你的团队开发任务极其紧张，再耗费一部分人力去进行CR，是不明智的。

（2）所有的代码都应被赞成。因为团队代码库的每一次改动（Change List，以下简称CL），都必定会提高当前系统的整体质量，即使这个CL并不完美。

（3）CR不应该追求完美，而应追求持续改进。要知道，没有完美的代码，只有更好的代码，“慢即是快”。

（4）CR不是挑刺，更不是证明谁的能力更强。CR是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”，仅具有指导意义。

（5）评审者也需要对这个CL负责。CR不应设置奖惩机制，即便是有，也是对评审者和开发者同时的奖励或处罚。

（6）时刻保持谦虚。无论是评审者还是开发者，都可以在CR中提升自己的能力。

（7）合理解决问题解决冲突难以达成共识时，需要面对面或者拉起更大的团队讨论，带上leader。

4.大数据代码的走查

 首先我们来看看阿里内部代码评审的内容：主要包括数据一致性检查、数据完整性检查和指标间逻辑检查。

那么，在进行code review之前的需求评审阶段，我们先要明确数据统计的详细口径是什么，下面举两个实际的需求例子。

需求1：（错误示例）统计时间内店铺内所有用户的支付订单数。问题所在：需求描述太过于简洁，没有阐述清楚数据统计的时间维度以及过滤条件，导致统计口径不清晰，要求产品明确口径。

需求2：（正确示例）某APP商家域店铺维度的离线支付金额。支持自然日、自然周、自然月。统计时间内，所有付款订单金额之和（剔除优惠促销、剔除抽奖订单）。

明确需求之后，下面详细介绍code review的一些常见关注点：

1）关联关系 & 过滤条件

l 关联表使用 outer join 还是 join，要看数据是否需要做过滤。

l 关联关系 on 字句中，左右值类型是否一致。

l 关联关系如果是1：1，那么两张表的关联键是否唯一。如果不唯一，那么关联会产生笛卡尔导致数据膨胀。

l where 条件是否正确过滤，以上述需求为例子，关注sql中是否正确剔除优惠促销、剔除抽奖订单。

2）指标的统计口径处理

数据指标的统计涉及到两个基本概念：

l 可累加指标：比如订单金额，页面流量等，可以通过数值相加来进行统计的指标，针对这类指标，sql中使用的函数一般是sum。

l 不可累加指标：比如访客数，不能通过简单相加，而是需要先去重再求和的方式进行统计，针对这类指标，sql中一般使用count(distinct )。

3）insert插入数据

是否支持重跑。等价于看插入时是否有overwrite关键字，如果没有该关键字，重跑数据（多次执行该工作流）时不会覆盖脏数据，而是增量往表插入数据，进而可能会导致最终数据统计翻倍。

插入的数据顺序和被插入表结构顺序是否完全一致。我们要保证数据字段写入顺序没有出错，否则会导致插入值错乱。