文档、代码审查

文档、代码目录结构

4.项目监控

5.需求管理

6.项目沟通

6.1.内部交流

6.2.与客户交流

7.配置管理

第一、文档、代码审查时的要有目的性，针对性。

文档、代码审查的根本目的是保证品质，但不能把它做为一次文档、代码审查工作的直接目标，这样的目标太泛泛，让我们在文档、代码审查工作过程中抓不住重点。

第二、文档、代码审查工作时参与的角色要合理。

参与文档、代码审查工作的人大多是技术合格，但业务不合格，这样对于一些复杂的业务逻辑问题就很难发现，从而使得这些业务逻辑问题在文档、代码审查的过程中蒙混过关。

第三、文档、代码审查工作不能过于集中，一次文档、代码审查的代码量太大。

在有限的几个小时内，面对上千行，甚至更多的代码时，再有耐心的人也难免产生视觉疲劳。

准备要充足，对于要文档、代码审查的缺少必要的审查规范和标准。在文档、代码审查过程中，我们有文档、代码编写规范，代码的设计规范、业务的逻辑规范和标准。

那么，我们应该怎样做，才能使文档、代码审查工作保质而且高效呢？一个标准的文档、代码审查工作应该分为三个阶段：

　    一、事前准备阶段

评审规范和标准：

在一次文档、代码审查前，掌握代码分析和评审技术、掌握自动化代码分析工具的使用，文档、代码审查产生成本估算，代码文档归档服务器，要懂开发的人员参与文档、代码审查，代码评审以公司内部的文档、代码标准为基础。在文档、代码审查前设计确定评审规范和标准是必要，通过规范和标准我们在审查过程中可以有据可依，有理可循，而且还可以做到标准统一。

代码评审的目的：

保证文档完善、代码质量、学习和交流，确保参照良好的编码标准，产生高质量，可维护的代码及供参考的文档资料库。

二、实施阶段。

充分的事前准备，只是做好文档、代码审查工作的前提，文档、代码评审应按照一定的流程作业，这样可以降低评审成本，提高评审效率。代码评审流程介绍如下：

1、     文档、代码评审发起。

代码评审发起要有专门负责人，负责人要控制整个评审过程。负责人负责确定评审范围、评审人、评审结果交付日期和组织召开评审会议。负责人还要编写《代码评审评审点列表》，《代码评审评审点列表》列举出代码评审过程重点检查的项目供评审人逐一检查代码。

2、     文档、代码审查的对象。

在准备文档、代码审查代码对象时，我们要注意代码的数量，如果代码量比较大，要对代码进行必要的分解，确定其中的关键代码，对关键代码进行文档、代码审查，可以达到举一反三的目的。

负责人发起代码评审。告知评审人代码的评审范围，确定被评审代码的版本号，告知评审人评审结果的交付时间。负责人还应该为评审人提供相关的资料例如《编码规约》等。

3、     文档、代码审查内容。

我们对代码的审查内容很多，如代码的编写是否规范（注释的书写格式、命名规范等）、技术处理规范（异常处理、日志处理、代码组织结构等）、业务实现等。我们不能希望通过一次文档、代码审查工作，完成所有这些内容的审查，因此我们必须设定本次文档、代码审查工作内容界限，确定审查重点；要做代码静态分析，在不执行的情况下对代码进行评估的过程，类型检查，安全审查，比较静态安全分析工具的最佳方法是使用一些工具分析同一代码并比较其结果。如：命令行参数、配置文件、从数据库中检索出来的数据、环境变量、网络服务、注册表值、临时文件，不要盲目依赖数据库的数据来保证应用程序的正确运行。

评审人评审文档、代码。评审人按照负责人告知的评审范围，认真评审代码、文档，填写评审报告，在规定的时间内完成评审。填写评审报告要明确的描述问题发现点的位置，要写清代码文件的版本号，问题点的行号。

4、选择文档、代码审查工作的实施方式。

文档、代码审查工作有很多形式可供我们选择，我们可以根据实际情况选择桌面式文档、代码审查、演示讲解式文档、代码审查、一对一的座位文档、代码审查等等。负责人将评审结果转交给代码编写人，编写人认真核对评审报告，修正代码。编写人要认真填写评审报告，要写清修正后代码文件的版本号，修正点的行号。

5、召开评审会议。

会上逐一对评审报告认真分析，评审人和代码编写人要对每一项评审结果达成共识。准确记录。对于文档、代码审查过程发现的问题，我们必须清晰准确的记录，可以使用问题点记录单，明确记录的项目和内容。

6、负责人编写评审总结。

将评审中总结出的问题和经验通知给项目组成员。并且把完整的所有文档、代码上传到服务器存档，通过版本控制工具来管理（如：SVN、VSS等工具），这样可以有效的共控制文档和代码的完整性，供公司后期参考学习使用

三，事后跟踪跟踪。

文档、代码审查结束后，对发现的问题，首先需要确定以下内容。

　　      1．问题点的难易程度以及影响的范围；

　　      2．解决问题的责任者和问题点修正结果的确认者；

　　      3．解决问题点的时限。

　   其次是对于修正问题责任者，在问题点的修正过程中，要三方面内容的记录。

　　      1．问题点的原因；

　　      2．解决问题点的对策；

　　      3．修正的内容。

做为修正结果的确认者，必须按照事前约定的时限及时的对修正结果进行全面的确认。

文档、代码管理

如何防止员工离职时擅自拷贝带走机密资料？

如何防止设计文档、程序源代码等机密信息等泄露给竞争对手？

如何让员工高效地分享企业知识的同时又能保护机密文件的安全？

现状分析

知识经济时代，企业的核心竞争力将更多地来自技术发明、专利、创新等"软资产"，随着信息系统应用的普及，这些“软资产”体现为大量的文档、代码。在日常工作中，需要数十甚至数百位员工协同工作，不可避免地需要涉及机密文档、代码，如何很好地保护这些重要资料，成为摆在企业面前的一个难题。泄密源自内部雇员故意所为；文档、代码泄密所造成的损失是没有计算标准的。在内部人员故意的泄密行为面前，企业网络中的防火墙、入侵检测以及各种文件加密等技术手段均不能起到真正的防范作用。通过寻求更加完善的技术手段保护机密文档、代码，是企业必然的选择。

虽然企业可以通过各种规章制度和一些技术手段对机密文档、代码进行管理，但是传统的安全措施和技术手段无法消除企业机密文档、代码泄漏的隐患。与此同时不可避免地因为安全原因，导致工作效率下降以及公司资源浪费，不利于有效利用现有文档和部门间的协同工作。

文档、代码保密解决方案

采用机密文档、代码集中存储、统一管理、用户权限控制的方式，将机密文档集中保存在文档中心并与客户端设备完全隔离，通过版本控制工具及管理工具，使授权用户可以在权限范围内正常使用，但无法以任何形式复制到客户端设备，从根本上杜绝了机密文档的泄漏，保护企业的核心竞争力。

客户端可以被管理或禁止的操作包括：

机密电子文档不会以任何形式（硬盘、内存等）保存在客户端设备上，用户无法以任何形式将机密电子文档复制到客户端的其他存储设备上，包括硬盘存储、软盘存储、光盘存储、U盘存储以及其他客户端存储设备。

可以管理或禁止客户端对机密文档、代码的各种输出操作，包括打印、文档编辑中的复制/粘贴、屏幕拷贝等。

使用代码、文档管理系统，帮助企业建立全面的文档管理与授权机制平台，用户可以对授权的文件与信息进行快速的查找、阅读与编辑，有效解决企业文档版本多、查找不方便甚至丢失等一系列问题，提高工作效率。可以配合企业各种的应用系统，构建安全、灵活、适应性强的应用访问平台，既满足保密需求，同时满足业务需求。

系统以文件或文件夹为基本单元向用户分配操作权限，只有拥有相应权限的用户才能执行对应的操作。用户权限细分为：无权限（用户根本无法看到或搜索到该文件）、列表（只能看到或搜索到文件名）、读取（用户可以读取到文件的内容）、修改（用户可以对文件进行修改）、管理（用户可以对文件进行授权），这些权限均可以做出时间期限的规定并随时动态调整。

用户操作日志：

自动记录每个用户的重要操作，包括文档操作，账户操作，权限修改操作等。日志记录可以在线查看。

方案简述

企业采用机密电子文档集中存储、统一管理、用户访问权限控制的方式，将机密文档、代码集中保存在机密文件服务器上，通过文档、代码管理系统管理机密文件，用户通过访问设备的方式得到对机密文件的访问授权，得到授权的用户在访问机密文件的全过程中，这些文件不会以任何形式存在于用户使用的PC机的内存或硬盘中，从而彻底防止了机密文件的泄密可能。

建立网络机密区，将应用系统集中部署在严密保护的服务器上，通过网关授权用户使用，从根本上杜绝机密信息的泄漏途径，达到既保护企业机密信息，又不影响工作效率的目的。文档、代码保密解决方案可以配合企业现有应用系统，构建企业的综合信息安全平台。

在本方案中，涉密的应用系统（包括开发工具，PDM、文档阅读和管理工具、版本控制系统等）和机密文件集中部署在机密区网络，机密区的应用系统和文档服务器与外部网络完全隔离，

通过应用系统的操作界面。使用权限范围内的各种系统和工具、根据授权，浏览或修改机密文档，访问应用系统，所有的操作都集中在服务器端，客户端任何对文档的输出、拷贝等行为均被禁止，使用者不能将机密文档本身或者内容复制到客户端的任何设备上。将现在的应用系统纳入统一的信息安全平台，在兼顾高安全性同时又不妨碍员工进行正常的工作。

文档、代码保密方案是一个综合的文档安全解决方案，能够实现任何终端设备与文档服务器的网络隔离，有效杜绝各种文档泄漏的可能性。它集成了企业内部的安全需求，如集中的文档管理、有效的数据传输控制、客户端不留下任何信息等。

可以完全实现企业实施文档保密的最核心目的（防止内部员工的故意泄密行为），从根本上保证了机密电子文档的安全。文档、代码管理系统，可以定义用户对于机密文档或文件夹的权限，包括无权限（无法看到或搜索到该文件）、列表（只能看到或搜索到文件名）、读取（可以读取到文件的内容）、修改（可以对文件进行修改）、管理（可以对文件进行授权），这些权限均可以做出时间期限的规定并随时动态调整。

 

第二篇：代码审查管理

代码审查管理

概述

Code Review代码审查是指软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找各种缺陷，包括代码缺陷、功能实现问题、编码合理性、性能优化等；保证软件总体质量和提高开发者自身水平。Code Reciew是轻量级代码评审，相对于正式的代码评审，轻量级代码评审所需要的各种成本明显低很多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性地被引入到软件开发过程中。

相反如果代码评审的流程和方法不正确，将极大提高开发成本，又无助于整体质量的提升，将得不偿失。

代码审查的内容

代码最大的问题，不是一两个地方有技术缺陷，也不是业务逻辑错误，而是整个软件设计的不好，易读性不够，难以维护。前两者更容易通过测试和使用来发现和更正，但是后者就不同。如果回想一下自己见过的各种烂摊子，是不是有同感？具体哪里有问题怎么改说不上来，就是整体软件看上去混乱无章，无从下手。一般系统开发不是一锤子买卖，还需要大量的维护工作和系统升级，假如一个系统设计不合理，代码编写不清晰易懂，代码编写不规范，将给后续的系统维护和升级代码极大的困难。

代码审查就是为了提高整体系统的质量，使系统设计更加合理，开发更加简洁清晰，代码更加易读和维护，从编写可靠的软件向编写精美软件迈进，代码检查的主要内容有：

1、 代码注释：开发人员，特别是没有经验的初级程序员，往往忽视注释的重要性，

造成更个程序的易读性大大减低，给后续的维护和升级带来极大的困难。详细、清晰的注释，可以是团队内部的其它成员在看代码时不需要看具体的代码实现，浏览一下注释就知道代码要实现的功能了，节省了很多人的时间，从而提高了团队工作效率；

2、 结构问题：MVC的分层不清晰和命名不规范，重复拷贝代码（不封装函数，不

用Template/泛型??），函数过长（超过一屏幕就叫过长），错误封装（不恰当的public/不用Interface/不内聚）；强耦合，分层不当（多个无关类置于一个文件，多个无关方法置于一个类）；不恰当的命名等；以上问题都将影响系统的可扩展性。 在此强调一下MVC分层审查重要性，好的分层式设计可以达至如下目的：可以很容易的用新的实现来替换原有层次的实现，可以降低层与层之间的依赖，利于各层逻辑的复用，达到分散关注、松散耦合、逻辑复用、标准定义。可以降低系统升级的成本，同时可以增强系统的复用程度。

3、 业务逻辑问题：软件与需求的符合度评审，虽然在功能测试时能发现大部分的

业务逻辑错误，但是有些逻辑测试需要一定的触发条件，而且测试只会发现有效的而不能发现一些开发和设计缺陷，等积累长了，谁也找不到原因。因此对于系统关键模块和业务逻辑复杂的功能模块有必要进行代码审查。

4、 编码素质问题：很多问题属于那种“这样也行那样也行”的状态，比如命名/

初始值/缩进/断行??是高手的做法总是比新手好一些。工具、框架使用不当。

5、 实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复

杂、代码可读性不佳、扩展性不好；

6、 测试问题：可测试性不好、测试覆盖度不够；

代码审查不是一蹴而就的，需要循序渐进的过程，需要持续跟进和完善；同时代码审查无法做到面面俱到，否则成本将很高。有效的代码审查内容，需要根据公司的实际情况找出哪些是重要必需的审查内容，哪些是目前最困扰公司开发的问题，进行提炼，制定出符合公司管理要求的开发规范，以此制定代码审查内容。

代码审查的好处

1、 提高代码质量

2、 及早发现潜在缺陷，降低修改/弥补缺陷的成本

3、 促进团队内部知识共享，提高团队的整体水平

4、 评审过程对于评审人员来说，也是一种思路重构的过程，帮助更多的人理解系统

5、 是一种传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可

以在以后轻松维护代码

6、 鼓励程序员们相互学习对方的长处和有点

7、 可以被用来确认设计和实现是否合理，检查设计是否清楚和简单

代码审查管理的局限

1、 无法完全验证逻辑是否正确，无法检查功能是否完整；

2、 无法检测代码中遗漏的路径和数据敏感性错误

3、 不验证规格的正确性

4、 代价高昂

对于以上局限，需要编写正确的详尽的测试用例，进行功能测试和集成测试来弥补。 代码审查管理的方法 评审程度，进行一次整体的地毯式的评审成本很高，因此代码评审的范围应该是：

1、最近一次迭代开发的代码；

2、系统关键模块；

3、业务较复杂的模块；

4、缺陷率较高的模块；

要Review的代码越多，那么要重构，重写的代码就会越多，因此要经常性地进行Code Review，但是过于频繁的Code Review既没必要也浪费资源，根据Code Review方式不同，制定合理的Code Review周期。

目前Code Review的方式比较凌乱，也没有统一的做法。“工欲善其事，必先利其器”，使用

好的工具进行轻量级的代码审查可以大大提高代码审查的效率和效果。但是目前没有任何一个工具能够完全代替人工审查，将所有问题审查出来，因此需要采取人工审查和工具审查相结合的方式，建议进行三种代码审查：1、项目组内交叉审查；2、项目组外会审；3、定期的工具测试。

对于代码审查发现的问题进行登记，事后跟踪处理情况，建议引入缺陷管理，将代码审查发现的问题记录到缺陷库中，指派给相应的处理人，处理人解决问题之后，提交检查人复查，检查人复查问题已经修复，则关闭该缺陷。

一、 项目组内交叉审查：

交叉评审也就是团队成员相互检查代码。参加人员可以是任意两组成员，最好是开发组长分别对每个组员进行代码走查。

评审的时机是在下班前半小时，对近几天（不要超过一周）改动的模块进行走查。每次评审不要贪多，当一次评审超过400行代码时，能发现的缺陷数显著降低，事半功倍。 项目组内交叉审查的好处是项目组内成员大家都很了解整个系统的架构、设计和业务，且项目组内有统一的开发规范和风格，组内成员相互比较了解，代码审查时不需要再重新熟悉系统和业务，知道重点审查哪些模块，是最能有效发现问题的代码审查方式，并且通过审查别人的代码可以达到知识共享的目标。

但是项目组内审查完全靠项目组自觉，往往因为项目进度压力，项目组资源不够，造成代码审查虎头蛇尾，坚持不下去，或者效果打折。

二、 项目组外会审：

会审以项目为单位，召开专门的代码评审会议。参与者包括项目组全体成员和QA，应尽可能邀请其他2组的开发组长或者开发部的技术专家参加。

会审的时机最好是每两周或者一个月进行一次。评审的内容应该是代码的结构设计（特别是MVC分层）、系统的关键模块和业务较复杂的模块，缺陷率较高的模块和共性的问题进行代码评审。

会审之前需要项目组做好准备工作，现有组长做整体介绍，开发人员依次发言，结合代码简短介绍本次会审代码的一些实现思路、方式和问题，参与会审人员简单快速浏览代码，提出问题并开展讨论。会后总结，把会上提出的问题、亮点及最终结论记录下来，提供其他团队借鉴。

会审的好处是项目组成员充分参与，组内成员开发习惯不同，水平高低不等，通过共性问题的讨论和规范的强调，使大家的编码风格一致，避免犯同样的错误，同时提高团队整体的开发水平。项目组外的人员参与会审，避免项目组不按照公司规范进行开发，同时可以提供更广阔的解决思路，促进几个项目组之间的学习。

但是会审会额外增加人力投入成本，不适合进行地毯式的讲解和排查问题。因此会审之前开发组长必须要准备好会审的内容和评审的范围。不应该将一些如注释没写、命名不规范等低级错误拿到会议上评审，除非是共性问题。最大限度地提高会审的效率和作用。

三、 定期的工具测试：

纯人工的代码审查既耗成本，又不容易执行，且因为代码审查人员的水平的责任心的问题，容易造成代码审查的效果不佳。如何能够统一、快速、有效地进行代码审查呢？借助相应的轻量级代码检查工具是最有效的手段，目前在JAVA领域有多款有效的Code Review工具：FindBugs、PMD和CheckStyle等。在此推荐CheckStyle作为代码审查工具。 CheckStyle是SourceForge下的一个项目，提供了一个帮助JAVA开发人员遵守某些编码规范的工具。它能够自动化代码规范检查过程，从而使得开发人员从这项重要，但是枯燥的任务中解脱出来。

CheckStyle检验的主要内容

·Javadoc注释

·命名约定

·标题

·Import语句

·体积大小

·空白

·修饰符

·块

·代码问题

·类设计

·混合检查（包括一些有用的比如非必须的System.out和printstackTrace）

并且支持自定义的代码审查。

CheckStyle是一个开源的Eclipse插件，可以将代码检查的结果输出进行分析。采用CheckStyle以后，编码规范的检查就变得极其简单，可以作为一项切实可行的日常检查加以执行。

测试的时机可以定在每个月由测试人员对项目的代码进行一次代码检查，输出检查结果。 CheckStyle的优点是可以根据SUN的JAVA开发规范，自行裁剪和自定义java代码检查策略，由工具自动进行代码检查，快速高效。

代码审查的准备工作

需要开发部配合事项：

1、 系统架构师制定和提供开发规范和指南，为代码审查提供依据；需要提供word版本的

开发规范和EXCEL版的代码审查表；同时在公司内部宣贯开发规范；

2、 系统架构师研究Checkstyle的使用，参照Checkstyle附带的配置文件，根据公司开

发规范，酌情加以裁剪和自定义Checkstyle代码审查配置文件，在项目的Maven配置文件中，添加Checkstyle任务；建议Checkstyle刚开始试行时尽量简单，在使用过程中，听取开发人员的反馈，不断修改完善配置文件，形成稳定的Checkstyle配置文件，强行执行Checkstyle，将Checkstyle作为静态测试的一部分；

对开发、测试培训Checkstyle的使用，测试定期输出Checkstyle的测试结果；

3、 系统架构师对于Checkstyle无法涵盖的代码审查内容，又认为非常有必要的代码审查

内容，制定代码审查表，要求项目组内交叉审查，定期开展会审，邀请其他项目组开发组长、测试和QA进行会议审查；

需要测试配合事项：

1、学习开发规范，学习Checkstyle，定期进行Checkstyle的静态测试，输出测试结果； 需要QA配合事项：

1、 与测试部门讨论制定Checkstyle静态测试输出测试报告内容和格式；

2、 在QA检查报告中增加代码审查的检查内容，定期对代码审查结果进行通告;

谨慎使用代码审查中发现的问题作为考评标准：

代码审查的目的是发现错误改正错误，提高整体的代码质量。

在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。

参考文档： 《高效代码审查的十个经验》 《Code Review 代码审查 不完全整理》 《如何有效的做Code Review》

《CheckStyle使用手册》 《Code Review》