一、项目需求(0.5天)
要做一个数据库分发、同步工具，有一个数据库是源，有数目众多的同步目标数据库，定期将数据进行分发同步。时间要求：1周。技术选型不限。要求高性能。
二、初步设计(0.5天)
这个需求没有特别复杂的业务，也没时间去画图、写文档做设计。
开始考虑各大概思路就要干活了，否则一周时间没有保证。
1、无人值守定时执行使用Quartz
2、增量同步任务设计，使用时间不确定的执行时间点来自动管理。对于源数据，都有一个更新时间，一更新时间为依据，去每次要更新数据的时间点就可以了，就像一个刻度尺，上面有刻度0、1、2、3......n，第一执行（0-1），第二次执行（1-2），每次执行完就记录下就记录下去源数据的时间点到一个同步日志表，并记录下成功失败的状态和执行点。
（实际上设计的很自动化，对日志表数据自动判断处理，对真正做到数据的正确分发与同步）
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做一些看起来很简单明了的文档，尤其是用例图、活动图、状态图。用例一般是全画，活动图和状态图，挑复杂的画就是了。这样到最后开发完了补文档也不是难事。
本文转自 leizhimin 51CTO博客，原文链接：http://blog.51cto.com/lavasoft/186108，如需转载请自行联系原作者
