前阵子，同事发现一个我年初写的一个 lib 中有一个 bug。并向我报告了错误现象。
然后我就去修复这个 bug。最后仅仅改动了一行代码便攻克了，解决完 bug 发现一上午就这么过去了。
好吧。一上午仅仅修复了一个 bug。并且仅仅改了一行代码。究竟发生了什么。时间都去哪里了？回顾下整个过程，因为这个 lib 开发于半年前当我再回去定位 bug 时花了一点时间来回顾整个 lib 的代码结构设计。
然后找到了出问题的代码所在的类，但我没有立马着手改动代码。而是先在 lib 的单元測试集中新写了一个单元測试。单元測试构建了该 bug 的重现场景。并顺利让单元測试执行失败了，然后我再開始去改动代码，并找到了出问题的那一行，改动后又一次执行了单元測试集并顺利看见了绿条。
作为一个公共 lib，改动完毕后我还要为本次改动更新公布版本号，编写相应的文档，并上传到 maven 仓库中。才算完毕。
回忆一下，发现时间主要花在了构建重现 bug 的測试场景中，有时为了构建一个測试场景编写代码的难度可能比开发功能本身更困难。
前面说了个修复 bug 的样例，尽管仅仅是改了一行代码却有这么多事要做。但就算在开发新功能时一样要为主要场景编写单元測试，还要考虑很多其它的问题，比方有时在编程时会陷入冥想，但想的未必是深奥的算法问题，非常多时候是在想一个好的名字（类名、方法名、变量名），好名字省去了非常多凝视不是么？
编程就是把人类的思维、设计、语言、逻辑和精神创造以一种计算机能够识别和储存的方式记录下来。程序猿干的就是这么个活。当你终于坐在电脑前准备敲下代码时。已经到了最后的阶段，不仅要完整的记录下来，并且相同的事用更少的代码来完毕就更好，这也是我们不断重构和优化代码实现的意义。更少的代码让我在半年后用更短的时间又一次把它们载入进了我的头脑中。所以编程速度慢下来并非坏事。
以下是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和很多其它走在这条路上同行者交流，有兴趣可关注一下，谢谢。
