开发了很久，经常会遇到开始一个很清晰的项目，经过几个人维护，或者开发一段时间，就变得难以维护，一直在填坑。经过一段时间，回头看自己的代码也感觉很尴尬。我看了很多开源的项目。像spring、mybatis、dubbo这种架构，在我们的传统开发项目中并不太试用。
最后感觉其实很多时候没有什么最好和优雅，风格一致就是最好的。不要乱，代码可读性高。
下面说几个可读性高的技巧，
1.选择一套框架，阿里系，或者什么都好。
2.配置文件方式，javaconfig方式，数据库配置方式，采用统一的规则。
3编写框架时候，最好有一个良好的流程。这样别人重点 理解core就好了。就像spring核心是bean、shiro核心是认证授权、mybatis核心是文件解析自动装载返回值。
设计技巧：
数据主要有两大类：基础数据，运行数据。
基础数据：各种台账：人员、商品、地址、设备表。
运行数据：订单、车辆实时动态、风机运行数据。
基础数据：基本上都是增删改。而且用的比较频繁，改变频率较低、缓存他们得到较好的收益。
运行数据：有分为两种：历史数据和实时数据（近期数据）。
运行数据通常都有一定的时间特性。可以根据业务开始的时候设计分不分表（后期可以深很多事）。
实时数据具有很强的流动性，可以进行缓存，历史和实时可以分表或者分库设计（可以减少数据库压力）。
而且有了历史数据，很多问题变得很简单。比如说报表、登录失败次数（不设计登录历史数据的时候，需要用代码计数很麻烦）、IP地址变动。
总结一句话：历史记录作用大、只要压力不太大。（只要数据库压力不是瓶颈的时候，都应该保存）
在说一个传统企业的问题：
传统企业最多的就是不同维度的数据统计：设计的时候有一个关键点。就是粒度。
粗粒度很好实现，细粒度更易扩展。
举个例子：车辆的运行数据，具有地理和时间两个维度。这两个维度可以做出很多统计。
地理维度又分为：省、市、县
时间维度：年、月、日、时、分、秒z但你的数据库要是县级的，就需要知道每个省具有哪些县，具有哪些市。
经过项目的积累，我发现，最好的办法是对基础运行数据，保留县级，保不齐那天领导要看各县的数据。
可以建立市、日级的统计表。每天每个市的统计数据。用spring quartz、进行定时更新（一天一次，压力不大）。
不要为每一种维度建立统计表，后期很难维护，同时数据的计算结果准确性难以保证。
总结一句话、粒度最要要保存，统计粒度中间好。