最近的审查项目、代码检查存在以下问题。

1、使用Map和Json对象参加了。 为了便于后期的维护和阅读，建议使用对象作为参与者

2、建议直接使用语义不明的0、1数字作为比较条件，将语义不明的数字条件声明为有意义的应用常数(用final限定)。

3、将super_admin、admin、user等具有同种意义的字符串直接用于条件比较。 多次使用同一字符串时，容易发生打错，程序会出错。 因此，建议在枚举类中声明同类型含义的字符串常量，使用时统一使用枚举。 避免错误

4、分页时，采用类似meetings.sublist (0，10 )的方法进行分页。 这样，即使将满足条件的所有数据调查到存储器中，结果也只会使用一部分，导致资源的浪费。 将分页查询放置在数据库查询中时，最好尽可能减少数据库服务器的IO，合理使用数据库资源。 这有助于APP应用程序的顺利执行。

5、过多的地方重复使用同一个评论。 严重的代码冗余可以将注释统一标记在类头上，也可以在配置文件中统一放置。

6、日志打印记录少。 System.out.println ()； 的打印输出方式。 然后，在关键或认为容易出错的地方适当添加日志，方便错误的故障排除。

7、异常打印时请勿使用e.printStackTrace ()。 建议使用log.error )、e )。

b .对不确定的代码进行try-catch捕获，处理潜在的异常，进行日志打印处理，有助于排除错误。

c .具体如何处理异常，应该根据不同的业务需要和异常类型进行处理。

字符串获取消息(； 获取异常详细信息的字符串地理信息(； Sting toString (； 返回关于异常的简单说明。 void printStackTrace (； 例外和他调用堆栈信息向标准错误流添加getClass ()； 返回不应该在代码中写入常量信息，如对象8、文件存储路径等，以指示此对象属于哪种类型。 您需要创建配置文件，以配置文件的形式更易于维护，并更易于部署。

总结：本次项目暴露出的问题有代码结构不够严谨、命名不够规范、工具类的使用不够娴熟(使用量少)等问题。 如果代码可扩展性差，则后续维护和扩展需要花费时间，因此在编码前必须考虑是否适合业务场景、是否可行、其编码方法是否合理。多想多问多讨论。使用和熟悉更多单元测试，增强界面健壮性，加强对日志打印粒子读取的掌握，减少错误检查时间，减少绕路。

转载于：https://www.cn blogs.com/Cai JH/p/8457702.html