Slow Is Fast 慢就是快
小步快跑
小步快跑是最近一些年流传的比较广的一种理论。大致是说要快速迭代，在市场里面快速测试想法可行性，不行就换方向重新迭代。 这个乍一听似乎没问题，天下武功唯快不破。你速度够快才能在别人还没有动作的时候早日抢占市场，抢占用户。但是真的是这样吗？实际上一个产品最终如何，通常都不是抢占的那点先机决定的。要经受住市场考验，用户才会真的有黏性。而为了抢占先机做出来的功能，通常会不完善，功能不完整等等，导致前期培养的一些黏性用户失望而离开。反而可能你的竞争对手认真的学习并 copy 之后，功能做的扎实完善，吸引了用户。 在我看来，小步快跑正是一些无能的领导们想出来的东西。因为他们心中对全局也没有很好的思路，并不知道下一步的战略应该在哪个方向。所以就让大家小步快跑，不停试错。但是这样时间必然会浪费一些，那么带来的后果就是大家加班严重。 我之前体验过任何功能定好了今晚上线，就必须今晚上线的公司。即使 QA 工程师测试的时候发现产品文档写的不清不楚，也一定需要上线。最后的结果就是，QA 加开发工程师和产品经理一起在最后一刻打磨功能，大家一起加班。而这个功能上线之后，还有下一个功能等着，结果就是无穷尽的加班。半年之后回顾的时候，会发现大家忙乎了大半年，产品做的好不好不一定，反正班加了不少，每个人都很忙碌。
让自己慢下来
我在加入目前公司的时候，难免还会有之前的惯性。工作的内容虽然有区别，但是还是会觉得今天就能发布的东西，为什么我们一定要等到下周呢？我就很不理解。 但是这几年过来，我感觉慢慢能理解这么做的好处了。
让自己慢下来，有时候也是不让别人太快
但凡工作大都是需要和别的同事打交道的。哪怕只是 review 你的 PR 也是需要对方付出时间的。你如果一天提交很多 PR，或者提交很多变更，而又着急发布，那必然就需要其他同事快速的给你 review PR 才行。你自己可能对自己写的代码很有信心，也很了解，感觉 review 一下应该不费时间，但是别人从其他 context 切换过来，理解你的代码，思考解决思路等这些事情一套下来其实很耗费精力的。我看到别人提交的几十个文件变更那种 PR 经常是必须拖延一阵才能下定决心去 review，因为我不想频繁切换上下文，我想给他一个稍微长一点的时间段来完成这个事情。但是自己时间通常又很容易被各种事情打断，而且主要是对于这样的事情多少会有一些抗拒心理，毕竟很多时候是给别人做嫁衣。 另外，也别小看其他人贡献的想法，我有很多次提交的 PR 就被同事一个提醒而重构的。因为其他人也有他们的专长，有时候提供的一些建议会落在自己的盲区，而这些建议有时候确实可以很好的改进你的方案。也有时候会有一些自己也拿不定主意的时候，比如两个方案选哪个似乎都差不多，但是得到更多人支持的方案显然是应该优先选择的。等等此类事情，都是需要给别人时间的。
让自己慢下来，发现更好的方案
我在提交解决方案之后，经常会反复思考自己提供的方案。然后也经常会出现一些火花让我发现更优的方案。所以慢下来，也是给自己一些更多思考的时间。尤其是一些自己也觉得不那么完美的方案，如果给自己一些时间，或许可以思考出来更好的解决办法。即使没有更好的，也至少证明目前的方案即使不完美，但是也确实是自己能做到最好的了。 我自己的体验是，我慢下来之后，经常会出现推翻之前做法的时候。而我通常也越是在我的思路不停的时候，越是强迫自己变慢，尽量给自己一些思考时间。 当然，这里如果快速迭代，先部署一个将就用的有什么问题吗？好像也没问题。但是，或许可以换个思路思考，不立刻部署这个不完美的方案，会有什么问题吗？
为什么说慢就是快
慢下来之后，做事情就不着急了，就会有足够的时候考虑清楚。有时候一些想法可能是在你动手之后才想到的，如果着急完成可能就会忽略这些事情。慢下来之后，如果有没有考虑到的情况，也有足够的时间去考虑清楚。 着急去完成一些事情的时候，如果考虑不清楚，不可避免的就是返工。这样可能会有多次的对别人的打扰，多次的部署风险。当然返工这样的事情肯定也不能说总是会出现，但是一旦做事情开始着急的时候，出现概率就会变多。 没有返工就少很多无用功，如果慢下来，这些浪费掉的无用功就可以用来仔细去思考更完善的方案。这样看着是前期花了很多时间，但是部署会一次成功，并且可以使用很长时间。相比较不完善的方案，来回折腾，显然更优。