技术奇异点

但凡经手的代码，我尽量令其严格遵守代码规范。看到写的里出外进的代码，比如操作符和括号两侧随机缺掉或者多出空格，连续七八行的代码各行之间都空行…… 都不禁感慨背后的作者到底是有怎样的心情和素养。随着经历的增长，这种感受也会发生变化。

几个月前进行了一次不算剧烈的 hackathon。说「不太剧烈」是因为这次实际上和正式做产品 feature 没有太大区别。做产品 feature 的第一步也是用最快速度写出来一个能运行的基本逻辑，然后再一点点通过 refactor 把代码变换成更清晰的逻辑和结构，逐步加上对 edge case 的处理。Hackathon 无非是多少省去了第一步之后产品化的步骤。如果实现正式 feature 的第一步不是 hackathon-like，那么多半后面要走更多弯路浪费工作。因为编程语言在一个 feature 实现的初期和后期作为工具的作用是不同的。在初期，对 feature 的设想处于探索阶段。编程语言的作用是验证头脑中的想法，揭露其中的逻辑漏洞，起 proof 的作用。后期的作用则是用清晰的代码为其它开发者（包括未来的作者本人）固化知识。前者像草稿纸，而后者的产物如同不必再次 peer-review 就可以被引用的正式论文。

在高强度的 hackathon-like 步骤中，经常发现自己也生产出「里出外进」的代码。临场感受和事后分析都告诉我，在这个时候去整理这种代码的危害大于收益。当然，在整个逻辑被证明基本稳定，开始 refactor 之后，就应该严格执行代码规范。不过我开始同情和原谅那些不规整代码的作者，可能对于某些人来说拥有 refactor 步骤确实是种奢望。

这次 hackathon 中基本功能实现之后还富余了一些时间。这时我面临一个选择。是像实现正式 feature 那样开始 refactor，还是加进更多的 hacky code 让结果 demo 起来更酷更炫。既然暂时没有正式发布 feature 的计划，我决定选择后者。结果我发现脑子好像带着铅球跑步，写出来的东西不断撞到墙上，不得不废弃掉。此时我意识到 hackathon 这个名字确实在很多方面非常贴切。马拉松不光耗时长，跑完了也是需要休息的。这种休息不是体力上的回家睡一觉，而是通过整理工作进行脑力休息。

也就是说，代码冲刺之后的 refactor，非但不是一种奢望，而且还是正常脑力健康的保证。经过一两天的代码长跑之后，花上一段时间把代码整理干净，大脑得到放松，也是静下心来对这段工作的一个内心总结。当你看到一个经常产出「里出外进」的程序员或者团队，就如同看到一个运动生涯中只会冲刺不会休整的运动员，可以想见其未来的长期健康情况。