重大的科学技术突破没有什么神奇的， 在其背后， 是将知识、方法、想象力、行动、尝试、测试反复无尽地投入的过程。
编程是一场思维与意志的战争，是与自己思维缺陷不断抗争的过程。解决问题，引起新的问题，再消解问题，一步步小心地缩小问题的生存空间，直到幸运地发现问题能缩减到可以接受的范围，或者郁闷地发现问题在逐级扩大无法收拾只得从头再来。思维能力和意志力有多强大，决定了编程能力所能达到的高度。
最开始， 热情是 100%， 投入工作。 随着时间的推移， 热情逐渐降低， 任务也趋于完成状态。 当热情降到 60% 左右， 任务终于基本完成了， 意外发生了。
假设是在做数据订正脚本， 将多个集群的分数据库的数据合并到一个主数据库中。
1. 半路杀出个程咬金。 本来是负责5个表 A,B,C,D,E 的订正。 然而最近的项目又新增了一个表 C‘， （C 和 C’具有相似的字段， 但是针对不同的实体） ， 而且在数据订正所在项目之前上线（但是此时还没有上线， 因此线上没有相关数据参考）。 必须把这个表的合并工作考虑进去， 将 C 和 C‘ 均合并到主数据库的 C 表中； 此时， 还是有不少热情来完成工作的； No Problem.
2. 再一次完成后， 突然又被告知： C 表的线上集群的多个分数据库的一些主键数据重复（由于历史上的手工维护导致）， 合并时会导致冲突， 于是， 需要在主数据库的C表增加一个集群标识的字段区分出来。 再一次修改；
3. 再一次完成后， 与虚拟化网络团队的成员讨论发现， 将 C 和 C‘ 表合并， 与线上某个已知待解决的遗留问题结合， 会导致一些小概率的不可靠， 这些不可靠可能会导致大的网络故障。 经过讨论， 决定再增加一个字段来解决问题。 此时， 突然发现对 C 和 C‘ 表存在着重大的理解错误。 原来以为 C‘ 表的主键是包含在 C 表中， 现在发现是完全无交集的关系。由于相关项目还没有上线， 无法抓取线上进行验证， 只能采用潜规则和人工沟通的方式来确认。毫无疑问， 这需要一次较大的改动。
4. 数据合并订正是必须考虑合并验证、回滚和回滚验证的。 数据验证分单表数据验证和表关联数据验证。回滚是将主数据库对应于每个集群的分数据库的数据重新迁移到原来的分数据库。每一次改动， 都必须确保“合并、 合并后验证、 回滚、 回滚后验证”均正确无误。并且， 由于涉及到的是客户的敏感数据， 几百万条数据， 只要有一条数据订正出错， 都可能导致不小的故障。 必须一遍一遍地修改，运行验证程序， 查找数据验证失败的原因（由于线上数据存在脏数据， 出现若干条数据验证失败是很容易的， 需要程序具有很好的健壮性和容错能力）， 修复， 再验证， 再修复， 再验证， 就像改论文、拍电影一样， 几个步骤翻来覆去， 真是令人头晕目眩， 思绪混乱， 濒临崩溃。即便如此， 也无法保证绝对不出问题。与此同时， 还需要负责一个重要系统的维护和技术支持， 时不时有一些其它事务打断。
5. 凭借最后的热情， 终于再一次完成。 由于部署上线要通过 DBA 系统来创建新表。 问题又出现了： 由于 D 表的字段 usage 与 mysql 关键字冲突， 该字段被 DBA 系统直接屏蔽， 不可以使用， 因此， 必须将主数据库的 usage 字段改成其他字段。 新一轮的修改又要开始了。
6. 细节问题。 一些特殊值， 比如 NULL， 在 mysql 与 python 之间的转换， 从 mysql 取出的 NULL， 在 python 会变成 None , 如果不小心， 插入到 MySQL 就会变成 ‘None‘ ， 而不是 NULL， 这会导致某些查询失效。
也许无需多言， 你已经经历过类似的“折磨”。 有时技术的强弱并不是最重要的， 耐心和意志反而是最关键的。就像马拉松一样， 速度并不是最重要的， 耐心、策略和坚持才是最有力的品质。
代码已经不那么重要了，重要的是，在你的脑海里，内心里，灵魂里，孕育着怎样的图景。你所见的，不再是电脑与代码，它们只是思维粒子，蕴酿，冲突，碰撞，迸发出最终的火花。