王淮经验谈:我的码农原则

本文由前Facebook首位中国籍研发经理王淮撰写,分享了他在编写代码及进行代码审查时遵循的原则,强调了正确性和可读性的重要性,并提出了具体的实践建议。
摘要:王淮是Facebook第二位中国籍工程师,也是第一位中国籍研发经理,他一手开创了Facebook的支付安全和客服工具领域。2011年他离开Facebook,回国成为天使投资人。本文是王淮以前写代码和做代码审查时候的一些原则,供大家借鉴。

作者王淮分享了在写代码和做代码审查时候的一些原则,供大家学习与参考。

正确性(Correctness)

正确性是第一要求。不能解决问题的代码是耍流氓。

第一步,结构体现逻辑。第二步;需要什么数据,需要做什么处理,处理完了结果到那里去,都应该在结构中被很好的体现出来。

结构体现设计。设计一定要清晰。我的经验来看,一般来说,在design chart上面的每个component都对应着自己的class,然后之间或class内部的通信通过member function来完成。

一个可借鉴的做法——在一个大的feature implementation过程中,给出第一个diff的时候,可以只把结构当做一个diff,里面的函数可以是空的(place holder)。

把数据的生成和界面的展示分开来。典型的可以按照MVC的模式来,但也可以只把数据和UI分开来的比较轻量级的做法。结构应当是diff review时候最最关注的地方。最需要问的问题就是“这个diff号称要解决的问题被正确解决了吗?”

不论你是在正确还是有错误的时候。通过(相对)公证的test来1)减少自己被绕到代码里的几率;2)让后续的或者别人的改动对自己代码不经意的破坏被最快的展现出来。

test应该把class主要的function都测一遍

test也应该把class和其他class最重要的integration也测一遍。

可读性(Readability)

diff的大小

bug修改,无所谓,该多大多大。一般bug fix不会超过100行。超过的要特别重视,想想究竟是什么原因造成。会不会是当初设计的问题。

一个diff,原则上不应该超过200-300行修改。但多了怎么办,把一个diff变成多个–split to multiple changes.

每diff应该只做一件事情

每个diff尽可少的做一个改动。这样可以尽可能的方便自己的管理(学会用 git branch),和方便reviewer的代码审查。如果diff越集中做一件事,审查代码的人需要越短的时间来审查做出高质量的,整体效率越高。

一个function超过1屏=>split it, idiot.

统一的代码规范

比如文件名,变量或函数名的命名规范,分行的前置空2个spaces或4个;每行的字数(不应超过80char);如何使用public/private/protected;用左右括号的原则;空行的使用;文件和代码comments的位置(比如,代码comment只能单独成行);对“//TODO:”的使用规范;macro,constant的使用;

等等等等。

这里没有特别的哪一种style一定更对,但是需要有一个大家统一的guideline,一起遵守,让整体的代码有统一的风格和标准。

最大的好处就是有利于readability.

object-oriented v.s function-oriented

Java本身就是面向对象,所以这个问题不大。但千万不要出现披着面向对象的外皮,在class里面写超长的面向函数的处理。这种情况下,尽可能的分流成helper function.

crispy & sufficient的注释

注释应当简洁但充分。有些人觉得代码应该speak for itself。我不大同意,代码是实现细节,适当的在意图上给予说明,可以大幅度的减少读代码的人的烦恼。

diff发出去之前

与master做一次merge update,确保resolve all conflicts

run一次所有涉及的test cases(需要工具)

考虑最可能做reviewer的人,可以是团队伙伴,也可以是修改涉及到的源代码owner。但必须是关心该改动或和改动相关的人。

所有的manager应当自动subscribe自己的团队里所有人的diff requests (做好filtering,但你不一定要看)

code-review之中应该做的

作为reviewer,一定要读懂diff;所有被 accept的diff必须是在读懂的前提下。做reviewer 的人要有“将来如果这些代码线上出问题,我要帮助 support”的心理准备。

code review应该被每个engineer当做工作的重要一部分。做Performance Review 的时候应该把帮助做过的code review考虑,for both employee & manager.

应当在24小时内给回复,这应当变成共识。

感觉有问题的代码,一定要在相应的行上做出评论(inline comments),以让作者明白问题所在。

尽可能把对修改的所有意见一次性给出,减少来来回回的次数。比较复杂的建议reviewer 主动找author来进行线下沟通,达成一致。

一般的diff,来回次数不宜超过3次;如果超过3次,想想看,是不是diff太大,太复杂了。

check-in之前应该做的

与master做一次merge update,确保没有问题

run一次code change涉及到的所有test cases(包括新增的和涉及到的 test cases)

原文出自:王淮

标题基于SpringBoot的马术俱乐部管理系统设计与实现AI更换标题第1章引言介绍马术俱乐部管理系统的研究背景、意义、国内外研究现状、论文方法及创新点。1.1研究背景与意义阐述马术俱乐部管理系统对提升俱乐部管理效率的重要性。1.2国内外研究现状分析国内外马术俱乐部管理系统的发展现状及存在的问题。1.3研究方法以及创新点概述本文采用的研究方法,包括SpringBoot框架的应用,以及系统的创新点。第2章相关理论总结和评述与马术俱乐部管理系统相关的现有理论。2.1SpringBoot框架理论介绍SpringBoot框架的基本原理、特点及其在Web开发中的应用。2.2数据库设计理论阐述数据库设计的基本原则、方法以及在管理系统中的应用。2.3马术俱乐部管理理论概述马术俱乐部管理的基本理论,包括会员管理、课程安排等。第3章系统设计详细描述马术俱乐部管理系统的设计方案,包括架构设计、功能模块设计等。3.1系统架构设计给出系统的整体架构,包括前端、后端和数据库的交互方式。3.2功能模块设计详细介绍系统的各个功能模块,如会员管理、课程管理、预约管理等。3.3数据库设计阐述数据库的设计方案,包括表结构、字段设计以及数据关系。第4章系统实现介绍马术俱乐部管理系统的实现过程,包括开发环境、编码实现等。4.1开发环境搭建介绍系统开发所需的环境,包括操作系统、开发工具等。4.2编码实现详细介绍系统各个功能模块的编码实现过程。4.3系统测试与调试阐述系统的测试方法、测试用例以及调试过程。第5章系统应用与分析呈现马术俱乐部管理系统的应用效果,并进行性能分析。5.1系统应用情况介绍系统在马术俱乐部中的实际应用情况。5.2系统性能分析从响应时间、并发处理能力等方面对系统性能进行分析。5.3用户反馈与改进收集用户反馈,提出系统改进建议。第6章结论与展望总结马术俱乐部管理系统的设计与实现成果,并展望未来的研究
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值