关于开发流程的复盘

最近，阅读了一本书《复盘》，这本书豆瓣评分并不高(6.2分)，有人觉得内容是东拼西凑而来的，还有人说陈述组织的不够严密…当然，这些问题都存在。

不过我想说的是，其实这本书收获很大也是事实。

在五一期间，深刻复盘了过去一年工作中所遇到的问题，如果稍微调整下工作流程，就能避免很多的加班。

这里就将自己复盘的结果，分享给大家：

一、预演（preview）

一个互联网产品在开发之前，往往起源于一个绝佳的idea，对于想到这个idea的人来说，这个产品开发出来是绝对能收到用户的热烈欢迎的，甚至于改变世界的。

所以从这个idea开始，就想着用最快的速度设计并开发出来，好收到预想的效果。

但是真的如此吗？

有没有违背基本的事实？

你的感受真的是用户的感受吗？用户真的会愿意去尝试并因此而付费吗？

有没有竞争对手？如果没有的话，这真的是一个真实存在的需求吗？比如前两年很热的各种共享：共享单车、共享充电宝、共享篮球；早些年的各种O2O，现在又有几家活下来了呢？

当然这个从业务战略层面来说的，从微观上来说，产品逻辑是不是合理？业务流能不能走的通？

从技术层面上来说：技术上能否实现？数据流能不能走的通？产品的状态流转是否通顺？现有的技术实力多久的周期能完成？

如果仔细考虑以上问题，那么就能避免很多不靠谱的产品进入到开发阶段。

二、编码和测试（coding and testing）

开始编码之前，还有做一些事情，技术架构设计问题，技术的选型问题，数据结构设计的问题，甚至用什么开发语言来实现的问题…这些问题很多人都没有太认真的去思考。要么是撸起袖子就干，要么是追新、追炫，最后遇到一个巨大的坑来填，然后拼命的加班加点。

为什么编码和测试放到一条里面？因为之前太不注重测试了，等到开发完才进行测试，结果修复bug的时间越拉越长，甚至是测试的时间都快赶上开发的时间了。因为系统越复杂，就越难发现其中的问题，有些代码的用处甚至都忘记了，因此也越难于测试。

受到《测试驱动开发》这本书的影响，现在在团队推行写完一个小的功能就立即写上测试代码，因为刚写过，也知道代码的逻辑，测试起来也就几分钟甚至更短。

三、复盘（review）

在开发这一领域中，review是个很高级的词语，一提到review大家都能巴拉巴拉的说上一大通，但是真正有在用的却没有几个，原因就是时间不够用，但最核心的本质是懒。懒是因为没有作品意识，如果这个产品是给你未来的老板看的，估计你就不会去写乱糟糟的代码了。

当然复盘的含义不仅仅是代码层面的，还有设计层面的，也有对业务理解层面的，要做的其实很多。

一个人能力提升的关键，在于复盘，代码能力的提升，也是复盘(review)。

四、重构（refactoring）

review之后，就是重构了，那么关于如何重构，这里推荐一本书《重构(第2版)》，一本经典之作，十年、二十年仍然不会过时，里面有很多方法论以及实操手法，可以经常阅读或者作为速查手册。