代码评审

Code Review最佳实践 原文链接 : Code Review Best Practices 原文作者 : Kevin London 译文出自 : 开发技术前线 www.devtf.cn 译者 : ayyb1988 校对者: chaossss 状态 : 完成 在Wiredrive上，我们做了很多的Code Review。在此之前我从来没有做过，这对于我来说是一个全新的体验，下面来总结一下在Code Review中做的事情以及说说Code Review的最好方式。 简单的说，Code Review是开发者之间讨论修改代码来解决问题的过程。很多文章谈论了Code Review的诸多好处，包括知识共享，代码的质量，开发者的成长，却很少讨论审查什么、如何审查。 审查的内容 体系结构和代码设计 单一职责原则： 一个类有且只能一个职责。我通常使用这个原则去衡量，如果我们必须使用“和”来描述一个方法做的事情，这可能在抽象层上出了问题。 开闭原则 对于面向对象的语言，对象在可扩展方面开放、对在修改方面关闭。如果我们需要添加另外的内容会怎样？ 代码复用：根据 “三振法” ,如果代码被复制一次，虽然不喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。 换位考虑 ，如果换位考虑，这行代码是否有问题？用这种模式是否可以发现代码中的问题。 用更好的代码：

MBD模型自动代码生成开发正在汽车行业中展开，BMS和VCU很早就引入了基于模型的开发方式，将MBD引入OBC的开发具有重要意义。MBD开发相对于传统的手动代码有明显的优势： 1、代码的可视化，需求文档、模型之间的可追溯性极大的方便了工程师的沟通和评审环节 2、模型仿真，可先于硬件开发，在仿真环节可验证出逻辑上的BUG 3、代码自动生成，将产品开发的主要精力用在模型设计，减少软件BUG，将软件平台化，量产化 4、文档的自动生成，借助Matlab可自动生成报告，设计文档，Ployspace静态代码测试报告。 车载充电机OBC作为典型的ECU，打造软件的智能化ECU平台化开发，可通过以下几个方面着手实现。 一、应用程序控制策略通过MBD开发，底层驱动可以通过手工代码。 二、打造强大的智能化调试平台，通过CANoe开发调试数据库，通过CANoe可观测内部关键变量。 三、增加XCP标定功能，用结合CANoe.XCP的测量快速观察变量，加速调试过程 四、打造MCU单芯片仿真平台，在开发阶段快速通过仿真，将程序开发完毕。 五、打造UDS诊断、BootLoader实现芯片的全范围升级，永不刷死，实现OTA回滚。 六、增加网络管理，远程唤醒增加整车适配的灵活性。 OBC OBD建模概要 1、系统的输入输出，定义充电机的系统抽象 2、CC CP 电子锁 S2 充放电 使能的逻辑控制

原文 作者：Jeff Atwood Johanna Rothman是这么描述“无我编程”这个概念的： 25年前，Gerald M. Weinberg写了《程序开发心理学》。我在1977年发现了这本书，然后做了一个决定：放弃在电台做DJ的工作，打算做一个无我的软件工程师。 “无我编程”发生在开发阶段，表现为技术团队经常通过同级评审的方式来发现软件中的缺陷。目的是让所有人（包括作者）都参与寻找缺陷，而不是证明软件产品里没有缺陷。人们会交换各自手上的代码，相互进行评审，并且大家都有这样的共识：代码的原始作者会犯错误，而作为评审者，他们会找出这些错误。最后的结果是，每个人都从自己的错误以及别人的错误里有所长进。这就是“无我编程”的由来。不管我的工作做得“完美”还是“有欠缺”，“我”本人并不对正在开发中的产品负责。“我”的价值体现在尽心尽职，以及从错误中学习而付出的努力，而不是我的工作的最初成果。 把自我价值观从本职工作中分离出来是很重要的！ 这让我想起了电影《搏击俱乐部》（Fight Club）里的几句台词： 你的工作不代表你 。你的价值不在于你银行里有多少钱，也不在于你穿什么鞋，或者你钱包里的任何证件。 如果你的工作不代表你，接受别人对你工作的批评就要容易得多了！ 遗憾的是，对工作不敬业的人在这个世界上随处可见。而对于我们这些热爱编程、并且已经成为行家里手的人来说

在 2005 年的某一天，Linux 之父 Linus Torvalds 发布了他的又一个里程碑作品——Git。它的出现改变了软件开发流程，大大地提高了开发流畅度！直到现在仍十分流行，完全没有衰退的迹象。 本文不是一篇 Git 入门教程，这样的文章一搜一大把，我是要从具体实践角度，尤其是在团队协作中，阐述如何去好好地应用 Git。既然是讲在团队中的应用实践，我就尽可能地结合实际场景来讲述。 习惯养成 如果一个团队在使用 Git 时没有一些规范，那么将是一场难以醒来的噩梦！然而，规范固然重要，但更重要的是个人素质，在使用 Git 时需要自己养成良好的习惯。 提交 如何去写一个提交信息，《 Git： 教你如何在 Commit 时有话可说 》中做了很好的说明。在具体开发工作中主要需要遵守的原则就是「使每次提交都有质量」，只要坚持做到以下几点就 OK 了： 提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低； 用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方； 不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。 假如已经把代码提交了，对这次提交的内容进行检查时发现里面有个变量单词拼错了或者其他失误，只要还没有推送到远程，就有一个不被他人发觉你的疏忽的补救方法—— 首先

（“马蜂窝技术”公众号原创内容，ID: mfwtech） 一个项目从需求确定到最后上线，通常来说流程是这样的： 「测试」作为一个项目质量保证角色，在上面的整个流程中均有参与。而用例设计、项目测试环节更像测试的主场，PRD 的评审测试人员也会发表很多自己的观点，对项目的技术评审虽然测试人员也有参与，但也不如前两个环节的参与程度深。 其实，一个优秀的测试人员应该深入到项目的每一个环节中去发现问题，提出自己的观点，保证项目质量。那么要真正深入到项目实现中，测试应该怎么做呢？ 一、Review 接口定义结构 接口定义文档在测试过程是测试人员接触比较多的设计文档，尤其是与最外层面向用户的接口设计相关的部分。在参加接口文档评审、编写接口用例这些场景下，测试人员都会仔细阅读接口设计文档。 通过接口文档，可以帮助测试人员清晰了解到前端与后断是怎么交互的，每个页面哪些操作与后端存在交互，不同的接口之间是否存在关联，清楚这些可以帮助测试人员在测试过程中对出现的问题进行精准判断，确定导致问题出现的范围。 在阅读接口文档可以关注以下几个方面： 接口中定义字段是否考虑了扩展性； 字段是否必须有明确的说明；如果是代码实现需要清晰定义 NotNull/NotBlank； 字段含义是否存在歧义，字段的含义要有明确的解释； 接口是否覆盖到了所有业务场景； 返回值结构、内容是否正确；通常返回值都有固定格式规范

web应用程序测试方法和测试技术详述 1. 概述 l 随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多， 很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。 l 测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web应用的特点。 l 相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。 2. 测试方法 说明：测试方法的选择取决你的测试策略。 l 一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。 l 当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。 l 有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。 2.1 界面测试 l 现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。 l 方法上可以根据设计文档

什么是软件构建 构建的主要活动是编码和调试，但也涉及详细设计、规划构建、单元测试、集成、集成测试等其他活动。 软件构建活动中的具体任务 验证有关的基础工作已经完成，因此构建活动可以顺利进行下去； 确定如何测试所写代码； 设计并编写类（class）和子程序（routine）； 创建并命名变量和具名变量； 选择控制结构，组织语句快； 对你的代码进行单元测试和集成测试，并派出起中的错误； 评审开发团队其他成员的底层设计和代码，并让它们评审你的工作； 润饰代码，仔细进行代码的格式化和注释； 将单独开发的多个软件组件集成为一体； 调整代码，优化效率和资源。 为什么构建活动很重要 构建活动是软件开发的主要组成部分； 构建是软件开发中的核心活动； 把主要精力集中于构建，可以大大提高程序员的生产效率； 构建活动的产物——源代码——往往是对软件唯一精确的描述。需求规格书和设计文档可能过时，但源代码总是最新的。因此，源代码就必须具有尽可能高的质量。 构建活动是唯一一项确保会完成的工作。 来源： https://www.cnblogs.com/liam-ji/p/11406344.html

版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/CrankZ/article/details/81545439 概述 敏捷开发和DevOps都是一种理念。他们的理念相似，都是为了更好更快的发布产品，但又不完全相同。 而CI/CD是实现这两者理念的一种方法。 敏捷开发 前言 传统方式开发前有一份详细的开发文档，程序员照着需求直接敲代码，产品做好了直接部署上线。中间不会有人打扰，需求也不会变。 但是目前的情况是，用户需求和市场都变化太快，就算你前期用户调研的再好，计划书写的再详细，也抵不住市场的变化，说不定产品做出来，用户就不需要了。 所以为了适应市场的发展，我们必须不断提高我们的开发效率，及时跟进用户需求，缩短开发周期。在这种情况下，就有人提出了敏捷开发。 传统开发 传统开发方式的拥护者和敏捷开发方式的拥护者看待软件开发的世界观是不同的。 在传统开发的眼里，软件开发过程是确定的、可测的，只要在一开始努力收集到需要的信息并制定好计划，然后忠实的执行计划就应该可以成功。如果不成功一定是你在一开始就没有做好，没收集到必要的信息，计划做的不好或者执行不到位。然后传统开发方式就试图引入更多的流程，文档，试图让每一步都做到万无一失。 敏捷开发 而在敏捷的眼里世界可不是这样的

敏捷的世界观 有一种相当流行的软件方法学要求对一个项目分配35种不同的角色，包括架构师、设计人员、编码人员、文档管理者等。敏捷方法却背道而驰，只需一个角色：软件开发者，也就是你。项目需要什么你就做什么，你的任务就是与客户紧密协作，一起开发软件。敏捷依赖人，而不是依赖于项目的甘特图和里程表。 这大概是全栈工程师吧，哈哈哈~ 为做事而工作 恶魔：“出了问题，第一重要的是确定元凶。找到那个白痴！一旦证实了是他的错误，就可以保证这样的问题永远不会再发生了。” 在敏捷的团队中，大家的重点是做事。你应该把重点放到解决问题上，而不是指责犯错者上面纠缠。 你可以从自己先做起。如果一个开发者带着抱怨或问题来找你，你要了解具体的问题，询问他你能提供什么样的帮助。这样简单的一个行为就清晰地表明你的目的是解决问题，而不是追究责任，这样就会消除他的顾虑。你是给他们帮忙的。这样，他们会知道每次走近你的时候，你会真心帮助他们解决。他们可以来找你把问题解决了，当然还可以继续去别处求助。 如果你找人帮忙，却没有人积极响应，那么你应该主动引导对话。解释清楚你想要什么,并清晰地表明你的目的是解决问题，而不是指责他人或者进行争辩。 天使：把矛头对准解决问题的办法，而不是人。这是真正由用处的正面效应。 切身感受 勇于承认自己不知道答案，这会让人感觉放心。 一个重大的错误应当被当作是一次学习而不是指责他人的机会。

每个程序员都是从学校里走出来的，那么现实工作中和在学校里会有什么不同呢？让我们来看看三位程序员说的： 程序员A：在学校编程的时候，有着一头乌黑的秀发，现在发际线惨不忍睹； 程序员B：在学校的时候没钱觉得配不上女神，现在有钱了觉得好像并不是钱的问题？ 程序员C：在学校起码能靠帮女同学修电脑和炫技装X，现在在公司连个可以装X的对象都没有； 在学校里编程，不外乎三种情况： 一是课堂或课后作业； 二是期末考试或毕业设计； 三是课余时间参与维护的开源小项目。 开发团队要么是学校社团成员，要么是同宿舍的几位室友，大多数情况下都是一个人同时身兼数职，承包了产品经理、开发工程师、测试工程师甚至还包括美工的所有工作。 在学校里编程，只要根据老师布置下来的课题，实现主要功能，经简单测试可以运行就算及格。你可以各种花式炫技，也可以随便应付了事，因为在学校里编程最主要的目的是：能够将课堂上或者自学到的理论知识付诸实践，检验自身对于知识的掌握和运用程度。 在工作中的编程除了文首说的直观的不同当然还存在着许多深层次的不同，这些不同只有经历过的人才能明白。如果你正打算去做一名码农，以下我的总结会对你有一些作用的，具体有以下几点： 1. 工作中工具的使用呈现多样化 在工作中，需要使用公司专门要求的工具来完成编程，同时还有可能需要用到多种工具，这就需要程序员对于工具的熟练运用呈现多样性