让自己慢下来，放松下来

我的睡眠不好，由来已久。

最近一个月，迭代开发工作紧张而忙碌着。像我这种神经敏感的人，对于碰到的问题不分时间地点地思考，有一种脱离现实世界的感觉。太沉浸 于一个事情中，容易忘掉其他好多的事情，大脑的容量似乎就那么小，它还不如一台计算机的内存呢，一直不会升级。相反，它会逐渐地老 化。

代码写了又删，删了又写，简了又简，重构了再重构。我是一个天生爱追求完美的人，把代码看作是一种作品，各种精挑细研的方法都用着 。这样，别人看得懂，自己看得懂，问题又少，维护的成本代价也不会大。当然，前提条件是你必须把前期的coding工作做得非常好，留给 自己充分的时间来编码、测试、重构，业务功能要不停地梳理，功能代码要不断地clean up。好多复杂的业务逻辑，要么你没有梳理透彻， 要么你没有优雅地实现。

不同与以往的开发过程，我在这次中尝试着使用了不完善的TDD方法，总体效果不错。所谓不完善的，指我并没有完全地套用TDD的流程； 相 反地，开发前期我还是小步快跑，快速搭建出了基本功能的框架，让基本功能行得能了。接下来，逐个场景用例覆盖，书写用例，验证功能的 正确性。在场景验证的过程中，来发现之前分析的空白或盲点，补充场景，书写用例，如此循环。

除此之外，反复阅读你的代码。带着怀疑的态度支阅读你的代码，至少三遍，多问问自己：

• 我读得懂吗？

• 逻辑对吗？

• 实现复杂不？

• 能不能再简单点？

• 别人读得懂吗？

• 好维护不？

对着每行代码，写测试用例来覆盖。首先要相信计算机，接着要敢于质疑自己，再次要赶紧动手去做。实践是验证真理的唯一方法。

我觉得，以后开发工作可以继续使用这种工作方法。它的好处在于，用test case来驱动开发功能，用test case来保证已有代码功能的 正确性；代码弥补了场景和用例，用例验证了功能。当然，这需要你的管理者留给你足够的时间做这些事情。

哎，发现写着写着，又回老本行了。本来是要说说让自己慢下来的原因，跑题了。还好，这半个小时我慢了下来，大脑运转慢下来，身体 放松下来了。慢下来，放松，就会有更好的想法水到渠成。

我不是一台计算机，我需要时间来整理自己，更需要时间来反省自己。

我不是一台计算机，我不希望像它一样留不下来地空转。我需要时间停下来，回头看看自己的足迹。

让我慢下来，让我放松下来，我才会有更好的状态。