谈到创新， 通常会让人想到， 如何绞尽脑汁地去想出一个美妙的创意。 不劳您费神， 现实自然有很多问题有待求解。
何谓不同寻常 ？
举例一， 要做一个针对订单和用户的增删查改的功能， 当然， 对于做了半年开发的你也不是什么难事。 那么， 如果又做要针对订单的管理， 针对产品的配置管理， 很快就会面临一大堆类似的需求。 怎么办？ 花费相同的气力， 一次次重复吗？
能否做一个带搜索的增删查改的分页数据控件组件， 具体的业务只需要少量的配置和方法填充就可以很轻易的完成 ？
从具体到通用， 这是一个不同寻常之处。
举例二， 大多数系统都配置了数据库，这很简单，放在 Spring 配置文件里，一切交给 Spring 就可以了。对于产品运维系统来说，往往要涉及多个数据库连接，必须做到动态切换和访问多个数据库，怎么办？
一个监控API， 可以根据传入的监控组名称及指定时间段返回相应的监控项数据， 比如 query('cpu') 可以返回 CPU_USER, CPU_SYS, CPU_WAIT, CPU_IDLE; query('mem') 可以返回 MEMTOTAL，BUFFER，CACHED， FREE， query('disk_io_speed') 可以返回 rkb, wkb , query('net_traffic') 可以返回 RECV_BYTES, TRANS_BYTES 等, 那么，你必须根据用户的需求，解析数据并生成报表类似如下
CPU_USER CPU_SYS CPU_IDLE MEMTOTAL FREE rkb wkb RECV_BYTES TRANS_BYTES
但你并不清楚用户的需求。可能有的用户对 CPU_USER CPU_IDLE , rkb, wkb 感兴趣， 有的用户对 RECV_BYTES, TRANS_BYTES 感兴趣。 你必须找到一种方式， 能够允许用户做些配置， 生成用户感兴趣的监控项的报表。 如何做 ？
从静态设置到动态配置， 这是一个不同寻常之处。
举例三， 一个数据库的流量表， 有 ip 地址, port 端口和 bps 流量数据 三个字段。 要找出记录中 bps 最大的 十个不重复的 ip:port 。 当然， 这不是什么难事。
select distinct vip from (select concat(ip, ':', port) vip from table order by bps desc ) vips limit 10
如果这个表有 1000W 级别的记录数呢， 那么上述 SQL 将会运行 50s 左右。 你有能力优化它， 或者用更快的方案来解决这个问题吗？
从小数据集处理到大数据集处理的性能问题， 这是一个不同寻常之处。
举例四， 你需要绘制一个VIP 随时间变化的流量曲线图， 然而，不同VIP 的流量值范围分布很广泛。 有的 10 - 100 之间， 有的 10000-100000 之间， 有的甚至 10000 - 10000000。 刻度设置小了， 大的流量值无法显示（尤其是值得关注的峰值）， 设置大了， 小的流量值又变成了直线。 如何设置你的刻度，使之适应如此广泛分布的值范围？
游戏服务器对外提供24小时不间断的服务； 最初容纳100个人在线游戏； 然而，突然有一天用户人数激增， 结果服务器不堪重负， 原来的程序无法容纳这么大的游戏用户容量； 短时间修改又不可能， 程序是否能够通过仅仅部署多台分布式的服务器就直接增强其处理能力 ？ 換句话说， 程序具有弹性么 ？
从固定僵硬到弹性适应， 这是一个不同寻常之处。
举例五， 你需要访问多个集群的数据库去访问某些记录， 最初， 集群较少， 处于安全和简单考虑， 采用了串行访问的方式。 然而， 随着集群的增加要访问的数据库也越来越多， 查询性能直线下降； 于是， 你希望采用并发访问的方式， 这样， 多个数据库的总访问时间大约缩减到1-2个数据库的访问时间了。
从串行执行模式到并发执行模式， 这是一个不同寻常之处。
举例六， 做 GUI 程序是很繁琐的，界面要调整到比较赏心悦目的程度会耗费很多时间和精力； 能否将一些通用的排版策略抽离出来，做到通用组件中，其它组件直接继承该通用组件，就能复用其排版设置，最大程度减少界面排版的工作量； 此外， GUI 测试也是个很麻烦的事情，难以像后台程序那样做自动化的测试。 那么， 如何做到GUI测试的自动化呢？
从琐碎随意到自动化与规范， 这是一个不同寻常之处。
问题往往是相互关联的。 大数据世界更期待动态、弹性适应能力， 并发执行模式， 自动化、规范地测试和运维 ， 要尽可能复用，这就要求对日常重复开发工作通用化， 一次解决， 使用多次。
具有挑战性的问题往往是创新的重要驱动力。 发现不同寻常的问题， 踏上创新式开发之旅。