一、项目需求(0.5天)
 
要做一个数据库分发、同步工具,有一个数据库是源,有数目众多的同步目标数据库,定期将数据进行分发同步。时间要求:1周。技术选型不限。要求高性能。
 
二、初步设计(0.5天)
 
这个需求没有特别复杂的业务,也没时间去画图、写文档做设计。
开始考虑各大概思路就要干活了,否则一周时间没有保证。
 
1、无人值守定时执行使用Quartz
2、增量同步任务设计,使用时间不确定的执行时间点来自动管理。对于源数据,都有一个更新时间, 一更新时间为依据,去每次要更新数据的时间点就可以了,就像一个刻度尺,上面有刻度0、1、2、3......n,第一执行(0-1),第二次执行 (1-2),每次执行完就记录下就记录下去源数据的时间点到一个同步日志表,并记录下成功失败的状态和执行点。
(实际上设计的很自动化,对日志表数据自动判断处理,对真正做到数据的正确分发与同步)
3、使用线程池,减少JDBC连接的次数。
4、使用多线程池,一个数据库一个线程,进行数据分发同步操作。
5、使用批处理获取分批记录(任务)(每次比如100条),获取完成后保存到集合中,然后对将任务逐条发给每个数据库同步线程执行,同步线程, 根据任务数据的ID在其目标库上找对应的数据记录,如果找到就更新,找不到就插入。-----使用JDBC查询结果集的更新、插入操作,一次性完成这样的 任务,可以大幅提高数据同步的效率,这是非常关键的优化。
6、每个数据库如果有一条同步失败(可重试3次),则不在执行同步线程任务了,并记录日志到到日志表。等下次执行时候重新执行。
 
 
二、写简单的单任务测试(1天)
 
通过对一个数据库的操作,来验证上面的设计的合理性。
 
三、“礁点”都清楚了,放开手写代码(1天)
 
“礁点”都清楚了,思路也明确了,写代码如探囊取物一样容易,写程序最怕的是你在写代码的时候还没考虑清楚业务,还不知道技术风险,还不知道实现思路。即使这些问题不是100%的明确,也应该大体上明确才行。 ------想好了你在干,绝对不耽误事!
 
整个代码量在一千行以内(连getter/setter都算了),核心类只有两个,一个是系统置工具,实现可谓相当简洁,如果按照代码量计算工作量,我该哭了!
 
四、测试(0.5天)
 
测试实际上是和开发同步进行的,写一个功能块后我都会做个简单测试,看看有没有问题,如果没有,继续写别的,最后组装时候很轻松,因为没个模块都是可运行的。
 
做了一个100万的数据量的同步分发测试,同步分发给两个库,程序正常执行。而实际上的数据目前还不到1万条,而且这些数据增长很慢很慢,一年一万条撑死了。我做100万的同步测试至少可以满足程序跑一百年!
 
五、检查代码、梳理程序、写点文档(0.5天)
 
程序写完了,对代码做点注释,能做优化的做点优化,也是个检查过程。
最后写个简单的文档,使用了什么第三方的包、环境配置、开发时间、作者等,再写个简单的使用说明就ok了。
 
剩下时间就是你自己的了,放松放松,总结学习。
 
六、总结:
 
整个项目周期一个人4天就搞定了。
 
1、作为一个开发人员,必须要进行业务分析,并作出设计思路,这个设计甚至没有图纸,没有文档,就是大脑中的一个构思也罢,总之不能少。
 
2、对设计进行合理性分析,技术风险分析,任务量分析等等,并尽早找出“礁点”,该化解的化解,该逃避的逃避,免得毫无准备的情况下触礁翻船,这样代价太高了。
 
3、开发过程注重测试,不想提什么测试驱动开发,容易让人感觉到压力。测试不一定非要用个JUnit,通常写个main()就可以测试了,测试 完了后就删除了,因为没有人要我们的JUnit代码,工作量也不看这个,你的日志中也不会写你写N多的单元测试,呵呵。这些就灵活把握了,大项目一般都用 JUnit,小项目就很灵活了。
 
4、文档最后补,这和标准的软件开发的方法论似乎有悖,但是确实是没问题的。原因:
a、项目是否有足够的时间去完成需求?这个时间是否很充分?
b、需要什么文档?谁来做?多上时间?达到什么效果?
c、项目组的成员处于一个什么层次,总不能让那些连Hello World几种写法都看不明白的依葫芦画瓢的去写吧?他们需要的是一个套路,就像栽树一样,你把坑位定好,刨坑的刨坑、栽树的栽树、浇水的浇水,这活适合他们。可见一个项目组的带头人是多么重要!
d、其实没有看得见摸得着的文档,并不等于没有文档。只是文档还在设计师的脑子里呢,还没有print()出来呢,呵呵。
e、刚开始写文档,并不能很全面的把方方面面的都写出来,实现过程是一个迭代的过程,会持续的变更(可能变更很大),但文档谁来维护呢?因此在开发之初写文档要权衡考虑。
f、公司要文档吗?客户要稳当吗?要什么文档?如果不是必须的,能应付就应付,最好将文档烂自己肚子吧,没有人认为你写了文档就有功劳,有时间 好好总结下自己,总结下项目的得失,多钻研技术、管理、方法论等等也许对自己更好些。毕竟搞技术的,一切都在掌握之中,还担心什么呢?
g、在开发完成后写文档,时间上自由度最大,软件都出来了,功能都实现了,谁还会将焦点放到文档上呢?这时候写一切都是板上钉钉的东西,做都做好了,写就很容易了,以后也不用担心太大的改动。因此,很多时候项目快完了才补文档。
h、最后写文档也有不好的地方,刚开始的需求也许已经忘记了。对于复杂项目,刚开始不要做太多文档,最好使用UML做一些看起来很简单明了的文档,尤其是用例图、活动图、状态图。用例一般是全画,活动图和状态图,挑复杂的画就是了。这样到最后开发完了补文档也不是难事。