探讨前端代码Review
产品发展越快,对代码的管理也就需要越严格。通常代码在进入QA测试环节前就要进行代码review。review的目的倒不是为了发现bug,主要是为了避免代码设计上的缺陷和保证代码的可维护性。当然还有针对性的review比如安全性、性能、易用性等等。代码review除了可以提高代码的品质外,还能加强团队的协作精神,以及提高团队的整体技术能力。显然这是一件非常有意义的事。
前端代码更需要review。对于本身就不严谨的前端开发语言(html/css/javascript)来说,规范性尤为重要。常常因为各种原因凑合,最后注定要花费更大的代价挽救。也许做好这件事最大的阻碍是时间,活都干不完,哪有时间review。大家对review如果有消极或抵触情绪,review的意义会大打折扣。实际情况如果不能保证上线前所有代码都经过review,即便强制通过工具做到,也会流于形式,反倒丧失原本的意义。
重新调整前端代码review的目的:
1. 落实规范。代码风格的一致性是保证代码可维护性的基础。为此针对代码风格会出台一系列Guidelines,人review和机器review(如jslint等工具)结合是落实规范的有力保证。在制订这些规范时,要考虑它在这方面的操作性。参考http://bit.ly/douban-css, http://bit.ly/douban-javascript。
2. 教育意义。review的过程也是相互学习的过程。大到使用某种新技术,小到一行代码的写法,从中都可以学到东西。从这个方面来说,即便上线前没时间review,上线后能够总结收获和经验,对其他人起到某种教育意义这样的review也是很有价值的。
3. 荣誉感。对于工程师来说,这是比奖金更强的动力。众目睽睽下一段丑陋的代码被别人指出来是多么尴尬的事情。同时,要为一周一次的代码review准备足够的可讨论的changeset。世界上没有甘愿平庸的工程师。
4. 发现问题和积累成果。如果没有代码review,在每周的周会上也可以讨论这些问题。但泛泛而谈远没有看着具体代码来的真切。所以我们废除周会改成周期性的代码review。
5. 促进团队协作。周期性的代码评审会也是某种意义的交流会,大家可以了解彼此在做的事情,哪些可以解决自己的问题,或是我做的正好可以帮到别人。review的内容不局限于产品代码,也可以是一个跟具体产品无关的基础类库。
当然,也可以利用工具,对上线前代码做强制审核,未通过的不能上线。但这样容易流于形式。我还是觉得面对面的review更好。
做好代码review需要注意的问题:
1. 规模。人数5、6人为佳,人太多,时间拖得太长,越到后面效果越差。
2. 时间。最多不超过1个半小时,最好控制在1个小时内。
3. 代码量。400-600行代码之间。越多发现的问题就会越少。
4. 形式。提前将要review的代码链接、changeset链接准备好。找个会议室,集体看投影,或带上各自电脑。每个人轮流讲自己的部分。放点音乐活跃一下气氛也不错
5. 简要介绍应用场景。更多还是针对代码本身,诸如为什么做这些改动,删掉原来的代码解决什么问题,代码写法上有什么问题,用到哪些技巧性的东西等等。介绍完之后,留出一定提问的时间。
参考了:http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review
前端代码review我们也是在不断的尝试中。向后端工程师借鉴经验。重要是明确它的目的,不让它流于形式,真正起到积极的作用。
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:kejun 来源: Kejun's Blog
- 标签: Review
- 发布时间:2011-01-29 22:38:58
- [55] IOS安全–浅谈关于IOS加固的几种方法
- [53] android 开发入门
- [52] 如何拿下简短的域名
- [52] 图书馆的世界纪录
- [50] Oracle MTS模式下 进程地址与会话信
- [50] Go Reflect 性能
- [48] 【社会化设计】自我(self)部分――欢迎区
- [47] 读书笔记-壹百度:百度十年千倍的29条法则
- [36] 程序员技术练级攻略
- [27] 视觉调整-设计师 vs. 逻辑