如果一个方法明确返回是与否这两种情况，那么没有必要返回字符串的0或者1。这样会造成很多地方需要使用 字符串的形式来匹配结果判断是与否。例如以下这种形式。 方法应该直接返回true或者false。 代码会简洁明了很多。

Poor有不好，差的意思。 例如My english is poor. 这里的Poor是差的意思。 但是下图这个方法getDatePoor。也用poor来表达获取时间“差”的含义。 英语还是程序员应该要掌握学习的。不能光靠机翻英语，不然容易闹笑话。

很多方法或者功能我们应该尽可能的搜索是否已经有开源成熟的jar包或者框架实现。成熟的开源jar包或者框架，有大量完备的测试以及广泛的用户来确保质量。 如果实在需要自己造小轮子，请使用单元测试来确保质量

大量的if-else语句，具体情况具体分析。但是大部分都可以用卫语句提前返回结果。避免大量嵌套。

例如左边的写法可以改为右边的写法

像下图这种情况可以用Stream Lambda来进行简化

优化后

有些时候可能会写出一些不必要的冗余判断

我们应该封装一部分代码细节，暴露出代码的主流程，优化后

像上图这种情形，我们其实可以使用一句Stream 语句就可以描述出来。

这样会造成布尔字段取出时，还需要跟字符串1或者0进行比对，这是很尴尬的设计。

我们捕获异常之后一般都需要使用log来记录错误情形，如果什么都不做，就很可能丢失错误信息，并且使代码排查过程更加困难。

使用Java是静态语言，使用Map填充数据，反而失去了静态语言带来了代码检查以及IDEA识别字段引用的功能。

请不用将项目中所有的常量一股脑的放到一个类中。

可以使用像这种静态类的方式，分门别类地放入不同的常量

有时候用1表示肯定，有时候用0表示肯定，有时候用Y表示肯定。

在外层方法判断一遍，在内层方法又进行一遍一样的判断

常量的命名请使用大写加下划线的格式

就一种case了 完全没有必要使用switch语句

例如项目中大量使用了“jpg”的字符串魔法值，使用魔法值使得我们无法统一找到代码的引用处。在重构的时候难免会有疏漏。

如果单个方法的代码行超过80行，意味你的代码缺乏封装和可读性。例如这种一大坨的代码。