我的睡眠不好,由来已久。
最近一个月,迭代开发工作紧张而忙碌着。像我这种神经敏感的人,对于碰到的问题不分时间地点地思考,有一种脱离现实世界的感觉。太沉浸 于一个事情中,容易忘掉其他好多的事情,大脑的容量似乎就那么小,它还不如一台计算机的内存呢,一直不会升级。相反,它会逐渐地老 化。
代码写了又删,删了又写,简了又简,重构了再重构。我是一个天生爱追求完美的人,把代码看作是一种作品,各种精挑细研的方法都用着 。这样,别人看得懂,自己看得懂,问题又少,维护的成本代价也不会大。当然,前提条件是你必须把前期的coding工作做得非常好,留给 自己充分的时间来编码、测试、重构,业务功能要不停地梳理,功能代码要不断地clean up。好多复杂的业务逻辑,要么你没有梳理透彻, 要么你没有优雅地实现。
不同与以往的开发过程,我在这次中尝试着使用了不完善的TDD方法,总体效果不错。所谓不完善的,指我并没有完全地套用TDD的流程; 相 反地,开发前期我还是小步快跑,快速搭建出了基本功能的框架,让基本功能行得能了。接下来,逐个场景用例覆盖,书写用例,验证功能的 正确性。在场景验证的过程中,来发现之前分析的空白或盲点,补充场景,书写用例,如此循环。
除此之外,反复阅读你的代码。带着怀疑的态度支阅读你的代码,至少三遍,多问问自己:
-
我读得懂吗?
-
逻辑对吗?
-
实现复杂不?
-
能不能再简单点?
-
别人读得懂吗?
-
好维护不?
对着每行代码,写测试用例来覆盖。首先要相信计算机,接着要敢于质疑自己,再次要赶紧动手去做。实践是验证真理的唯一方法。
我觉得,以后开发工作可以继续使用这种工作方法。它的好处在于,用test case来驱动开发功能,用test case来保证已有代码功能的 正确性;代码弥补了场景和用例,用例验证了功能。当然,这需要你的管理者留给你足够的时间做这些事情。
哎,发现写着写着,又回老本行了。本来是要说说让自己慢下来的原因,跑题了。还好,这半个小时我慢了下来,大脑运转慢下来,身体 放松下来了。慢下来,放松,就会有更好的想法水到渠成。
我不是一台计算机,我需要时间来整理自己,更需要时间来反省自己。
我不是一台计算机,我不希望像它一样留不下来地空转。我需要时间停下来,回头看看自己的足迹。
让我慢下来,让我放松下来,我才会有更好的状态。