代码审查清单
C#代码审查清单
这是为C#开发者准备的通用性代码审查清单，可以当做开发过程中的参考。
这是为了确保在编码过程中，大部分通用编码指导原则都能注意到。
对于新手和缺乏经验（0到3年工作经验）的开发者，参考这份清单编码会很帮助。
清单1. 确保没有任何警告（warnings）。
2. 如果先执行Code Analysis（启用所有Microsoft Rules）再消除所有警告就更好了。
3. 去掉所有没有用到的usings。
编码过程中去掉多余代码是个好习惯。
4. 在合理的地方检查对象是否为’null’，避免运行的时候出现Null Reference Exception。
5. 始终遵循命名规范。
一般而言变量参数使用驼峰命名法，方法名和类名使用Pascal命名法。
6. 请确保你了解SOLID原则。
根据维基百科定义：在程序设计领域，SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转) 是由罗伯特·C·马丁在21世纪早期引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。
当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。
SOLID所包含的原则是通过引发编程者进行软件源代码的代码重构进行软件的代码异味清扫，从而使得软件清晰可读以及可扩展时可以应用的指南。
SOLID被典型的应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发的基本原则的重要组成部分。
参考：wiki/SOLID_(面向对象设计)7. 代码可重用性：如果一块代码已经被使用超过一次，或者你希望将来使用它，请提取成一个方法。
将重复的工作做成通用的方法放在相关的类中，这样一旦你完成别人就可以使用了。
将常用功能开发成用户控件，这样可以跨项目重用它们。
8. 代码一致性：比方说，Int32写成int，String写成string，应该在代码里保持统一形式。
不能一会二写成int一会儿写成Int32。
静态代码分析工具清单
静态代码分析⼯具清单SAST，即静态应⽤程序安全测试，通过静态代码分析⼯具对源代码进⾏⾃动化检测，从⽽快速发现源代码中的安全缺陷。
本⽂是⼀个静态源代码分析⼯具清单，收集了⼀些免费开源的项⽬，可从检测效率、⽀持的编程语⾔、第三⽅⼯具集成等⼏因素来综合考虑如何选择SAST⼯具。
1、RIPS⼀款不错的静态源代码分析⼯具，主要⽤来挖掘PHP程序的漏洞。
项⽬地址：2、SonarQube⼀款企业级源代码静态分析⼯具，⽀持Java、PHP、C#、Python、Go等27种编程语⾔，⽽且能够集成在IDE、Jenkins、Git等服务。
项⽬地址：https://3、CodeQL⼀个免费开源的语义代码分析引擎和查询⼯具，以⼀种⾮常新颖的⽅式组织代码与元数据，可以通过像SQL查询⼀样检索代码，并发现其中的安全问题。
git项⽬地址：https:///github/codeql-cli-binaries4、Find Security Bugs⼀个⽤于 Java Web 应⽤程序安全审计的 SpotBugs 插件。
项⽬地址：https://find-sec-bugs.github.io/5、VCG(VisualCodeGrepper)⼀种适⽤于 C++、C#、VB、PHP、Java、PL/SQL 和 COBOL 的⾃动化代码安全审查⼯具。
项⽬地址：https:///projects/visualcodegrepp/6、FindBugs⼀款静态分析⼯具，检查程序潜在bug，在bug报告中快速定位到问题的代码上。
项⽬地址：7、Cobra⼀款源代码安全审计⼯具，⽀持检测多种开发语⾔源代码中的⼤部分显著的安全问题和漏洞。
项⽬地址：https:///WhaleShark-Team/cobra8、Hades⼀个静态代码脆弱性检测系统，⽀持java源码的审计项⽬地址：https:///zsdlove/Hades9、Bandit⼀个专门⽤于查找Python代码中常见安全问题的⼯具。
代码审查(Code Review)清单
英文原文：oschina代码审查可以帮助提高代码质量，避免由于代码习惯而造成的 bug。
下面列出的这些要点因该可以作为大部分代码审查的指导，如果是 Java 应用的话，这些建议应该被视作最佳实践。
文档1. Javadoc 应该在每一个类和方法中添加。
2. 如果是修复某个 bug，应该添加 bug ID。
3. 走捷径的方法或者复杂的逻辑要有解释。
4. 如果代码会被公开，每个文件头都要标注版权信息。
5. 复杂的 HTML，JavaScript，CSS 应该包含文档。
功能1. 如果类似的逻辑被使用了多次，应该把它写成一个帮助类，然后在多出调用。
2. 鼓励使用 API 而不是重复编写代码解决相同的问题。
3. 要强调代码的单元测试。
4. 任何新加的代码不应该破坏已有的代码。
5. 假如是 Web 应用，JSP 不应该包含 Java 代码。
安全1. 任何代码都不能执行用户的输入，除非转义过了。
这个常常包含 JavaScript 的 eval 函数和 SQL 语句。
2. 禁止那些在短时间内提交非常多请求的 IP。
3. 任何类，变量，还有方法都应该有正确的访问域。
4. 尽量避免使用 iframe。
性能1. 所有数据库和文件操句柄在不需要的时候都应该被关闭。
2. SQL 语句的写法会导致性能千差万别。
3. 鼓励创建不可变（immutable）的类。
4. 类似的逻辑代码，尽量通过 if else 语句来实现更多的重用。
5. 尽量避免使用重对象（heavy objects）。
6. 如果是 Web 项目，请检查是否使用了合适的图片尺寸，CSS sprites 和浏览器缓存等技术。
7. 全局都需要的信息保存在 application context 中。
编码习惯1. 没有被使用的变量要删除。
2. 针对不同的 Exception 要用不同的 catch 语句，而不是一个 Exception 解决所有问题。
3. 针对变量，方法和类要用相同的命名方法。
软件测试二：测试基础2之检查代码、带上X光眼镜测试软件
软件测试⼆：测试基础2之检查代码、带上X光眼镜测试软件1、检查代码军队、⾦融、医药类软件，或者在组织严格的开发模式下⼯作，在代码的级别验证产品就是例⾏公事。
如果测试软件的安全问题，那么这是必须进⾏的。
1、静态⽩盒测试：检查设计和代码静态⽩盒测试是在不执⾏软件的条件下有条理地仔细审查软件设计、体系结构和代码，从⽽找出软件缺陷的过程，有时称为结构化分析。
进⾏静态⽩盒测试的⾸要原因是尽早发现缺陷，以找出动态⿊盒测试难以发现或隔离的缺陷。
在开发过程初期让测试⼩组集中精⼒进⾏软件设计的审查⾮常有价值。
另⼀个好处：为⿊盒测试员再接受软件进⾏测试时设计和应⽤测试⽤例提供思路。
他们不必了解代码的细节，但是通过听审查评论，可以确定有问题或容易产⽣缺陷的特性范围。
注意：开发⼩组负责静态⽩盒测试的⼈员不是固定的。
某些⼩组中，程序员就是组织和执⾏审查的⼈员，测试员被邀请作为独⽴的观察者。
还有⼀些⼩组中，测试员是该任务的执⾏⼈，要求编写代码的程序员和其他同事帮助审查。
这些⽅式都可以，取决于项⽬⼩组的情况。
对于静态⽩盒测试最不幸的是常常不能善始善终。
许多⼩组错误的认为这样耗时太多、费⽤太⾼、没有产出。
这些都不对-与产品接近完⼯时的有选择性的测试，找出甚⾄找不出缺陷相⽐。
问题在于⼀般认为程序员的任务是编写代码，⽽任何破坏代码编写效率的事情都会减缓开发过程。
所幸，⽬前很多公司意识到早期测试的好处，并招聘和培训程序员和测试员进⾏⽩盒测试。
2、正式审查正式审查进⼠进⾏静态⽩盒测试的过程。
正式审查的含义很⼴，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查均属于此过程。
正式审查有4个基本要素：确定问题。
审查的⽬的是找出软件的问题-不仅是出错的项⽬，还包括遗漏项⽬。
全部的批评应该直指代码和或设计，⽽不是其设计实现者。
遵守规则。
审查要遵守⼀套固定的规则，规则可能设定要审查的代码量、花费多少时间、哪些内容要做评价。
其重要性在于参与者了解⾃⼰的⾓⾊、⽬标是什么。
程序代码规范性检查与整改方法研究
程序代码规范性检查与整改方法研究在软件开发过程中，代码规范性检查与整改是一项至关重要的任务。
通过对程序代码的规范性检查，我们可以减少代码错误和不一致性带来的潜在风险，提高代码的可读性和可维护性。
本文将介绍程序代码规范性检查的重要性，并提供一些有效的整改方法。
代码规范性检查的重要性程序代码规范性检查是软件开发过程中的一项必要任务。
它有以下几个重要的原因：1. 错误和风险的减少：通过规范性检查，可以减少代码中的错误和潜在风险。
代码规范性检查可以确保程序员遵循一致的编程规则，帮助排除一些容易引起错误的代码。
这将减少代码出错的可能性，提高代码的质量和稳定性。
2. 提高代码的可读性：规范性检查可以促使程序员编写具有良好结构和命名规范的代码。
这将提高代码的可读性，使其他程序员能够更轻松地理解和维护代码。
可读性良好的代码能够减少团队之间的沟通成本，提高开发效率。
3. 保持代码的一致性：通过规范性检查，可以确保代码符合统一的编码规则和风格。
这将使不同开发者编写的代码看起来一致，降低代码的混乱程度。
一致的代码风格有助于提高代码的可维护性和可扩展性。
有效的整改方法以下是一些有效的程序代码规范性整改方法：1. 运用自动化工具：利用自动化工具可以大大提高代码规范性检查的效率和准确性。
例如，代码审查工具（如Checkstyle、ESLint等）可以扫描代码并检查代码是否符合预定义的规则。
这些工具可以帮助开发者快速发现并修复规范违规的代码。
2. 建立代码审查流程：建立一个完善的代码审查流程可以确保代码的规范性得到维护。
代码审查可以是集体评审或个人评审的形式，旨在发现和纠正代码中的规范违规问题。
通过定期的代码审查，团队可以保持代码的高质量和一致性。
3. 提供规范性检查清单：制定一份规范性检查清单可以帮助开发者快速了解代码规范的要求，并遵循这些规范编写代码。
清单可以包括命名规则、代码缩进、注释规范等规范要求。
开发者可以根据清单中的要求自我检查代码的规范性，并进行相应的整改。
软件开发项目管理检查清单（转）
软件开发项⽬管理检查清单（转）转⾃【冬眠的蛤蟆】博客检查清单⽤于确认作业或⼯程是否存在遗漏，是反映项⽬管理是否存在问题的“天⽓晴⾬表”。
下⾯是软件开发项⽬管理的⼀个检查清单，⽐本章中所⾔“软件开发项⽬管理过程中的祸根及其后果”更加详细。
通过这个清单，可以发现项⽬管理存在的问题，并采取措施加以改善。
需求式样晴⾬表是否存在稳定的、完整的、书⾯的需求式样？是否已经就需求事项煞费苦⼼地与顾客进⾏了沟通和确认？是否存在需求式样尚未确定就以“暂定式样”开始作业⽽事后返⼯的情况？是否为了确认顾客的需求⽽对“需求式样书”进⾏了审查？是否根据顾客提供的产品式样书⽽直接进⼊了设计作业？是否在作业途中不断变更或追加需求式样？是否按照项⽬编号规则对每项需求赋予了惟⼀的编号？是否已经明确顾客⽅的项⽬推进体制以及最终决策者？是否摄于顾客的特权优位性⽽不经讨论地接受顾客的需求变更？是否在远远超越⾃⾝能⼒⽽根本⽆法完成的情况下不能清楚地说“不”？是否在作业已经进⼊测试阶段后还发现需求式样理解有误？是否以单⼀窗⼝接收顾客的需求，确保⼀窗⼝输⼊？项⽬组成员的作业是否基于最新需求信息，⽽不是已经失效的历史信息？项⽬计划晴⾬表是否将估算视为⼀种特殊的技能，并将估算当作⼀个⼩项⽬？是否定期对项⽬计划实施重新估算并根据实际情况加以调整？是否对作业⽂档等成果物的“量”进⾏了估计？是否以适当的单位进⾏了作业量的估计？项⽬作业是否具有详细的⽇程表？⽇程表确定之后，如果和实际情况出⼊较⼤，是否进⾏了调整？是否接受了不切实际的开发⽇程，⽽其结果是，⽇程表仅仅成为⼀种形式？“⼯作量”和“难易度”是否会因为担当者的不同⽽出现巨⼤变动？是否因为实际进展超前于计划⽽没有思考项⽬计划本⾝存在的精度问题？团队管理晴⾬表是否存在明确的软件开发⾏动单位：团队？是否虽然叫作团队，但是并没有认识到协作⽽是专注于⼯作任务的分担？管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？项⽬管理者是否仅仅根据⾃⼰的经验⽽将需求式样直接分派给“个⼈”？项⽬管理者是否总是认为项⽬没有什么值得注意的问题？团队成员是否知道项⽬作业内容的相互关系及其优先级？是否在项⽬启动之后仍然还有项⽬组成员感到⽆所事事？是否经常有特定的项⽬组成员总是加班到深夜？团队成员是否知道并遵守统⼀的作业规范？是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？团队成员是否在相互察看成果物后产⽣提⾼⾃⼰的作业⽔平的意识？当问题难点解决之后，是否向项⽬组成员介绍解决该问题的思维和⽅法？项⽬组成员的出勤时间是否经常相差很⼤⽽不寻找原因？项⽬组成员在遇到技术难题时是否与项⽬组其他成员沟通并寻求⽀援？项⽬组成员在讨论问题时是否出现⽆条理的、⾮建设性的讨论？作业流程晴⾬表是否存在专注于组织整体的开发作业和项⽬流程的⼈或者⼩组？是否存在项⽬开发作业的标准作业流程？是否存在记述顾客需求式样的⽂档标准？是否存在设计书的⽂档标准？是否不经过设计阶段⽽直接进⼊编码阶段？设计阶段是否实施了以设计为对象的审查？编码阶段是否实施了以代码为对象的审查？中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？是否未经单体测试就直接开始综合测试？是否时⾄最后才发现此前隐藏的诸多问题？是否⽆视已经发现的问题⽽继续推进作业？是否多次重复出现以前相同的错误⽽没有吸取教训？是否没有专门的测试⼈员⽽在交付之前还是由开发者⾃⼰实施测试？对式样需求是否确⽴了适当的测试项⽬？测试是否⼏乎没有⾃动化⼿段？过程改善⽅⾯是否存在可以商量和咨询的⼈员？是否⿎励各开发⼩组写作事后分析报告，⾄少能就项⽬进程开会讨论？是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？项⽬配置晴⾬表是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？是否只有担当者知道⽽没有向所有成员公布缺陷的修正范围和修正⽅法？是否因为修改⼀个程序缺陷⽽引发多个新的缺陷？担当者是否能在任何时间对源程序做⾃由的变更？开发期间是否定期对制作过程中的⽂件和程序进⾏备份？是否确⽴了资源备份在⾮常时期的因应⽅式？需求式样书和设计书等正式⽂件是否存在“确认”⼿续？项⽬⽂档是否⼀直保持最初的状态，即使在式样变更后仍然没有变化？是否在项⽬后期难以想起中途式样变更的“理由”？对于程序缺陷和式样变更，是否能追踪其修改点？对于开发环境⽬录中的旧代码是否难以判断其能否删除？开发⽂档是否会出现链接到旧版本的情况？教育培训晴⾬表是否描绘出现在的开发组织多年后的“风姿”？在组织上，是否对现在的⼈员实施技术性教育和培训？是否确⽴了员⼯教育培训的计划和⽬标？是否将技术学习视为个⼈任务⽽没有组织上的“⽅向”？项⽬开发⼈员所持有的软件开发⽂献的平均数量是否在1册以下？项⽬作业休息时间是否毫不涉及崭新技术⽅⾯的话题？项⽬组成员是否不知道软件⼯程的意思？是否不了解“凝聚度”、“结合度”等词汇的意思？是否难以说出5个以上的软件质量特性及其副特性？项⽬审查晴⾬表参与者是否了解审查的整体流程？是否带着⽬的⽽⾮盲⽬地实施审查作业？是否仅仅局限于代码审查⽽不顾及其他？审查者是否只关注形式⽽⾮实质？是否明确审查对象物，针对“物”⽽⾮“⼈”？是否记录审查结果并追踪缺陷修正结果？是否将审查的反馈结果导⼊下⼀项⽬中？审查会议是否演化成为问题解决会议？其他是否采取了数据备份以及病毒防范等措施？对电⼦邮件的应对是否总是滞后？是否感到电⼦邮件的应对很繁琐？。
代码检查、走查与评审
容易引起变量使用错误，特别是对于指针或引用变量。 在java中要求变量在使用前必须初始化。
数组下标的范围和类型
是否存在下标越界错误，下表类型是否为整型。
通过指针引用的内存单元是否存在（虚调用）？
如在函数返回局部变量的指针或引用时会产生虚调用错误。
被引用的变量或内存的属性是否与编译器预期的一致？
代码走查和代码检查类似，都是以小组为单位进行代码阅读， 是一系列规程和错误检查技术的集合。二者的过程大致相同， 不同之处在于
规程稍微不同 走查会议期间，每个测试用例都在人们脑中推演，即把测 试的数据沿着程序的逻辑结构走一遍，记录程序的状态供 监视，很多错误是在向程序员提问的过程中发现的。
其他与代码检查相同的地方
实施过程
协调人在代码检查前几天分发程序清单和设计规范 编码人员讲述程序的逻辑结构，其他人员提问题并判断是否存
在错误 对照历来常见的编码错误列表分析程序 注意力集中在发现错误而非纠正错误上（非调试） 会议结束后，程序员会得到一份已发现错误的清单
整理课件
8
代码检查的错误列表
1.数据引用错误
参与者所持的态度同样非常关键 代码走查也会带来同样的附带作用
整理课件
19
桌面检查
桌面检查
是人工查找错误的一种古老的方法 桌面检查可视为由单人进行的代码检查或代码走查
由一个人阅读程序，对照错误列表检查程序，对程序推 演的过程。
桌面检查的缺点
桌面检查的效率低 是一个完全没有约束的过程 违反了测试原则：人们一般不能有效测试自己编写的程 序，因此桌面检查最好由其他人而非该程序的编写人员 来完成
const关键字） 全局变量的定义是否一致？
软件测试的常用方法
软件测试的常用方法软件测试一般按照静态分析和动态分析方法来实施，静态分析是对应用程序的外在形式和表现进行测试，而动态分析则是直接测试应用程序所执行的内部行为。
1.静态测试：（1）代码审查：代码审查是一种在软件开发期间和开发周期后执行的活动，它可以检查软件系统是否具有所需的属性，如可靠性，可接受性，功能完整性，有效性和可用性。
（2）检查清单测试：检查清单测试是一种以文档格式表示的跟踪，可用于提供正确的功能，以确保软件可操作性。
它可以帮助团队确定某些特定方面的问题，例如安全性，格式，注释，编码等。
（3）流程图：流程图是一种图形化技术，可用于描述软件系统中函数之间的联系和控制，以及实现这些函数所需的活动。
它可以帮助团队发现函数之间的冲突，活动缺乏流畅性或存在其他异常情况。
2.动态测试：（1）单元测试：单元测试是一种针对程序中特定函数，类或模块进行测试的方法，它通常用于确定每个单元的表现是否符合文档要求。
（2）集成测试：集成测试是将软件的不同部分联系起来以确定其整体表现的一种方法。
它可以帮助团队确认不同组件之间的兼容性，以及集成新组件会对软件产生的影响。
（3）系统测试：系统测试是一种针对整个软件系统进行测试的方法，它可以帮助团队发现隐藏的故障，纰漏，工作流程问题等。
（4）接口测试：接口测试是检查两个软件组件之间交互的行为是否与预期结果相符的过程。
它可以帮助团队确认不同组件交互的行为是否有效，以及是否存在其他异常情况。
（5）性能测试：性能测试是指将软件系统被重载多少程度，其响应时间是多长时间，它可以在多少并发情况下运行，它在运行期间是否可用等等。
（6）回归测试：回归测试是指对软件中已存在功能的重新测试，以确保系统中的更改不会影响原有功能或引入其他错误。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
常规项
代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
所有的代码是否简单易懂？
代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
是否存在多余的或是重复的代码？
代码是否尽可能的模块化了？
是否有可以被替换的全局变量？
是否有被注释掉的代码？
循环是否设置了长度和正确的终止条件？
是否有可以被库函数替代的代码？
是否有可以删除的日志或调试代码？
安全
所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？在哪里使用了第三方工具，返回的错误是否被捕获？
输出的值是否进行了检查并且编码？
无效的参数值是否能够处理？
文档
是否有注释，并且描述了代码的意图？
所有的函数都有注释吗？
对非常规行为和边界情况处理是否有描述？
第三方库的使用和函数是否有文档？
数据结构和计量单位是否进行了解释？
是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？
测试
代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
单元测试是否真正的测试了代码是否可以完成预期的功能？
是否检查了数组的“越界“错误？
是否有可以被已经存在的API所替代的测试代码？。