1. 滥用 getter、setter 方法
在设计实现类的时候，除非真的需要，否则尽量不要给属性定义 setter 方法。除此之外，尽管 getter 方法相对 setter 方法要安全些，但是如果返回的是集合容器，那也要防范集合内部数据被修改的风险。
比如：一些基于配置文件加载后写入集合容器的对象，不应该开放可改变的setter/getter方法，因为从一开始定义的时候就确定了他们是不变的。
2.Constants 类、Utils 类的设计问题
对于这两种类的设计，我们尽量能做到职责单一，定义一些细化的小类，比如RedisConstants、FileUtils，而不是定义一个大而全的 Constants 类、Utils 类。除此之外，如果能将这些类中的属性和方法，划分归并到其他业务类中，那是最好不过的了，能极大地提高类的内聚性和代码的可复用性。
目前项目中对这种设计应用的不是很好，Constants只有一个大的类，而utils相对好点，划分出了 FileUtils、XmlUtils（前者用于上传下载，后者用于反序列化xml与序列化java类）等。
3. 基于贫血模型的开发模式
贫血模型的开发模式是彻彻底底的面向过程编程风格的。这是因为数据和操作是分开定义在 VO/BO/Entity 和 Controler/Service/Repository 中的。
目前面板项目的做法和贫血模型基本无二，不同的层有不同的entity，虽然不叫VO、BO，但是作用一致。项目自下而上有 mapper.xml -> mapper.java -> dto.java -> dao.java 、dto.entity -> dao.java -> service 、service.entity-> controller 、resultMessage、requestMessage。