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