代码评审

一、异常处理 1、【强制】Java 类库中定义的一类 RuntimeException 可以通过预先检查进行规避，而不应该 通过catch 来处理，比如:IndexOutOfBoundsException，NullPointerException等等。 2、【强制】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低。 3、【强制】对大段代码进行 try-catch，这是不负责任的表现。catch 时请分清稳定代码和非稳 定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的catch尽可能进行区分 异常类型，再做对应的异常处理。 4、【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请 将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的 内容。 5、【强制】有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回 滚事务。 6、【强制】finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。 7、【强制】不能在 finally 块中使用 return，finally 块中的 return 返回后方法结束执行，不 会再执行 try 块中的 return 语句。 8、【强制】捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。 ?>

原文： https://www.cnblogs.com/xuecaichang/p/10265936.html 目录 传统运维与自动化运维的区别 CMDB包含的功能 CMDB实现的四种方式 1、agent方式： 2、 ssh类（parmiko, frbric,ansible) 3、saltstack方式 saltstack的安装和配置 1安装和 配置 2、授权 3、执行 命令 AES介绍： CMDB数据表的设计： 图表的设计 前端代码的实现 1、相关文件的引入 2、代码初始化 3、Js代码 CMDB https://lupython.gitee.io/2018/05/05/CMDB%E4%BB%8B%E7%BB%8D/ 尚泽凯博客地址 Top 传统运维与自动化运维的区别 传统运维： ​ 1、项目 上线： ​ a.产品经理前期调研（需求分析） ​ b.和开发进行评审 ​ c.开发进行开发 ​ d.测试进行测试 ​ e.交给运维人员进行上线 上线： ​ 直接将代给运维人员，让业务运维人员把代码放到服务器上 痛点 ： ​ 曾加运维人员的成本 改进： ​ 搞一个自动分发代码 的系统 ​ 必须的条件： ​ 1、服务器的信息（ip,hostname等 ) ​ 2、 能不能把报警自动化 ​ 3、 装机系统： ​ 传统的装机和布线： idc运维： ​ 用大量的人力和物力，来进行装机 自动化运维：

一. （1）结对成员 　　　　4班 张洋洋 - 4班 赵东旭 二. （1）结对成员的博客链接地址 　　 https://www.cnblogs.com/nihenpiaoliang/p/11726543.html （2）代码审查结果表 1. 张洋洋的代码审查表（由赵东旭完成） 类别 审查项 结论 重要性 程序的版式 空行是否得体？ 是 代码行内的空格是否得体？ 是 一行代码是否只做一件事？如只定义一个变量，只写一条语句。 是 重要 If、for、while、do等语句自占一行，不论执行语句多少都要加 “{}”。 是 重要 注释是否有错误或者可能导致误解？ 否 命名规则 命名规则是否与所采用的操作系统或开发工具的风格保持一致？ 是 重要 类名、函数名、变量和参数、常量的书写格式是否遵循一定的规则？ 否 重要 程序中是否出现相同的局部变量和全部变量？ 是 静态变量、全局变量、类的成员变量是否加前缀？ 是 表达式与基本语句 如果代码行中的运算符比较多，是否已经用括号清楚地确定表达式的操作顺序？ 是 重要 是否编写太复杂或者多用途的复合表达式？ 否 是否用隐含错误的方式写if语句? 否 Case语句的结尾是否忘了加break？ 否 重要 使用goto 语句时是否留下隐患? 例如跳过了某些对象的构造、变量的初始化、重要的计算等。 否 重要 常量 如果某一常量与其它常量密切相关

一. （1）结对成员 　　　　 4班 赵东旭 - 4班 张洋洋 二. （1）结对成员的博客链接地址 　 　　 https://www.cnblogs.com/zyyzy/ （2）代码审查结果表 1. 张洋洋的代码审查表（由赵东旭完成） 类别 审查项 结论 重要性 程序的版式 空行是否得体？ 是 代码行内的空格是否得体？ 是 一行代码是否只做一件事？如只定义一个变量，只写一条语句。 是 重要 If、for、while、do等语句自占一行，不论执行语句多少都要加 “{}”。 是 重要 注释是否有错误或者可能导致误解？ 否 命名规则 命名规则是否与所采用的操作系统或开发工具的风格保持一致？ 是 重要 类名、函数名、变量和参数、常量的书写格式是否遵循一定的规则？ 否 重要 程序中是否出现相同的局部变量和全部变量？ 是 静态变量、全局变量、类的成员变量是否加前缀？ 是 表达式与基本语句 如果代码行中的运算符比较多，是否已经用括号清楚地确定表达式的操作顺序？ 是 重要 是否编写太复杂或者多用途的复合表达式？ 否 是否用隐含错误的方式写if语句? 否 Case语句的结尾是否忘了加break？ 否 重要 使用goto 语句时是否留下隐患? 例如跳过了某些对象的构造、变量的初始化、重要的计算等。 否 重要 常量 如果某一常量与其它常量密切相关，是否在定义中包含了这种关系？ 是 重要

一、结对成员 胡昊 博客链接地址 点击此处跳转到胡昊的博客 二、结对互审表 内容 常恒代码（由胡昊复审） 胡昊代码（由常恒复审） 1.概要部分 1.代码是否符合需求和规格说明 是 是 2. 代码设计是否考虑周全 是 是 3. 代码可读性 代码可读性较高，思路清晰 注释全面 代码可读性较高 部分注释不清晰 4. 代码容易维护么 容易 一般 5. 代码的每一行都执行并检查过了吗 已成功通过执行并检验 已检查 2.设计规范部分 1.设计是否遵从已知的设计模式或项目中常用的模式 遵循已知的设计模式 已经遵循已知设计模式 2.有没有硬编码或字符串或数字等存在? 有 无 3.代码有没有依赖于某平台，是否会影响将来的移植(如Win32到Win64)? 否，不影响 否，不影响 4.有没有无用的代码可以清除? 有，较少 存在，但无用代码不多 3. 代码规范部分 1.大小写是否区分 是 是 2.是否有相关注释 是 是，只有部分注释 3.是否分行 是 部分未分行 4.是否缩进 是 是 4. 具体代码部分 1.有没有对错误进行处理?对于调用的外部函数，是否检查了返回值或处理了异常? 进行了处理 检查了调用函数的返回值 处理了异常 对错误进行了处理 检查了返回值 处理了异常 2.参数传递有无错误，字符串的长度是字节的长度还是字符(可能是单1双字节)的长度， 无 无 3.边界条件是如何处理的? switch

一、结对成员 常恒 博客链接地址 　　https://www.cnblogs.com/changheng/ 二、结对互审表 内容 常恒代码（由胡昊复审） 胡昊代码（由常恒复审） 1.概要部分 1.代码是否符合需求和规格说明 是 是 2. 代码设计是否考虑周全 是 是 3. 代码可读性 代码可读性较高，思路清晰 注释全面 代码可读性较高 部分注释不清晰 4. 代码容易维护么 容易 一般 5. 代码的每一行都执行并检查过了吗 已成功通过执行并检验 已检查 2.设计规范部分 1.设计是否遵从已知的设计模式或项目中常用的模式 遵循已知的设计模式 已经遵循已知设计模式 2.有没有硬编码或字符串或数字等存在? 有 无 3.代码有没有依赖于某平台，是否会影响将来的移植(如Win32到Win64)? 否，不影响 否，不影响 4.有没有无用的代码可以清除? 有，较少 存在，但无用代码不多 3. 代码规范部分 1.大小写是否区分 是 是 2.是否有相关注释 是 是，只有部分注释 3.是否分行 是 部分未分行 4.是否缩进 是 是 4. 具体代码部分 1.有没有对错误进行处理?对于调用的外部函数，是否检查了返回值或处理了异常? 进行了处理 检查了调用函数的返回值 处理了异常 对错误进行了处理 检查了返回值 处理了异常 2.参数传递有无错误，字符串的长度是字节的长度还是字符(可能是单1双字节)的长度， 无

一、结对成员 胡昊 博客链接地址 　　 https://www.cnblogs.com/whohow/ 二、结对互审表 内容 常恒代码（由胡昊复审） 胡昊代码（由常恒复审） 1.概要部分 1.代码是否符合需求和规格说明 是 是 2. 代码设计是否考虑周全 是 是 3. 代码可读性 代码可读性较高，思路清晰 注释全面 代码可读性较高 部分注释不清晰 4. 代码容易维护么 容易 一般 5. 代码的每一行都执行并检查过了吗 已成功通过执行并检验 已检查 2.设计规范部分 1.设计是否遵从已知的设计模式或项目中常用的模式 遵循已知的设计模式 已经遵循已知设计模式 2.有没有硬编码或字符串或数字等存在? 有 无 3.代码有没有依赖于某平台，是否会影响将来的移植(如Win32到Win64)? 否，不影响 否，不影响 4.有没有无用的代码可以清除? 有，较少 存在，但无用代码不多 3. 代码规范部分 1.大小写是否区分 是 是 2.是否有相关注释 是 是，只有部分注释 3.是否分行 是 部分未分行 4.是否缩进 是 是 4. 具体代码部分 1.有没有对错误进行处理?对于调用的外部函数，是否检查了返回值或处理了异常? 进行了处理 检查了调用函数的返回值 处理了异常 对错误进行了处理 检查了返回值 处理了异常 2.参数传递有无错误，字符串的长度是字节的长度还是字符(可能是单1双字节)的长度， 无 无

为便于规范各位开发人员代码、提高代码质量，研发中心需要启动代码评审机制。为了加快代码评审的速度，减少不必要的时间，可以加入一些代码评审的静态检查工具，另外需要为研发中心配置统一的编码模板和代码格式化模板。 Java代码规范、格式化和checkstyle检查配置文档下载地址： http://www.blogjava.net/Files/amigoxie/Java 代码规范、格式化和checkstyle检查配置文档.rar 1 、配置统一的编码模板 1.1 配置编码模板 在 Eclipse 或 MyEclipse 中点击 Window -> Preferences 菜单，点击左侧的“ Java ” -> “ Code Style ” -> “ Code Templates ”，界面如下图所示： 点击上图右侧的“ Import ”按钮，在弹出的文件选择窗口选择公司自己的编码模板，例如 eclipse_templates.xml 文件（仅提供参考，可自行修改）。在“ Configure generated code and comments ”区域有“ Comments ”和“ Code ”两个菜单，点开后可以看到各种类型的注释和编码模板定义： 可以点击上面的各种类型查看该模板文件的定义。 例如文件注释定义： 文件注释定义中的文件作者取自所在系统登录用户，若不正确时，可点击“ Edit

一个项目不可能没有工具类，工具类的初衷是良好的，代码重用，但到了后面工具类越来越乱，有些项目工具类有几十个，看的眼花缭乱，还有不少重复。如何编写出好的工具类，我有几点建议： 隐藏实现 就是要 定义自己的工具类，尽量不要在业务代码里面直接调用第三方的工具类 。这也是 解耦 的一种体现。如果我们不定义自己的工具类而是直接使用第三方的工具类有 2个不好的地方 ： 不同的人会使用不同的第三方工具库，会比较乱。 将来万一要修改工具类的实现逻辑会很痛苦。 以最简单的字符串判空为例，很多工具库都有 StringUtils工具类，如果我们使用commons的工具类，一开始我们直接使用 StringUtils.isEmpty ，字符串为空或者空串的时候会返回为true，后面业务改动，需要改成如果全部是空格的时候也会返回true，怎么办？我们可以改成使用 StringUtils.isBlank 。看上去很简单，对吧？ 如果你有几十个文件都调用了，那我们要改几十个文件，是不是有点恶心？再后面发现，不只是英文空格，如果是全角的空格，也要返回为true，怎么办？StringUtils上的方法已经不能满足我们的需求了，真不好改了。。。 所以我的建议是，一开始就自己定义一个自己项目的StringUtil，里面如果不想自己写实现，可以直接调用commons的方法，如下： public static boolean

Code reviews 确实有很多用处，而在实际工作中它被用来找到程序bug、保证代码风格、编码标准。过于负担了。 它不应该承担发现代码错误的职责，而是审核代码的质量，如可读性，可维护性，健壮性以及程序逻辑对需求的实现正确完整性。程序中的bug应该由单元测试、集成测试、性能测试、系统测试、回归测试来保证的，其中主要是单元测试是最重要的环节，因为那是最接近Bug，也是Bug没有扩散的地方。 它不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。 今天，在中国的很多公司里，上面这两件事依然被认为是Code Reivew最重要的事，但在实际工作中够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试。对于代码规范，这应该是程序作者自己需要保证的，而且有一些工具是可以帮你来检查代码规范的。 上述言论并不是说，在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说，那并不是Code Review的意图。 如何使Code Review更有意义。 经常进行Code Review。就好像人家都把整个房子盖好了，大家Review时这挑一点、那挑一点