案例二：定期自动更新宝宝年龄

1.模块概述

本模块功能如下：

1.宝宝年龄更新；比如宝宝8月份注册时1岁，生日8月8号，那么2018-8-8更新为2岁；

2.模块设计

2.1.功能模块

2.1.1.定期更新宝宝年龄

宝宝信息表baby_info：

宝宝id  | 名称name | 年龄age | 生日birthday

1          | lucy          | 1            | 2016-8-8                （注：当前日期是2017-8-12）

方案一：

服务器端启动定时任务：

1)每天定时扫描baby_info表；

2)读取birthday字段，与当前日期比较；

3)如果当天（2018-8-8）是宝宝生日，则更新baby_info，age+1=2岁

点评：

此方案逻辑正确，实现简单，可以实现宝宝年龄每年正确更新。

评审意见：

1. 新手很容易想到这样的思路，一般就直接开始写代码实现了，并一边实现，一边去考虑实现难点了。比如：定时任务库，生日判断方法等，直接钻进实现去了。

2. 功能实现了，测试没有bug，这个任务就完成收工，也再也不会想起优化了。

3. 直到某一天数据库中宝宝数量突破万级，定时任务执行效率极低，这时想到需要优化性能；

4.优化性能时又想到方案了，分布式：多几台服务器，多几个定时任务，每个任务扫描2000个宝宝信息；好了思路OK了，开始代码实现，性能测试又OK，任务收工，满足的泡一杯咖啡。这是大部分程序员的缩影！

再点评：

感觉没有什么不对哦。

难道是：方案一设计时就考虑多任务多线程等；不必等后面性能问题暴露了再改；

其实不然，而是再收到任务需求时，就应该停下来好好思考下，莫急于编代码！

多一点思考和分析，好一点的方案才是好程序的根基。

功能分析：

1.宝宝信息表baby_info中的宝宝数量只会越来越多，逐条扫描必定会效率低下，很快会遇到性能瓶颈；

2.宝宝生日是2016-8-8，则1岁是2017-8-8，下一年是2018-8-8；也就是2017-8-8更新年龄1岁后，下一次生日就是2018-8-8；

lucy 2016-8-8   1岁2017-8-8  2岁2018-8-8

jane 2016-8-10  1岁2017-8-10  2岁2018-8-10

3.上面的分析有发现什么特点没有？

1)不同生日的宝宝，更新年龄不在同一天；也就是分布在365/366天里面；

2)每次生日更新都是下一年。

有没有触发你什么灵感？

---

评审改进：

方案二：

1.改进宝宝信息表baby_info：

宝宝id  | 名称name | 年龄age | 生日birthday | 下一次生日next_birthday

1          | lucy            | 1           | 2016-8-8       | 2018-8-8

2          | jane            | 1           | 2016-8-10     | 2018-8-10

2.宝宝注册时，初始化下一次生日日期；

3.启动定时任务：

1)每天定时从baby_info表中筛选去next_birthday等于当天的记录；

2)这些宝宝当天为生日，更新年龄age+1；

3)并计算出下一次生日日期，更新next_birthday；

点评：

新方案优势：

宝宝生日的更新分散到365/366天里面去了；定时任务执行只会扫描当天生日的宝宝，非当天生日的宝宝都过滤掉了，这样扫描的记录就少了很多。

至此评审结束。

结束语：

程序设计是一场逻辑思维的旅程，在code之前，停下脚步，好好思考，好好想想多个方案，写出来。

更好的程序，来源于更好的设计。