近期考核项目，代码走查中存在如下问题：
1、入参使用了Map和Json对象。
建议使用对象作为入参，方便后期维护和阅读
2、直接使用意义不明确的0、1数字作为比较条件
建议将意义不明确的数字条件声明成有意义的应用常量（用final修饰）。
3、直接将super_admin，admin，user等此同类型有含义的字符串用于条件比较。
在多次使用相同字符串的时候，容易出现打错的情况，导致程序错误。所以建议将同类型含义的字符串常量用枚举类声明，用的时候统一使用枚举。规避错误
4、做分页的时候，使用类似meetings.subList(0, 10)的方法进行分页。
这样做，把所有符合条件的数据都查到内存中，结果只是用的一部分，造成资源浪费。建议把分页查询放在数据库查询时尽可能的减少数据库服务器的IO,合理使用数据库资源，有利于应用的平稳运行。
5、过多的地方重复使用相同的注解。
严重的代码冗余，可以把注解统一标注在类头或者通过配置文件统一配置。
6、日志打印记录较少。
不要使用System.out.println();的打印输出方式。然后在关键之出，或者觉得容易出错的地方适当增加日志记录，方便错误排查。
7、异常打印时避免使用e.printStackTrace()
a.建议使用log.error("异常",e);
b.对不确定的代码应加上try-catch，捕获，并处理潜在异常，做好日志打印处理，为错误排除提供帮助。
c.具体如何处理异常应该根据不同的业务需求和异常类型去处理。
-
-
- String getMessage（）；获取异常的详细信息
- Sting getLocallizedMessage（）；获取用本地语言描述的详细信息
- Sting toString（）；返回对异常的一个简短的描述
- void printStackTrace（）；打印出异常和他调用栈信息到标准的错误流中
- getClass（）；返回一个表示这个对象属于哪种类型的对象
-
8、对于文件存储路径等常量信息不应该写死在代码中。
应该写成配置文件，然后通过配置文件的形式方便维护，更方便实施部署。
总结：
通过本次项目暴露出的问题，可以看出代码结构不够严谨，命名不够规范，工具类的使用不够娴熟（用的少）等问题。代码可扩展性差，会对后面的维护和扩展造成更高的时间成本，所以在编码前应该先考虑好是否符合业务场景，是否可行，这种编码方式是否合理。多想多问多讨论。还要多使用和熟悉单元测试，提高接口健壮性，增强对日志打印颗粒读的把握，减少错误排查的时间，少走弯路。