认识达内从这里开始

认真做教育专心促就业

与开发者反馈错误时，请想想这7点！（下）

发布：互联网
来源：互联网
时间：2017-04-26 10:27

    四.以正确方式阅读代码

    根据项目类型以及所引入变更的具体特性,我们往往可以通过多种方式实现这种变更.大家可以这样思考:当我们在查找特定错误代码片段时,通常会在头脑中完成调试流程,包括读取从输入到处理的对应代码,并根据调用顺序捋顺其逻辑.这种代码阅读方式能够帮助大家更加明确各组件间的关联及交互方式,但其它一些场景则不太适用这种方式.烟台IT培训

    自上而下阅读代码能够帮助大家了解其中的抽象含义,并弄清是否需要利用灵活代码以支持不同场景,但这往往不能让我们很快掌握代码之间依赖性的冗余或者缺失问题--因此这种作法并不可取.

    在查看不同的模块或者命名空间时,大家可以关注其子系统交互及组织方式,这能帮助大家找到那些常见的设计与架构问题,但往往会漏掉具体实现细节.

    总之,我们应确保在审查代码时从多个角度考虑问题,同时变换立场及顺序反复检查.

    五.以不会导致误解的方式进行反馈意见讨论

    作为审查人员,我们的反馈意见往往能够直接被传达至初始开发者处.另外,其中某些意见可能相当具体,而另一些则较为开放,意味着需要引入更多开发者进行广泛讨论.如果您的反馈意见单纯以大篇幅文本形式体现,那么往往很难在不引发误解的前提下顺利进行讨论.

    我个人比较喜欢GitHub及Bitbucket等服务中的评论功能.这些意见会分行清晰显示,用户能够清晰掌握其相关上下文,并针对反馈中的特定部分进行具体讨论.更重要的是,如果文件内容发生变更(这在反馈过程中非常常见),那么对之前代码的反馈会被隐藏起来,这意味着过期的反馈意见将不再被纳入代码审查流程.

    与开发者反馈代码有错误时,请想想这7点!

    GitHub目前采用的代码审查方案是,我们可以将自己的全部信息进行队列排布,将其作为审查内容的一部分进行发送,并随后进行批准或者拒绝.微软提供的TFS在线服务也采取类似的机制.这种方法非常有效,我们能够随时发现人们对代码的错误以及改进空间的留言,并在之后进行针对性修改.不过在采取这种方式时,请务必在发送前对全部评论内容进行认真审校.

    六.避免"挤牙膏"

    要尽可能提供完整的审查意见,而非像挤牙膏般发现一点问题就通知开发者进行修改.无论大家提供的是单一文本还是拆分式注释,都要尽可能一次性提供全部信息,这样开发者(也包括我们自己)才能更为充分地利用时间.对于开发者来说,到处乱窜进行代码修改绝不是什么舒适的体验,而由此产生的怨气最终都会被归结于您.

    有时候人们会通过邮件发送代码审查反馈.在这种情况下,邮件的结构就变得非常重要,因为良好的格式能让对方逐行加以回答,我们也可以在得到合理答复后将不必要的部分删去.

    七.要有礼貌

    在提交反馈意见时,千万不要抱有"这就是个错误"的心态--即使事实确实如此.请始终坚持"这里还有改进空间/这里应该加以改进"的态度; 另外,除非您百分之百确定,否则请以疑问的口吻提出意见.请记住,接受审查的对象是人而不是机器; 第二,他们已经尽可能做好这份工作了.即使出于技术、知识、经验或者时间所限而导致开发者拿出了无法接受的代码成果,也请坚信一点,他们已经为项目的推进贡献出了大量精力.

    Linus Torvalds式的粗口与责骂虽然读起来颇具趣味,但对于交流对象而言却是种很深的侮辱与伤害.另外,为什么非要给自己树敌呢?毕竟老话说得好,和气才能生财嘛.

更多烟台IT培训相关资讯,请扫描下方二维码