程序代码评审记录表

评审简表、评审表填写说明

《评审简表》填写说明1、《简表》采用“河南省职称管理信息系统”中“个人申报版”录入、修改、上报、打印。

“个人申报版”软件、升级程序、更新代码及使用说明可到“河南职称网”下载。

请申报人员仔细阅读软件说明，并通过升级程序和“更新代码”更新软件。

选择评委会时，应选择河南教师中级专业技术职务任职资格评审委员会。

另，河南省教育厅代码：19018。

2、操作程序：点击河南省职称网—点击软件下载—安装—打开系统—高中级评审简表（或进入其他评价方式——初评、初聘、直接认定）——点击高校教师（或其他）---正高、副高、中级——省直---选择评委会（申报我校具有副教授评审权的10个学科的人员应选择河南教师高级专业技术职务任职资格评审委员会，其他申报高级职称人员应选择河南省高等学校教师评委会、申报中级职称人员应选择河南评委会）——确定---录入全部信息（不得空栏，字体尽量大、排版美观）---保存---返回---上报申报信息---保存（生成“txt文本”）。

由系统生成的和经审核后的纸质《评审简表》内容一致的“txt 文本”（以申报人员姓名命名）发送至szk@。

3、若不能直接打印《评审简表》，可通过PDF虚拟打印机在本机打印保存PDF文件后，到连接A3打印机的电脑打印。

4、《简表》右上方“填表人签名”一栏中不需签名。

5、《简表》中“第一学历”应为第一次参加工作前的学历。

6、《简表》中“其他专业技术职务”一栏，如果申报人员在上次申报之后，本次申报之前曾经参加过专业技术职务任职资格转评，则申报人员务必填写本栏内容，以确保《简表》能体现出本次申报符合相应的任职年限要求。

7、《简表》中“工作学习简历”请按照时间顺序连续填写，不得有间断并确保真实准确。

8、《简表》中“教学完成情况”一栏，填写时按××-××学年填写，为近5年。

9、《简表》中论文、著作、科研等部分内容填写时标明序号“1.2.3…”，论文排序从第一篇送审论文即开始编号为“1”，依次顺延。

软硬件评审记录

评审结论说明
主要遗留问题
序号
问题描述
严重等级
提出人
责任人
关闭或处理说明
评审结论
拟制
审核
注：问题级别分严重问题A、重要问题B、次要问题C和提示问题D四种：
1.严重问题A：指产品特性严重不符合法律法规要求，可能会造成财产或人身伤害的不合理项，或则产品丧失基本功能，无法使用的项目。
2.重要问题B：指产品特性不满足预期的要求，产品部分功能丧失，如数据偏低、网卡不兼容等。
3.次要问题C：产品特性不满足预期要求，但不影响基本功能的使用，会降低客户满意度的项目。如产品外观、包装方式等。
4.提示问题D：未构成A\B\C类问题，但有发展成问题的趋势。
评审记录
项目名称
产品型号
评审ห้องสมุดไป่ตู้型
□评审会议■电子流
评审时间
评审主题
□硬件系统设计评审□原理图评审□BOM评审□PCB设计评审□代码提交审核□软件设计评审□软件需求规格书□测试用例评审□测试报告评审□ID评审□产测流程设计评审□包装设计评审□装备软件评审□其他
评审专家
部门
角色
姓名
部门
角色
姓名
序号
评审材料/内容

软件设计评审检查表

该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线?
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
是否将需求分别陈述,因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y：是 TBD:不确定 N：不是 NA：不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
测试计划进程表开发阶段测试阶开发组集成测试承测试组系统测试业主联合测试软件需求分析完成确认测试计划完成系统测试计划软件概要完成软件集开始设计确开始设计软件设计评审检查表设计成测试计划认测试用例编写确认测试说明系统测试用例编写系统测试说明软件详细设计完成软件单元测试计划开始设计集成测试用例编写集成测试说明软件编码编写软件单元测试说明执行软件单元测试编写软件单元测试报告软件测试完成集成测试说明执行集成测试进行测试分析编写软件集成测试报告完成软件确认测试说明执行软件确认测试进行测试分析编写确认测试报告完成系统测试说明执行系统测试进行测试分析编写系统测试报告

代码评审方法

代码评审方法一、前言代码评审是软件开发过程中非常重要的一个环节，其目的是为了提高代码质量、发现潜在的问题和错误，以及加强团队协作。

本文将详细介绍代码评审方法。

二、准备工作1.确定评审人员：评审人员应该具有丰富的开发经验和技能，能够对代码进行全面的检查和分析。

2.确定评审标准：根据项目需求和开发规范制定相应的评审标准。

3.确定评审时间：在项目进程中确定评审时间，并确保所有参与人员都能够参加。

三、代码评审流程1.准备阶段（1）确定要进行评审的代码版本，并将其分配给评审人员。

（2）评审人员应该先独立地阅读代码，并记录下自己认为需要改进或修改的地方。

（3）在阅读完毕后，可以组织一个会议来讨论每个人的意见，并对每个问题进行讨论和解决。

2.正式阶段（1）按照预定时间召开会议，由主持人带领大家进入正式阶段。

（2）由提交者介绍自己提交的代码，并简单说明其设计思路和实现方式。

（3）由主持人逐行或逐段地进行代码审查，评审人员可以随时发表自己的意见和建议。

（4）对于每个问题，评审人员应该尽可能地提供解决方案，并记录下来。

（5）在评审过程中，应该注意保持专业的态度和良好的沟通，避免产生过多的争执和冲突。

3.总结阶段（1）在评审结束后，应该对所有问题进行汇总，并制定相应的修复计划。

（2）对于一些较为严重或紧急的问题，应该及时通知提交者并要求其立即进行修复。

（3）在修复完成后，应该再次进行代码审核以确保所有问题都已经得到解决。

四、评审标准1.可读性：代码应该易于阅读和理解，采用一致的命名规范和格式化方式，并注释清晰明了。

2.健壮性：代码应该能够处理各种异常情况，并有相应的错误处理机制。

3.可维护性：代码应该易于维护和修改，并且具有良好的模块化结构和可扩展性。

4.性能：代码应该具有良好的性能，在处理大量数据或高并发情况下也能够正常运行。

五、注意事项1.评审过程应该尽可能地客观和公正，避免个人情感和偏见的影响。

2.评审人员应该具有良好的沟通能力，能够与提交者进行有效的交流和合作。

CMMI3认证全套资料-代码评审记录

Num. of Open 0 0 0
实到情况（Y/N) 预评审准备时间（h)
填写自动
0
0
结论（Y/N)
解决情况(Y/N) 1
评审问题统计表
0
0
0
疑问
0
0
轻微
Total Num. Num. of Open Problems
0
0
严重
Total Num. Num. of Open Problems
问题等级疑问轻微严重
Total Num. 0 0 0
代码评审记录
记录人：
评审时间
评审日期：评审开始时间：评审结束时间：评审时长（hs）：
评审模块
文件/模块名 Module A Module B
0.0
版本 20101010.0 20100908.0
评审人员
应到人
预评审发现问题/疑问收集
参考检查单
检查内容代码的编写格式是否一致？定义的程序名是否有意义？命名中若使用特殊约定或缩写，是否有注释说明？代码编译后是否未产生Warning? 数据类型和数据声明是合理正确的吗？所有定义的子程序都使用了吗？是否防止引用已经释放的内存空间？对于退出过程/函数后仍然需要存在的内存，是否确保该内存使用完毕后及时释放该内存？注释是否清晰正确？是否符合特定语言的代码要求？（见“特定语言代码要求”页）
(如需增加检查项，在此行前插入）
0 描述说明
评审问题跟踪
问题ID 1
问题描述
问题等级
(如需增加检查项，在此行前插入）
评审结论及确认
以下签字代表评审人员同意以上文档，对文档内容进行承诺评审情况分析：（对评审发现问题以及评审问题统计数据进行分析）

ISCCCQOT0440 软件安全开发服务资质认证审核记录表

审核记录
符
合
不符合
需观察
42.
测试阶段- 集成测试
E2.5.2 a）仅二级/一级要求：明确集成测试策略，制定集成测试计划。
抽查项目，查验集成测试的测试策略、测试计划。
43.
E2.5.2 b）仅二级/一级要求：依据概要设计方案和测试计划进行集成测试设计，并执行集成测试，形成测试记录。
抽查项目，查验集成测试设计、测试记录。
查验需求阶段控制程序文件；抽查项目，查验需求阶段项目文档，内容应覆盖审核条款的要求。
需求阶段项目文档包括可行性报告、招标文件、需求分析报告等。
17.
E1.2 b）结合软件项目需求、安全需求，与客户充分沟通，达成共识并形成记录。
抽查项目，查验与客户沟通的记录。
18.
19.
E2.2 a）仅二级/一级要求：准确识别和综合分析软件项目在可用性、完整性、真实性、机密性、不可否认性、可控性和可靠性等方面的安全需求。
52.
E2.6.1仅二级/一级要求：试运行结束后，制定系统试运行报告，并提交客户。
抽查项目，查验系统试运行报告，内容应覆盖审核条款的要求。
53.
E3.6.1 a）仅一级要求：提供三个月以上的试运行记录和报告。
抽查项目，查验系统试运行记录和报告。
54.
E3.6.1 b）仅一级要求：综合软件系统试运行状态，建立软件系统运行策略和安全指南。
44.
E3.5.2仅一级要求：对集成测试结果进行分析，形成分析报告。
抽查项目，查验集成测试分析报告。
45.
46.
47.
测试阶段・系统测试
E2.5.3a）仅二级/一级要求：制定包括系统安全性测试在内的测试计划，并执行系统测试，形成测试记录。

评审报告模版

是否明确了项目范围和约束？
是否别了项目风险？
是否评估了项目风险值及控制措施？
是否确定了所有项目涉众（干系人）？
是否确定了项目各项资源需求？
是否确定了项目各项里程碑？
是否确定了项目开发模式，？
是否明确了项目进度计划完成时间？
是否明确了项目系统测试计划完成时间？
是否明确了项目风险控制计划完成时间？
是否明确了项目质量保证计划完成时间？
用例简述是否明确执行此用例的不同用户和用户通过此用例要达到的最终结事件流是否明确描述了系统所有主要的包括应有的分支动作并指明了触发条件且每个动作都是由应有的具体角色发送或接收的
XX评审报告
1
提示：由开发部项目经理填写此表格。
项目名称
评审类型
[走查/审查/复审]
时间
地点
参加
人员名单
姓名
工作单位（部门）、职务、职称
附录A
主要检查项
评价
实现代码是否完整正确地实现了设计方案？
代码实现方式是否合理、高效？
代码资源消耗、性能、执行效率、日志输出是否符合要求？
是否有重复实现公司已有代码或开源代码的地方？
代码编写是否符合编码格式规范？
代码编写是否符合系统日志规范？
代码编写是否符合安全编码规范？
提交版本时是否填写详细的备注信息？
是否明确了项目配置管理计划完成时间？
附录D
主要检查项
评价
分析包的结构是否与系统用例包结构一致？
是否分析定义出必要的边界类、控制类和实体类，通过其类图和协作图来表现相关系统用例的实现？
必要的类方法和属性是否已经定义？
每个分析类是否在其文本框中描述了真正的类名及其作用，
每个类方法是否描述了真正的方法名或实现类名，以及这些方法或实现类的作用和实现要求？

代码评审标准与结果

6
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
2
比较运算符是否正确
3
布尔表达式是否通过内部否定操作进行了简化
4
每个布尔表达式是否都正确
5
比较操作是否存在不引人注意的副作用
6
是否存在“&&”替换为“&”或“||”替换为“|”的情况
7
代码中是否避免了对浮点型数值的相等比较操作
流程控制缺陷
1
每个循环是否选用了最佳循环结构
2
所有的循环结束条件是否明显
3
6
注释对于理解代码是否有帮助
7
代码中的注释是否充分
8
代码中的注释是否过多
布局/封装缺陷
1
代码布局风格和缩排标准是否前后一致并体现其逻辑结构
2
代码中是否存在已被注释且不再使用的代码
3
复杂程序是否合理地分解成多个子程序
4
每个方法的代码量是否都不超过60行
5
方法或类之间是否具有低耦合性
6
方法或类之间是否具有高内聚性
7
是否存在重复代码且它的功能可以通过调用其他方法实现
8
方法参数数量是否控制在5个以内
性能/算法缺陷
1
是否存在更好的数据结构和算法可以采用

软件质量保证配置管理计划评审检查表

√：检查通过
х：检查不通过需修改
其他标记：请注明原因
配置管理计划
目标
（）
适用范围
（）
职责与权限
（）
配置项标识
（）
配置管理工具
（）
配置项组织结构
（）
备份制度
（）
版本发放
（）
变更控制
（）监督Βιβλιοθήκη 监控（）评审结论评审结论是否明确
（）
评审遗留问题是否落实
（）
评审报告
评审报告是否成文
（）
评审报告是否发给参加评审的人员
（）
项目SQA人员签名：
请在（）内标注相关检查结果
质量策划
（）
需求文档
（）
设计文档
（）
测试计划用户手册
（）
会议记录
（）
调研报告
（）
培训记录
（）
每日/周工作记录
（）
评审报告
（）
源代码
（）
开发工具与版本
（）
配置管理工具的定义
（）
配置项组织结构
（）
备份制度是否明确
（）
版本发放
版本发放原则（谁做，如何做）
（）
版本标识原则
（）
变更控制
明确的提交流程
（）
明确的修改流程
（）
对配置项（包括源码）修改时填写注释
（）
源代码阶段性设置Lable
（）
监督与控制机制是否明确
（）
评审的组织
以上资料是否提前2天发给参加评审的人员
（）
是否指定评审会议主持人
（）
评审的参与人
配置管理计划中涉及的SCCB成员

XX投标项目技术明标评审记录表(2023年)

技术明标评审记录表（标准分100，分值代号为M1）
序号
评分项目
标准分
评分标准（分）
投标人名称代码:
1
企业业绩
5
近三年（见备注）完成的类似项目的国内销售与安装业绩—原件备查。需提供合同复印件盖公章，包括用户的联系电话及联系人,根据数量打分，企业业绩每提供1个得1分，最多5分。
2
企业财务状况
2
根据最近两年投标人已经审计的财务报表，财务状况良好得0-2分。
10
产品质保期限及质保内容；产品维护服务、技术支持的方式和时间：0-4分；
产品质保期后运行、维护保养的成本：0-4分；
在北京市具有常设服务办事机构（须提供相关管理部门的证明文件）得2分，否则不得分
8
投标人的专业技术力量和技术支持
5
根据投标人专业技术力量（技术人员所获得的相关资质认证等）视情况得分0-5分；
9
备品备件提供计划
5
配置合理、充足3-5分
欠合理1-2分
评委签字：日期：年月日
（备注：“近三年”指2009年11月1日至2012年10月31日）
3
企业资质认证及资信证明
3
有ISO系列认证，具有银行资信证明，并有政府机构出具的重合同守信用证明得0-3分。
4
投标文件对招标文件货物产品配置、技术规格、案及正确的货物、设备参数配置：0-20分；
所选品牌在招标文件推荐的品牌范围内或虽不在范围内但性能功能质量相当者（须提供相关文件支持）：0-15分；
根据所选品牌的货物，其技术性能的先进性可靠性依次进行打分：0-25分；
5
产品的寿命和可靠性
10
使用寿命长，可靠性高7-12
使用寿命较长，可靠性较高0-6

评审代码表

关于专业技术资格评审代码表的说明
为便于专业技术人员正确选择申报专业技术资格的系列（专业）。

我们整理编写了广东省（含深圳市）高、中级专业技术资格评委会一览表，供大家参考。

使用时，请注意以下几点：（1）申报人选报专业时，应以近几年来所从事的专业技术工作为依据，即申报人必须是在职在岗的专业技术人员。

（2）申报人选择申报专业的文件依据是广东省职改办颁发的各相应系列（专业）《广东省专业技术资格条件》，申报人应按资格条件的第一条选择申报专业及代码，并按所选专业《资格条件》的有关规定准备申报材料。

（3）申报正高级专业技术资格须报省直高评委评审，日常工作部门设在深圳的高评委只能评审副高级资格。

（4）深圳市的各个中级评委会应严格按市人事局规定的受理范围接受申报。

（5）选择好专业后，应将所选专业组名称及代码分别写在申报资料袋正面及底部相应栏内；选报未列出专业评审组名称及代码的评委会时，不填写专业组名称及代码，但须在“专业”栏写明评委名称，在“专业代码”栏内写明评委会代码。

高级专业技术资格评审委员会
深圳市中级专业技术资格评委会一览表。

(完整word版)代码审查规范

代码审查规范1. Code Review目的Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。

Code Review主要用来在软件工程过程中改进代码质量,通过Code Review可以达到如下目的：•在项目早期就能够发现代码中的BUG。

•帮助初级开发人员学习高级开发人员的经验，达到知识共享.•避免开发人员犯一些很常见，很普通的错误。

•保证项目组人员的良好沟通。

•项目或产品的代码更容易维护。

2。

Code Review的前提条件代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点.•所有代码注释清晰，语法正确,编译通过。

•日志代码完整,业务日志、系统日志分开，中文描述，脱敏处理，状态变更,全部清晰明确。

•测试代码覆盖全部分支和流程,暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。

•项目引用关系明确，依赖关系清晰，配置文件描述。

3。

Code Review的审查范围代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求(性能、功能）与设计文档相同等等。

3.1、完整性检查（Completeness）•代码是否完全实现了设计文档中所涉及的所有流程和功能点•代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。

•代码是否使用缓存等，配置信息是否正确可配置。

•代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等3。

2、一致性检查(Consistency）•代码的逻辑是否符合设计文档•代码中使用的格式、符号、结构等风格是否保持一致3。

3、正确性检查(Correctness)•代码是否符合制定的标准•所有的变量都被正确定义和使用•所有的注释都是准确的•所有的程序调用都使用了正确的参数个数3。

如何使用代码评审来检查代码正确性

如何使用代码评审来检查代码正确性代码评审是软件开发过程中非常重要的一环，它可以帮助团队发现潜在的错误、提高代码质量、避免未来可能出现的问题，从而保证软件的稳定性和可维护性。

下面将介绍如何使用代码评审来检查代码的正确性。

1.选择合适的评审工具：在进行代码评审之前，首先需要选择合适的评审工具。

目前市面上有很多代码评审工具，比如Github、GitLab、Phabricator等。

这些工具可以帮助团队成员在代码库中提交代码并进行评审，同时也能够记录评审结果和意见，便于以后查看和跟进。

2.确定评审原则和标准：在进行代码评审之前，团队需要确定一套评审原则和标准，以确保评审过程的准确性和一致性。

这些原则和标准可以包括代码规范、代码风格、命名规范、注释规范等，以及特定项目的需求和约定。

3.选择评审人员：代码评审需要至少两名评审人员进行，一般来说，评审人员应包括代码提交者本人以及另一位熟悉项目的团队成员。

评审人员应具有足够的经验和知识，能够准确地识别和纠正代码中的错误和问题。

4.进行代码检查：在进行代码评审时，评审人员需要注意一些常见的代码问题，比如功能实现是否符合需求、逻辑是否正确、边界条件是否考虑全面、异常处理是否完善、代码是否可维护等。

评审人员可以结合项目的具体情况和需求，制定详细的检查清单，逐一检查代码的正确性。

5.提出修改建议：在检查完代码后，评审人员需要提出修改建议，并给出具体的改进方案。

修改建议应基于团队约定的评审标准和原则，以确保代码质量和一致性。

评审人员应尽量避免在评审过程中过于苛刻或主观，应以客观事实和逻辑为依据，尊重代码提交者的劳动成果。

6.进行讨论和确认：评审人员在提出修改建议后，需要与代码提交者进行讨论和确认。

代码提交者应认真对待评审人员提出的问题和建议，并根据实际情况做出相应调整。

同时，评审人员也应保持沟通畅通，尽量解释和说明自己的意见，以避免出现误解和分歧。

7.记录评审结果：评审过程结束后，评审人员需要记录评审结果和意见，以便以后查看和跟进。

代码审查报告范文

代码审查报告范文一、引言代码审查是软件开发过程中非常重要的环节，通过对代码的评审可以发现潜在的问题并及时纠正，合理分配编程任务和提高团队的合作效率。

本文对项目代码进行了详细的审查，旨在提供准确的评估和建议。

二、审查对象本次代码审查的对象是项目中的其中一模块（以下简称“待审模块”）。

该模块由开发工程师张三编写完成。

三、代码审查结果基于对待审模块的全面审查，本次审查结果如下：1.代码结构和可读性：待审模块的代码结构清晰，模块划分合理，函数命名规范，注释规范。

部分代码行长度超过了标准限制，建议进行适当调整以提高可读性。

2.效率和性能：待审模块的算法设计合理，关键代码运行效率较高。

但在一些循环中，存在重复计算的情况，建议通过合理的缓存机制来减少计算量，提高性能。

3.安全性：待审模块没有发现明显的安全漏洞和错误，已经对用户输入进行了合适的验证和处理。

但仍需要注意对敏感信息的保护和防御措施的加强。

4.错误处理和异常处理：待审模块未对所有可能的错误和异常进行适当的处理，部分场景下可能导致程序崩溃或者不可预期的结果。

建议增加错误处理和异常处理的代码逻辑，保证程序的健壮性。

5.可扩展性和复用性：待审模块的代码结构较为臃肿，缺乏模块化和封装性，导致部分函数功能重复，不利于对模块进行扩展和复用。

建议优化代码结构，增加代码的可扩展性和复用性。

6.单元测试：待审模块的单元测试覆盖率较低，需要完善单元测试用例，覆盖更多的分支。

同时，建议引入自动化测试框架，提高测试效率和质量。

四、总结和建议通过对待审模块的代码审查，我们得出以下总结和建议：1.代码结构和可读性：优化部分过长的代码行，增加适当的空行和缩进，提高代码可读性。

2.效率和性能：优化重复计算的部分，引入缓存机制，减少计算量，提高性能。

3.安全性：继续加强对敏感信息的保护，并注意常见的安全漏洞和攻击手段，防范信息泄露和篡改。

4.错误处理和异常处理：增加对可能出现的错误和异常情况的处理，保证程序的稳定性和可靠性。

代码评审清单

代码评审清单（Code Checklist ）产品,项目组名称；_宅急送_________ 产品项号名称，公共_______________ 版本号：被检杳人簽字：—检杳內容: _ _检查人螯宇，_____________________ 检查日期’______________________说明：是杏尽童避免了嵌会的立•弔篦杂芳雄是否併行了必茅而充分的汗释拎K是否代码拥亍路径是否清晰S罰Chi航是否有決4分支控制逻短复杂度是否合浬是否诜行了必更1门充分的注释同个循坏怎是吞仅执行了羊而明确的巧毙占械比校需要挣常数玫在比较表达式的前面否代彳礎丧奸格ig化并能疝苴逻辑结枸尽量孑哎在循开丙岀观近程谐月奇个吐务可作远程谓用次数是否小于以冈1中因数是吞仕抱定范围内Joinb on矽页产恪匹0己问題淸单.冋幅沐阚窟改n期修改n期楡杳SQL r 是冈1语句』碍弓用乎符画单引号T^MO select *开预的语句，必姦指出旦饶宇SF严禁使用ins«t m2 Uiblc: values "t ? , ? , "?) ＞必须指1岀具依更0jt值広字段避兌隐含的炎型转换(不同数据类型字段明加)子宣询前后必须加上桔号邀免在我here使用，1* / 1=2’这*怯廿戎作为部分条件禁上使用椰图禁上使用XX in 0 or XX血CKm中的元素个数不应超过500)禁止使用or超辽500个其止使用not in・建议使冃not exist婪止在一条河语句中恃月3层以丄的嵌套如具勺多表连莪盯「应该有主从之分，尽重从一个表取数Where子句过滤条杵，索引列或过遞记录最多氏条林应験在前面字符邑连接必须使用“ rCaw when吾匀中巳能出珂二、k、u以及is mill运算袴左连接写送必須带”cxuei'关佬宰伝稈诅用蓟摇伎端启否有不必萼的冗輛摇Java代码审查检查丧类定义缺陷(CD)代码评申检査表软件代码检杳单（C语言）77 检鱼寮量和宏，数字帘金应该用宏未表不，检登宏足义中的数位、実型是合正佚月说明・1.本檢杳单为软件评頁朋检査较件产品惜俣和扶陷提供了指导。

软件项目代码走查管理规范

代码走查管理规范修订记录修订类型包含：新增、修改、删除。

目录1 目的 (1)2 适用范围 (1)3 职责划分 (1)4 代码走查分类 (2)5 代码走查流程 (2)5.1 准备阶段 (2)5.2 执行阶段 (2)5.3 修复阶段 (3)5.4 反馈阶段 (4)6 代码走查要求 (4)7 相关文件 (5)1目的明确项目中代码走查的流程和要求，提升代码走查质量，为代码走查工作提供指导依据。

2适用范围技术与研发中心。

3职责划分在代码走查工作中，各角色职责如下：4代码走查分类5代码走查流程5.1 准备阶段（1）技术经理依据代码走查活动要求，规划代码走查执行时间，确定走查方式。

（2）开发人员在代码编写完成后，应先对编写内容进行自查，再将代码提交到开发库中进行保存。

（3）技术经理确定走查代码范围，发送代码走查活动通知。

5.2 执行阶段（1）工具静态检查如果使用工具进行静态代码走查，则按照工具的使用方法，执行静态检查活动，代码走查执行者将工具走查结果记录到《代码质量评价表》中。

使用工具的静态检查是可以实时执行的活动，因此鼓励开发人员在编译个人部分的代码时，尽可能多频次、全覆盖的执行工具静态检查，提升个人编写代码内容的准确性、规范性，最大程度确保合并到主流上的分支代码的优质性。

除此之外，为了增强执行效果，还可以待全部分支代码合并到主流后，以全量代码为对象进行整体性的工具静态检查。

（2）人工代码评审人工代码评审是一种正式的评审活动，通常采用集中会议的方式，以功能模块为单位，通过讨论的方式，对程序代码进行审查，以达到提升代码质量的目的。

如果采用人工代码评审方式，则由技术经理牵头组织审查活动，邀请团队开发人员及其他必要成员组成一个审查小组，进行代码评审会议。

会议中，评审小组成员依据设计说明书、控制流程图、程序文本及有关要求、规范等内容，充分阅读被评审程序代码，并由该程序编写者介绍其代码实现过程、讲解程序逻辑，在此过程中参会人员提出问题、展开讨论、发现错误。

软件设计评审检查表

测试计划检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？

code review(程序员必看)

如何做Code Review
统一的编程规范和设计文档规范.也会用这些作为Code Review的检查标准完整的技术架构和技术架构说明或事例，争取能够包含程序编写的各个方面不定期的Code Review会议及代码讲解
Code Review时间安排
Code Review的时间安排可以根据项目大小和周期长短来定，小项目（如3个月内）可以定在10天内一次，大项目（6个月以上）可以在半个月内一次，次数的安排也要讲究，在项目的开始之处应该安排密一些，在项目进展到一定的程度后，周期可以更长，一个月内一次。这种安排出于以下考虑，一是项目成员对项目的认知在开始阶段比较粗浅，问题较多，因此需要及时的纠正；而当项目成员随着进展而成长后，有很多问题可以为成员自己所避免,因此安排Code Review 的次数应该减少。除了纠正错误和问题之外，Code Review可以通过相关人员的参与，来交流一些技巧和宝贵的经验，以讲解和讨论的形式获得提高。
编码的习惯检查
魔法数 MagicNumber，非常让程序不可读。比如：也叫 MagicNumber，非常让程序不可读。比如： sex = 0 表示的什么意思？大多数时候，表示的什么意思？大多数时候，就连作者本人都要皱眉头想半天，所以，人都要皱眉头想半天，汗……所以，这里的"0" 所以这里的"0" 就是一个魔法数。如果这样写就好的多：就是一个魔法数。如果这样写就好的多： public static final int MALE= 0; sex = MALE;
编码的习惯检查
不合适的token 不合适的token 很多大牛都建议在java java中不要使用很多大牛都建议在java中不要使用 switch；另外，使用c++ switch；另外，使用c++ 或 c-- ， ++ --c这样的后缀也会让可读性变差。 c 或 --c这样的后缀也会让可读性变差。内部赋值语句如果有人这样写：如果有人这样写：String s = Integer.toString(i = 2); 是不是很想扁他？扁他？