大家都经常讨论到CodeReview（以下简称CR），但是很多时候我们并不知道我们为何要去做CR，而是按照公司的相关制度规定执行。所以，我在这里先抛出一些问题：CodeReview到底能给团队带来什么？什么样的团队需要进行CodeReview活动？如何有效开展CodeReview活动？用哪种方式会比较好呢？
在一次开发团队的内部分享会中，我问了大家这个问题，我初步的总结了一下：
1、促进工程师日常代码交流和人员的成长；
2、团队营造浓厚的工程师交流氛围；
3、为产品质量进行把关等；
1、对技术追求高，技术驱动型的团队；
2、服务的范围广，涉及面也非常重要，出现质量问题影响严重的，对质量要求很高的团队；
3、测试人员缺失，或者测试环境比较弱的团队；
4、新人密集的团队；
5、任何有主动意愿的团队；
1、疲于应付的团队，项目节奏非常紧，每天淹没在需求的沟通以及变更 优化；
2、创新型的团队，需要快速的开发出产品投入市场进行验证，更加倾向与敏捷的开发；
3、领导或者核心技术骨干不认同Code Review的意义的团队；
要想在团队内部有效运作CodeReview活动，必备四要素。
1、代码规范：参考《阿里巴巴集团java开发规范》，附加项目个性化的规范，经过领导和团队的评审进行发版，形成团中的标杆，衡量好坏的依据；
2、检视指南：也就是CodeReview-Checklist，checklist有必要指出团队中非常关注的几个重要的点（性能效率、内存泄漏、死循环、异常处理等等），不求完全覆盖所有的检查项，对于核心要素必须指明，作为团队互相进行CodeReview的审查依据，并进行不断的更新；
3、总结优化：团队需要对每周的Codereview进行回顾、总结分析，持续优化，推进团队的运作，而不是指停留于形式，要找问题的本质，对于有代表性的问题，需要在每周的分享会中进行分享---这一项任务的前提是建立CodeReview的记录机制，考虑如何进行记录的整合和存档；
4、激励机制：激发团队的主观能动性，可以考虑与团队人员的绩效考核挂钩（人员评级），或者针对CodeReview记录表，评估一周质量之星或者按月（奖励书籍、徽章等）；
根据项目的实际情况，我总结了以下几点：
1、前期进行执行强制性，培养开发人员的习惯，后期再逐渐放宽；
2、对于新项目，提交的内容必定是比较新，无法实现小片段高频率的评审，建议采用每周按照功能块的评审；
对于运维项目，尽量使用小片段的对比评审；
3、事前评审，即发布前进行CodeReview，控制产品的质量，减少验收时的返工率；
4、线下频率：每周12次，每次12小时；线上：每天，固定30~45分钟；
5、项目开发小组长即Gitlab中Group的master；
总结 代码评审是一种广泛应用的软件质量提升方法。它可以检测出代码中的各种问题，但是作为一个初学课程，这篇阅读材料只提及了下面几个好代码通用的原则： 不要重复你的代码(DRY) 仅在需要的地方做注释 快速失败/报错 避免使用幻数 一个变量有且仅有一个目的 使用好的命名 避免使用全局变量 返回结果而非打印它 使用空白符提升可读性 下面把今天学的内容和我们的三个目标联系起来： 远离bug. 通常来说，代...
介绍几个轻量级代码检查工具，包括代码静态检查，整理代码等。 无论是自己一个人写代码，还是与其他人合作写代码，都希望能有一份高质量的代码，以便别人或未来的自己可读、可维护和可扩展。 于是往往我们需要代码评审（Code Review）。正式的代码评审已经有不少书籍介绍且与开发环境有关，这里只介绍几个轻量级代码检查工具，方便日常开发过程中提高自己的代码质量。 Python Pylint https://...
Code Review也就是代码评审。代码评审有两种不同的方法，一种是代码审查（比较正式），一种是代码走查（没那么正式），我们这里讨论的仅指代码走查。 之所以需要代码评审，是因为通常自己对自己写的代码都难以发现问题，因此需要以第二双眼睛再次检查代码，帮助我们及时地发现潜在的问题。 一、代码评审前的前提与准备工作 做代码评审之前，团队成员间需要达成一个共识，制定一份合理的代码规范标准。以此为前提，后...
1.查过3个表的join，改用java进行数据组装 我们经常会遇到前端查询列表，但是列表的数据存在于多个表中。一般少于三个表的话，我们就会使用jion语句来处理。但是超过3个表的话，用jion显然不是好办法。通常就会采用java来处理。 伪代码如下： 2.数据封装过多时，采用异步线程 对于第一个问题，如果一个基础列表查出来，需要封装的数据过多时，可以采用异步线程来处理封装过程。对于使用到线程池的地...
由于公司的管理、规范和项目组本身的各种因素，导致代码上一直就存在这很大的问题，几个同事的离职和新人的加入，前几天一看他们的代码，立刻吓了一跳，看来代码的问题已经迫在眉睫了，终于决定把代码审查提上日程。于是开始研究各个开源的代码审查框架，花费了两天时间，成功安装了Groogle和JCR。顺便说一声，国内的资料真少…… Groogle介绍： Gr...
翻译自：https://github.com/golang/go/wiki/CodeReviewComments 注释 注释应该是一段完整的语句 注释应该以所描述内容的名字开头，并且以句号结尾 声明空的切片 应该使用： var t []string, 而不是： t := []string{} 前者会避免内存分配，除非使用了append() 不要使用panic 对于普通的错误处理，不要使用panic...
导语 zab协议包含两个阶段崩溃恢复与消息广播，基于zookeeper 3.5.3集群启动以及ZooKeeper.setData来分别说明下两阶段的流程。 一.Index 1.1 崩溃恢复 1.2 消息广播 二.reference https://zhuanlan.zhihu.com/p/25332396 从Paxos到Zookeeper-分布式一致性原理与实践 三.下篇 REDIS 3.2.8 ...
导语 以下基于hbase1.2，目前已经出了2.0版本，2.0具体细节没跟过，但是基本思路不变，优化了offheap、AssignmentManager(不再依赖zk做state数据交换，感觉这个思路有点像kafka的GroupCoordinator的思路，启动另一个管理节点，然后通过接口将结果分发到各工作节点，而尽量只用zk做小范围的一致性协调，减小数据写入，毕竟zk的写入吞吐量有限)等优化 一...
导语 Kafka 0.10.0还未实现Exactly-Once[1]，consume虽然可以基于事务实现Exactly-Once，但是produce流程如果ack阶段丢失响应依然会造成日志重复，所以本版本的实现Exactly-Once的方式还是建议采用消费端做幂等来实现。 一.Index 1.1 Produce流程 1.2 Consume流程 1.3 Replicas机制 二.reference ...
导语 YARN 2.6.0 版本还未支持GPU,且未启用DRF的DominantResourceCalculator的情况下，默认的DefaultResourceCalculator只是基于Memory来切割分配Container。 一.各组件间通信协议 框架层协议 应用层协议 二.on-yarn-app生命周期 Client请求RM获取AM_ID,然后封装ApplicationSubmissio...