代码评审

代码评审技术 代码审查（Code Review） 是一种用来确认方案设计和代码实现的质量保证机制，它通过阅读代码来检查源代码与编码规范的符合性以及代码的质量。 代码审查的作用 检查设计的合理性 互为 Backup 分享知识、设计、技术 增加代码可读性 处理代码中的“地雷区” 缺陷检查表 Python代码分析工具 Pylint 是一个 Python 代码分析工具，它用于分析 Python 代码的错误，查找不符合代码风格标准（Pylint 默认使用的代码风格是 PEP 8）和有潜在问题的代码。 Pylint功能 检查代码风格是否符合PEP8规范 检查代码是否存在常见的错误和违反最佳实践 检查重复的代码 Pylint 安装与使用 Pylint 安装： pip install -U pylint # 安装最新版的Pylint Pylint 使用： pylint [op0ons] module_or_package_or_file # 对模块/包/文件运行pylint --rcfile= 指定检查的配置文件 --ignore= 不进行检查的文件列表 --disable= 关闭某种类型的检查 -f 报告类型, 如html 代码静态分析工具 Checkstyle： 通过对代码编码格式、命名约定、Javadoc、类设计等方面进行代码规范和风格的检查。 FindBugs： 通过检查类文件或JAR文件

一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度实现技术支撑，减少定制项目中大量更改代码、需要新增模块情况发生。此外，产品研发过程体系也需要按照业务实际时间要求变化，不要拘泥于一定要按照瀑布方式，或是敏捷方式进行管理，凡事都需要找到契合自己的方式。 【这里以一个基线产品开发过程作为流程解释基础，需要注意的是，以下说描述的各个阶段，在项目执行前要明确各个阶段的目标、指定计划、及时沟通，并确保各个时期所有成员对项目理解一致】 项目启动会 项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，目标与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候，考虑清楚自己的行动计划，怎么做才能更有效地完成目标，是每个人都要详情清楚的问题，否则，目标越是不清晰或是过高，都会影响项目的实际结果。 项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项，并将这些内容写入 PPT（最好是有固定格式和范文，让团队内部或者公司内部共同遵守规范），需要大家达成一致。对于关键角色任命，事前也需要听取相关领导和项目主要干系人的意见。 用户需求

本文转载自 https://www.cnblogs.com/zer0Black/p/9463206.html 。 我是一名项目经理，在过去的四个月里，我把一个项目带崩了（上线后频出问题，用户无法使用）。在最近的几天，我每天都在反思自己，我都在问自己以下几个问题： 1.我做错了什么？ 2.我在其中占有多重的因素？ 以下内容，我将回答以上问题，并在最后说一下我的补救措施。 项目和团队背景 首先给大家说明一下项目背景，以便各位对此项目有更清晰的了解： 1.该项目是一个二次开发项目，第一个基础版本（打印申报系统）也由我带领开发。 2.系统是需要和国家系统对接，有三条主流程。 3.需求频繁变化，由于系统需要对接国家系统，需求方对需求也不甚了解。曾在5月份一个月内需求变更超过8次，都是主流程变更。 4.项目大小按照最初需求估算，约在100人天左右。 5.项目两条主流程无法测试，依赖于外部U盾，但开发过程中并没有U盾。 6.客户现场使用U盾调试和开发时间约为20天左右。 7.我当时同时负责大大小小4个项目，没有进入开发，仅管控进度。 8.团队成员共3名，其中两名是当时开发基础版本的项目成员，他们对此项目较为熟悉。 9.项目推进过程中，需要多次去现场调试测试，由团队中的两名工程师共同前去。 我做错了什么 除了监控进度，还要管理质量 在项目的开发初期，我制定了一份详细的开发计划，用于指导整个开发过程

c++常用库 C++ 资源大全 关于 C++ 框架、库和资源的一些汇总列表，内容包括：标准库、Web应用框架、人工智能、数据库、图片处理、机器学习、日志、代码分析等。 标准库 C++标准库，包括了STL容器，算法和函数等。 C++ Standard Library：是一系列类和函数的集合，使用核心语言编写，也是C++ISO自身标准的一部分。 Standard Template Library：标准模板库 C POSIX library ： POSIX系统的C标准库规范 ISO C++ Standards Committee ：C++标准委员会 框架 C++通用框架和库 Apache C++ Standard Library：是一系列算法，容器，迭代器和其他基本组件的集合 ASL ：Adobe源代码库提供了同行的评审和可移植的C++源代码库。 Boost ：大量通用C++库的集合。 BDE ：来自于彭博资讯实验室的开发环境。 Cinder：提供专业品质创造性编码的开源开发社区。 Cxxomfort：轻量级的，只包含头文件的库，将C++ 11的一些新特性移植到C++03中。 Dlib：使用契约式编程和现代C++科技设计的通用的跨平台的C++库。 EASTL ：EA-STL公共部分 ffead-cpp ：企业应用程序开发框架 Folly：由Facebook开发和使用的开源C++库

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简介： 谷歌成立于 1998 年，以搜索起家，到目前为止已经发展了 21 年。在过去的 21 年中，谷歌不断创新，开发了七款产品，拥有超过 10 亿级活跃用户，谷歌的工程师文化一直被认为是优秀且特别的。近日，谷歌开源了其内部一直在使用的代码评审规范，看看谷歌工程师是如何评审代码的。 代码评审标准 代码评审的主要目的是确保代码库的整体质量随时间推移逐步得到提升，所有代码评审工具和过程都是为了实现这一目标而设计的。 为了实现这个目标，必须做出一系列权衡。首先，开发人员的开发任务必须要有所进展。如果他们不提交改进的代码，代码库质量就得不到改善。此外，如果评审人员过于严格，开发人员就没有动力进行持续改进。 评审人员的职责是确保每个 CL（变更列表）的质量，保证代码库整体质量不会随着时间的推移而下降。这是一项艰巨的任务，因为代码库整体质量常常会随着每次提交代码质量的小幅下降而退化，特别是有时候开发团队时间很紧，并认为必须走捷径才能完成交付任务。 评审人员要对他们评审的代码负起责任，确保代码库保持一致性和可维护性。 以下是可在代码评审中使用的准则： 一般来说，如果 CL 达到可以提升系统整体代码质量的程度，就可以让它们通过了，即使它们可能还不完美。 这是所有代码评审准则的最高原则。 当然，也有例外的时候。例如，如果 CL

为什么要重构 框架陈旧 -> SpringBoot 微服务架构，更方便划分责任田 -> 云龙等套件，便于质量管控审查 -> Redis 提升加载和相应速度 代码组织结构混乱，扩展性，可读性，健壮性都很差 -> 优化框架设计，规范普通开发人员开发出高质量代码 -> 提升代码复用率。封装工具包; 函数只包含最小逻辑 等 -> 请对自己的代码加上注释 -> （还能修复一些无从下手的BUG ^-^） 数据库设计不合理/使用华为自研数据库 （如最佳实践 引用的文档复制了多份; 回帖的匿名信息不保存;） -> 抛弃Oracle, 拥抱Gauss（其实是Postgrel） -> 重新设计数据库 重构依然存在问题 重构没有计划 我们的SE在开发上有丰富的经验，但是性格比较（乖巧？），说话比较含糊，感觉思路不是十分明确 没有明确的计划，走一步看一步（如“大家先把xxx做了，然后再看”），导致效率极低 与甲方的思路不一致，如要求出类图，但是我们都觉得没什么用，>_> 过度设计 设计应当遵守规范，保持最简单，所有开发人员一看就能明白。 不要为了设计而设计，不要添加复杂的逻辑。 重构编码管理粗放 我以为重构的编码会严格的管控起来，事实是我想错了，根本没人在意... 还是风格各异的代码，几百行的函数比比皆是 （这样有什么意思，换一批人还是骂前人代码的） 两个月后： 整个项目重构基本完成，虽经历波折

本文分别在VS2008和VS2010 With Parallel，进行了相同代码的单元测试，其中使用Parallel后，性能的提升还是比较令人满意的，示例中包含了使用Parallel(TestStrBTest()用例)和使用普通foreach的测试用例，感兴趣的同学可以下载来跑一下。 http://files.cnblogs.com/isline/TestApplication.rar 概要 单元测试是一种辅助开发的测试方法，是在开发阶段进行的，测试人员与开发人员可以分别对需要的模块进行单元测试。 单元测试的对象，在函数式变成语言中可以是过程，在OOP语言中可以是类。 类的划分与建立是否合理，是单元测试是否能顺利进行的关键，建模很大意义在上决定了单元测试的适应度。 单元测试是一种白盒与黑盒都适用的方法，与其紧密相关联的环节有代码的复审、走读、静态分析与动态分析，所以单元测试是白盒测试或灰盒测试。开发人员为主要测试实施者，进行白盒测试，测试人员进行灰盒测试。二种角色在实施单元测试时没有过多的交集，且要保持彼此的隔离。我写的是程序人员进行的白盒单元测试。 这篇文档主要为大家介绍与开发人员相关的动态分析单元测试。 单元测试是一种偏向白盒测试的方法，由于测试人员很难使用相应的语言编写单元测试用例，并对代码进行高覆盖度的测试，所以单元测试一般由程序人员本着“尽可能早”的原则完成

一 需求分析阶段 二 设计分析阶段 三 开发联调自测阶段 四 提测阶段 五 测试执行 六 上线阶段 七 运营阶段 一 需求分析阶段 1.业务修改 现有业务修改是否清晰 核心逻辑是否遗漏 有无业务冲突 2.用户体验和影响 交互是否合理 会不会拉长交易流程 干扰用户选择 下单和支付响应时长 3.周边业务线的影响 是否清晰描述上下游系统的影响 4.安全 黑白名单 反作弊 开关 规则和阈值 5.旧数据兼容 二 设计分析阶段 系统结构： 针对项目需求，结合业务现状来评估RD设计的系统修改点是否合理 模块、系统间使用了什么接口、中间件进行通讯（http、dubbo、mq、缓存、数据库、定时任务等），是否合理，例如dubbo循环依赖等 - 画出当前的系统结构图 - 标注出系统结构的改动点 数据流： 能不能拿到自己想要的数据，做出的修改是否会对现有系统造成负面影响，例如数据结构不兼容，缓存结构不兼容等 - 接口和接口字段的CUD（增、改、删） - 数据存储的变化（表、字段） 三 开发联调自测阶段 1.根据需求和设计文档进行case设计和评审（后续自动化case同步进行？） 2.测试环境准备 分支 sql ng 权限配置等 3.跨团队项目的上下游沟通 测试计划沟通 和上下游模块沟通各自负责的测试计划安排、测试范围、测试重要场景、跨团队 测试数据的构造、配合的方式，把团队间的影响降到最低。 环境对接

1、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试可以包括但不限于一下几个方面： 页面是否风格统一，美观 页面布局是否合理

代码评审有两种不同的方法，一种是代码走查，一种是代码审查，我们这里讨论的仅指代码走查。通常自己写的代码都难以发现问题，需要以第二双眼睛再次检查代码，帮助我们及时地发现潜在的问题。 做代码审查之前，团队成员间需要达成一个共识，制定一份合理的代码规范标准。以此为前提，后续再补充，否则会事倍功半,可以以下面为例： Code review 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量以及团队内部知识共享而不是以缺陷和错误来批判他人，也不需要评论，表扬或是批评；如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测 试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方） Code review 不应该成为保证代码风格和编码标准的手段，代码规范与代码优化一定要区分开，不可相提并论。首先每个程序员的提交review的代码就应该是符合规范的，属于每个人自己的事情，不应该交由团队来完成。其次，作为一个审查者，你的任务不是确保被审查的代码都采用你的编码风格，因为它不可能跟你写的一模一样，而是要确保被审查的代码的正确性。 Code review不应该仅仅只是走查，评审就完事了，还需要进行质量分析，CODING企业版产品集成了代码评审和质量分析功能。 1.