一.Design Review

详解

翻译为设计评审,也就是对需求设计进行审核,防止出现异常问题,例如下面的这些

可用性

• 外部依赖有哪些?如果这些外部依赖崩溃了我们有什么处理措施?
• 我们SLA是什么?主要是指可用性目标几个9? 50/90/99分位数的响应时间是多少? QPS是多少?
• 我们的超时、重试、过载保护、服务降级机制是什么?如何避免雪崩
• 我们的调用方有哪些?分别有什么服务配额?是否需要对关键的服务调用方单独部署?

运维

• 我们都有配置了哪些监控?如果出现问题,我们需要查看哪些信息?这些信息是否都有记录?
• 报警的处理流程是什么?
• 系统上线流程和步骤是什么,出了问题后是否可以回滚,以及怎么回滚?

安全

• XSS,CSRF,SQL注入这些是否需要处理?
• 3防怎么搞:防抓,防DDOS,防恶意访问
• 是否有请安全团队review
• 是否有风控的需求?
• 信息存储时是否设计到密码,信用卡,身份证等敏感信息,这些信息是怎么存储和访问的?
• 系统是否符合公司的安全规范(SSO, 接口认证)?关键业务操作是否可审计(可回溯谁在什么时间干了什么操作)

扩展性

• 分层,分模块怎么拆分比较合理?拆分出来的模块可以搞成服务单独部署吗?
• 应用层可以水平扩展吗?有用session吗?可以去掉session吗?
• 如果系统的负载提升到以前的3到10倍,当前系统是否依然可用
• 存储层面如果需要扩展存储怎么做?
• 系统中有哪些上下依赖的节点/系统/服务?这些依赖是否会导致无法并行开发?能否去掉这些依赖?
• 是否有数据访问API? 数据API的设计对性能的考虑是什么?数据API对异常数据(超大数据集、空数据集、错误数据、schema异常...)的处理是什么?

存储

• 数据计划怎么存储?会有可能的性能瓶颈吗?需要考虑一些缓存方案吗?
• 有什么复杂SQL可能会导致慢查询吗?
• 数据库的操作什么地方用了事务?什么情况会导致锁竞争?我们的锁策略是什么?一致性和可用性如何平衡?未来如果分库分表会有什么影响?
• 缓存失效会有什么影响?缓存大量失效会有什么影响?冷启动有问题吗?有热点数据吗?多个缓存节点需要权衡可用性和一致性吗?
• 存储时,是否需要分库,分表,选择的理由是什么?

技术选型

• 开发语言是什么,框架是什么为什么用他们?
• 缓存用什么(tair/medis/redis/memached),web server用什么?(nginx+php fpm, apach php扩展,jetty,tomcat,jboss),消息队列用什么(rebbitmq/beanstalk/kafka/mafka)?为什么用它们?
• DB是否可以用、以及用哪种no sql(hbase, tair)来优化?
• 业界或者其他团队是否有处理过类似问题?他们是怎么处理的?是否可以copy或者借鉴?

服务调用和服务治理

• 请求同步处理还是异步队列处理比较好?
• 服务接口的URI设计合理吗?可以向下兼容吗?
• 服务间的调用协议是什么?有公司标准的调用协议可以用吗?
• 客户端和服务端的调用协议是什么?有公司标准的调用协议可以用吗?
• 有什么服务治理相关的要考虑的吗?
• 能否接入otco或者sg做服务治理?

业务监控

• 正常的业务逻辑外,可能会有哪些奇葩或者恶意的操作?我们应该怎么处理?
• 除了系统上的监控外,需要什么业务维度的监控吗?
• log是怎么记的?如果要debug能有什么开关迅速打开吗?log怎么rotate?log会影响性能吗?

复用

• 项目中有用什么新技术吗?为什么要用新技术?未来其他人接手容易吗?
• 项目中有什么复杂计算的地方吗?这些计算可以用什么算法优化吗?
• 这个项目可以抽象出来什么可以复用的东西吗?
• 项目中的什么可以不用自己做,调用现成服务吗?

推荐方法

根据需求我们需要给出实现方案,如Db 表设计,消息队列设计,代码组织,模块划分,单元测试等等,这是我目前了解到的,我开发的时候还没有做到这么细,也是自己后面努力的方向。

设计好方案以后需要思考是否可以满足我们这次开发的业务需求:

• 功能是否完善
• QPS是否合格,当然这个是在我们项目对性能有要求的前提下
• 线上出了问题是否方面定位和分析
• 使用是否好用

给出设计方案以后,我们可以思考一下,然后隔一天自己Review一下,如果自己觉得没有什么大的问题的时候,请团队内的同事或者产品经理帮忙Review一下自己的设计和分析,在和同事交流和分析的时候,我们往往会get到我们没有注意到的细节和问题,这也就是Design Review 的重要性了,根据我们讨论和分析得到的问题,给出解决方法和方案,然后再Review一下,如果没有问题,我们接下来就可以进入开发阶段了。

在Design Review的过程中帮我们暴露了我们没有考虑到的问题,提前解决总比我们开发到一半才发现自己的设计有问题,需要重新设计要好的多。同时,不要害怕被指出问题,提早暴露问题总比线上出了问题好的多,还有要有开放和空杯的心态,和同事一起分析和解决问题是成长最快的。

二.Code Review

详解

翻译为代码审查,大白话就是在代码提交后,由管理员或几个人对提交的差异内容进行审核,一般包括如下
常规项:

1. 代码能够工作么?它有没有实现预期的功能,逻辑是否正确等。
2. 所有的代码是否简单易懂?
3. 代码符合你所遵循的编程规范么?这通常包括大括号的位置,变量名和函数名,行的长度,缩进,格式和注释。
4. 是否存在多余的或者重复的代码?
5. 代码是否尽可能的模块化了?
6. 是否有可以被替换的全局变量?
7. 是否有被注释掉的代码?
8. 循环是否设置了长度和正确的终止条件?
9. 是否有可以被库函数替代的代码?
10. 是否有可以删除的日志或调试代码?

安全:

1. 所有的数据输入是否都进行了检查(检测正确的类型,长度,格式和范围)并且进行了编码?
2. 在哪里使用了第三方工具,返回的错误是否被捕获?
3. 输出的值是否进行了检查并且编码?
4. 无效的参数值是否能够处理?

文档:

1. 是否有注释,并且描述了代码的意图?
2. 所有的函数都有注释吗?
3. 对非常规行为和边界情况处理是否有描述?
4. 第三方库的使用和函数是否有文档?
5. 数据结构和计量单位是否进行了解释?
6. 是否有未完成的代码?如果是的话,是不是应该移除,或者用合适的标记进行标记比如‘TODO’?

测试:

1. 代码是否可以测试?比如,不要添加太多的或是隐藏的依赖关系,不能够初始化对象,测试框架可以使用方法等。
2. 是否存在测试,它们是否可以被理解?比如,至少达到你满意的代码覆盖(code coverage)。
3. 单元测试是否真正的测试了代码是否可以完成预期的功能?
4. 是否检查了数组的“越界“错误?
5. 是否有可以被已经存在的API所替代的测试代码?

推荐方法

Code Review的目的除了提高代码质量,提前发现bug外,还包括统一团队的代码规范,比如经常会碰到有人说你这个变量命名不对,或者这里缩进不应该用tab,甚至这里应当多加一个空白行。而类似架构或者设计模式这样的“大”问题,我个人觉得并不适合在code review的时候去讨论。如果这方面有问题,那说明之前design review没有做好或者有可能根本没有做design review。

像我软内部,我所知道的范围内所有代码都是需要code review的。具体的规则可能每个部门各不相同,比如有的部门给每个组件规定几个owner,改到那块代码必须找至少一个owner做review。有的部门还规定每次code review至少要有一个senior级别以上的码农参与,等等。

从工具上来说,现在的码农还是比较幸福的了。n年以前做code review,就是自己做个bbpack发到邮件上,其实就是一个diff,reviewer就看着windiff,有意见的就拿个小本本记下来:某某行号,某某问题,然后email沟通。

后来车库计划(利用员工闲暇时间随便做点什么的一个计划)里面有人做了一个新的code review工具,叫CodeFlow,极大改善了我们做code review的体验,病毒式地传播到了公司各个部门,可以算是车库计划最成功的项目了。

CodeFlow主要把code review的过程做成了一个聊天式的体验,你对哪段code有意见,直接选取那段code然后加个comment,对方就需要对此做出回应。比如你说这个函数名字起的不够优雅,对方可以采取你的意见修改并把这个comment设置成fixed;当然他也可以认为没必要改而设成won't fix;当然你也可以继续和他撕下去。

当review的作者按照意见修改了一遍代码后,他可以发出一个新的iteration(迭代),然后reviewer们在新的iteration基础上可以再次提出新的意见。

最后每个reviewer可以设置此次review的状态,比如reviewing(正在review),或者waiting(在等作者修改),设成signed off就表示通过了。

总的来说大家对CodeFlow还是挺满意的,它的功能现在基本上都在Visual Studio里面整合了,其他答案也已经有人提到Visual Studio的code review功能了。

经验

code review这事儿,与具体的项目以及人员息息相关。人多真的力量大么?其实不尽然。

就我所知道的范围,比较硬核(强制性)的code review基本上都是发生在一个软件产品的后半段。也就是,软件自身已经成型了,甚至是已经交付了,后续的维护以及版本升级阶段。

如果是从零构建一个全新的软件,以我个人的经验来说,大部分情况下不会也不应该enforce(强制)很hardcore(重量级的)code review,因为那是在浪费时间和精力。为啥?因为在软件还未成型的时候,需求往往也是没有完全理清楚的,每个人理解都不同。一群同床异梦的人聚在一起review,往往最后是一群乌合之众。对于这种情况,我个人是倾向于仰仗个人的(也就是靠大牛)。当然,规模大的话也需要一个团队,适当的review需要,但是不是那种一二三四五死板板的做法,主要是团队leader检查实际的实现是否达到预设要求,我管这种叫单向的review,简单来说,水平好的review差的,大牛的代码大牛自己review即可。

不管是项目前期还是后期,要多构建自动化测试,多构建测试用例。前期因为项目需求不确定,测试难以割裂出来交给专门的团队,这时主要是代码编写者自己写测试代码自测。项目定型之后,就可以也应该组建专门的QA团队负责这个事情了。

其实对于大项目,理想上最牛的码农应该都是QA,并且在项目的初期就介入,进行白盒测试(也就是code review)。但是事实上能做到的应该不多。因为实际的软件开发很多都是需求变来变去,设计和编码是交错在一起的,多大的项目最终落实到个人头上都是一人多角色,即是运动员也是裁判。虽然从软件工程和项目管理角度这样很不好,但是确实是普遍存在。

当然诸如下面许多回答答主所在的软件巨头的成熟产品团队,自然是另外一番景象。我写这个回答的目的只是表达那只是事实的一部分,而且很可能是一小部分。

本文版权归作者所有,欢迎转载,请务必添加原文链接。