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