代码评审

值得学习的C语言开源项目 - 1. Webbench Webbench是一个在linux下使用的非常简单的网站压测工具。它使用fork()模拟多个客户端同时访问我们设定的URL，测试网站在压力下工作的性能，最多可以模拟3万个并发连接去测试网站的负载能力。Webbench使用C语言编写, 代码实在太简洁，源码加起来不到600行。 下载链接： http://home.tiscali.cz/~cz210552/webbench.html - 2. Tinyhttpd tinyhttpd是一个超轻量型Http Server，使用C语言开发，全部代码只有502行(包括注释)，附带一个简单的Client，可以通过阅读这段代码理解一个 Http Server 的本质。 下载链接： http://sourceforge.net/projects/tinyhttpd/ - 3. cJSON cJSON是C语言中的一个JSON编解码器，非常轻量级，C文件只有500多行，速度也非常理想。 cJSON也存在几个弱点，虽然功能不是非常强大，但cJSON的小身板和速度是最值得赞赏的。其代码被非常好地维护着，结构也简单易懂，可以作为一个非常好的C语言项目进行学习。 项目主页: http://sourceforge.net/projects/cjson/ - 4. CMockery

原文链接： https://www.cnblogs.com/ftl1012/p/javaCode.html 编码规范 1 前言 为确保系统源程序可读性，从而增强系统可维护性，java编程人员应具有基本类似的编程风格，兹制定下述Java编程规范，以规范系统Java部分编程。系统继承的其它资源中的源程序也应按此规范作相应修改。 2 适用范围 本文档将作为java编程人员软件开发的编程格式规范。在项目Java部分的编码、测试及维护过程中，要求严格遵守。 3 命名规范 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。 3.1 Package 的命名 Package 的名字应该都是由一个小写单词组成。示例：unipost.trans 3.2 Class 的命名 Class 的名字每个单词必须由大写字母开头而其他字母都小写的单词组成。示例：FileMng 3.3 Class 成员的命名 变量、方法、属性：大小写混排的单词组成，首字母小写 示例： functionName、countNum、size 3.4 Static Final 变量的命名 Static Final常量：大写单词组成，单词之间使用“_”连接 示例： MAX_INDEX 3.5 前后台变量名称 前台变量 fg_变量名 后台变量 bg_变量名 3.6 参数的命名

单元测试过程 定义：单元测试是对软件 基础组成单元 进行的测试 时机：一般在 代码完成后由开发人员完成 ，QA人员辅助 对象：类、模块、组件、单元 单元测试 单元测试的依据是软件的 详细设计描述、源程序清单、编码标准 等。 单元测试一般应该由编程人员完成，有时测试人员也加入进来，但编程人员扔会起到主要作用。 多个被测试模块之间的单元测试可同时进行，以提高单元测试效率。 单元测试是对软件组成的基本单元测试。 在传统的结构化编程语言如c语言中，单元一般是模块，也就是函数或子过程。 在象c++中，单元是类和类的方法 在Ada语言中，单元可为独立的过程、函数或Ada包 在第四代语言（4GL）中，单元对应为一个菜单或显示界面。 单元测试的目的 验证 代码 是否达到详细设计的预期要求（概要设计->集成测试） 发现代码中不符合 编码规范 的地方 准确定位发现的错误，以便排除错误 单元测试的优点 单元测试在编码过程中（在所有测试前），若发现一个错误，不论是从做回归测试的角度，还是对错误原因理解的深刻性的角度，修复错误的成本远小于集成测试阶段，更小于系统测试阶段（ 效益更优 ） 在编码过程中考虑单元测试的问题，有助于编程人员养成更良好的 编程习惯 （ 规范 ），提高源代码质量 单元测试的步骤 实施应遵循一定的步骤。 计划 单元测试 设计 单元测试 实现 单元测试 执行 单元测试 结果分析并提交

1：如果调用的方法返回值是基本数据类型，接收返回值的变量如果不是必须用包装类，请不要使用包装类进行接收，同理：在一个方法内return基本数据类型，方法返回值不要写包装类。 2：方法的参数列表中，如果包含可以为空的入参，请将该参数往后放，把主要的参数放在前面。 3：方法入参进行不要用id、code、name等过于简单的描述，应该用patientId，centerUserId，patientCode等，如果用前者必须写注释 4：一个方法内get()获取一个属性时，重复2次以上一律提成一个变量 ，不要在多处重复调用get方法 5：DTO或者VO只用于数据传输，不要作为入参进入方法内，以这个方法为例， 方法内使用了仅recordDTO的recordId和recordParamList，该方法的参数列表就应该只有这（recordId，recordParamList），这里的思想是：入参是函数体的目录，需要让人一眼就能看到包含什么，除非必要情况，尽量不要传对象，特别的大对象 6：进行修改操作的接口一定要先校验合法性，看该记录可不可以被修改，甚至修改人有没有修改记录的资格（token只能保证用户本身是合法的，不能保证他的行为） 7：引入第三方类库时不要引入不用版本的相同内容，要在import中修改统一的版本，尽量不要在代码段落中书写完整的路径 8：循环超过2层时考虑重构、

Git 作为一个源码管理系统，不可避免涉及到多人协作。 协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。”工作流程”在英语里，叫做”workflow”或者”flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 本文介绍三种广泛使用的工作流程： Git flow Github flow Gitlab flow 如果你对Git还不是很熟悉，可以先阅读下面的文章。 《Git 使用规范流程》 《常用 Git 命令清单》 《Git 远程操作详解》 一、功能驱动 本文的三种工作流程，有一个共同点：都采用”功能驱动式开发”（Feature-driven development，简称FDD）。 它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。 二、Git flow 最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。 2.1 特点 它最主要的特点有两个。 首先，项目存在两个长期分支。 主分支master 开发分支develop 前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。 其次，项目存在三种短期分支。 功能分支（feature

CICD核心概念 CICD是持续集成（continuous integration，CI），持续交付（continuous delivery，CD），持续部署（continuous Deployment，CD）的简称。 指在开发过程中自动执行一系列脚本来减低开发引入bug的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。 1，持续集成 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处有两个： 1）快速发现错误：每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 2）防止分支大幅偏离主干：如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的： 让产品可以快速迭代同时还能保持高质量，它的核心措施是：代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。 Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" 2， 持续交付 持续交付指的是频繁的将软件的新版本交付给质量团队或用户，以供评审，如果评审通过，代码就进入生产阶段。 持续交付可以看作是持续集成的下一步，强调的是，不管怎样更新，软件是随时随地可以交付的。 3，持续部署 持续部署是持续交付的下一步，指的是代码通过评审之后，自动部署到生产环境。 持续部署的目标是：代码在任何时候都是可以部署的

使用 Swift 进行软件开发的最佳实践. 本文档的 英文版在这里 ,感谢 Swift社区 (频道为 #bestpractices )为我们提供如此优质的文档。 前言 这个文档的产生得益于我在创作 Swift Graphics 时做的一系列的手记。本指南中的大部分建议也考量了是否可以为其它的观点和论点。当然，感觉其他的方法必须存在时除外。 这些最佳实践没有规定或推荐 Swift 是否应该在一个程序上以面向对象的或者函数式的方式来使用。 本文档更多的是关注 Swift 语言及其标准库。也就是说，以一个纯粹的 Swift 的角度提供可提供的关于在 Mac OS, iOS, WatchOS 和 TVOS 上如何使用 Swift 的具体建议。 同时也会提供一些如何在 Xcode 和 LLDB中有效利用 Swift 的提示和技巧。 这项工作正在进行中，非常欢迎大家通过 Pull Request 或 Issues 的方式来贡献内容。 你也可以在 Swift-Lang slack (位于 #bestpractices 频道) 上参与讨论。 贡献者注意事项 请确保所有的例程是可运行的 (这可能不适用于现有的例程)。这个 markdown 文件会转化成一个 Mac OS X 的 playground. 黄金法则 Apple 通常是对的。应紧随苹果所推荐的或他的 Demo 中所展示的方式

2017年12月13日记录 今天是小组开始讨论白盒测试实践作业的第六天。下表展示了目前作业的完成情况： 阶段一：熟悉白盒测试方法 孙宁、郎绪文 阶段二：熟悉代码复审的过程　 （会议总结）陈立 阶段三：熟悉静态代码检查工具　 张田晖 阶段四：熟悉基于Junit的单元测试脚本开发　 张田晖 　　　　　　　　　　　　　　　　　　　　　　　　　　　表一：本次小组作业要求及完成情况，第二列表示主要负责人 　　　　　　　　　　　　　说明：删除线表示已完成；下划线表示完成了一部分或者完成了初稿；没有任何线条标注表示尚在学习、处理中 之前的博客记录方式不好，过于大而化之，忽视了很多细节，今天进行补充说明： 本次白盒测试实践作业测试的系统是之前在黑盒测试实践中使用的商城项目。 阶段一中主要针对被测web系统（网上商城）的登录功能，生成订单功能、提交订单功能，使用了白盒测试方法中的判定覆盖和语句覆盖的方法来设计了用例。 阶段二中评审会当天记录工作不够仔细，且没有提纲挈领的写在博客中，遗忘了一些内容，给后面的评审报告的撰写造成了一些麻烦。 阶段三中使用的静态代码检查工具为阿里巴巴java编码规约的自动扫描插件。 今天的主要进展如下： (1) 陈立同学完成了评审结果报告和缺陷报告的初稿，会议纪要因为之前没有做好记录的原因撰写的内容并不够完整。评审结果报告中主要报告了商城的购物模块(com.itheima

今日小组成员任务完成情况： 小组12-9工作量 成员 今日工作 备注 郭义 未完成白盒测试文档（延期） 未完成任务(12-12日任务已完成） 杜杰 完成了代码复审方法 完成任务 侯俊 完成了 findbugs测试文档 完成任务 李嘉蕊、姜黎黎 完成缺陷报告模板 完成任务 唐伟 编写今日博客 完成任务（后期添加未完成组员的部分） 小组完成文档总览 白盒测试用例如下图 代码评审会议纪要 1、主持人（杜杰）对项目及此次会议做整体介绍。 2、小组其余成员（姜黎黎、唐伟、李嘉蕊、侯俊、郭义）根据代码评审标准，以及对代码的阅读，填写评审表。 3、主持人结合代码讲解发现的问题，每讲完一个问题，针对其展开讨论，每个问题控制在10分钟以内。 4、 主持人组织全体与会人员召开会议并记录会议过程。 评审结果报告 一、概要部分 全组人员开的代码复审会议中，首先，对项目的源码从头到尾进行复审，看代码是否符合需求和规格说明，然后检查代码是否有周全的考虑，以及代码的可读性和可维护性，经过小组成员的审核和讨论，确认该项目的代码全部符合以上要求。 二、设计规范部分 对代码进行了初步的复审后，然后小组成员开始分块对项目代码进行设计规范部分的复审。经过大家的复审，确认项目代码遵从了已知的设计模式或项目中常用的模式，没有硬编码或字符串/数字等存在，没有依赖于某一平台，不会影响将来的移植（如Win32到Win64）

申明： 因学识有限，某些见解和观点或有不妥，如有冒犯还请见谅。如需与作者联系，见文章底部个人签名处，乐于交流。 Q群：210285832，欢迎共同志趣者交流。 【前言】 百度百科上说：“代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。”这篇百科的内容好像是几年前CSDN上的一篇博文，但不管他们怎么抄，代码评审大概就是这么个意思。 代码评审，没多大点事，貌似可有可无，但不管你怎么回避，确实不能也无法做到视而不见。 【代码评审的尴尬】 最典型的介绍代码评审的开展方法就是：搞个3、5个人，什么小组长、秘书、测试人员啦，然后开会什么的。于是代码评审变成了会议，开发人员多数是技术宅、务实派，比较反感这种貌似能解决问题却往往更加添乱的口水活动，于是这事自然成了形式。借用一网友的图片，会议的初衷是好的，但往往过于理想化： 图左 - 心目中的会议是这样的（图片来自网友博客） 图右 - 实际上会议却往往是这样 一直以来，个人对代码评审非常认同，身体力行，且行之有效。虽然实际推行的范围和力度根据实际情况有所保留，但这往往是基于团队成员的意识、开发目标类型的差异而作出的裁剪。 代码评审，其实是开发人员某种程度上追求卓越的一种体现，专业与业余的区别，往往在于细节。实现同样的需求，抛去什么高瞻远瞩的词藻，Martin