最近看了一篇文章，叫《A development process startup founders should use to ship features weirdly fast》，翻译过来应该是《初创公司创始人快速发布功能的开发过程》，作者Andrew Orsich是一个专门做创业孵化公司的一个联合创始人。文章讲的是作为初创企业应该如何高效迭代，这对我们现在在一个大公司或者一个大业务线要新开一个实验性质的小产品线具有很好的指导意义。

他说自己有幸见过不少0-4岁的公司，很惊讶于其中很多公司有复杂和缓慢的软件交付流程，他觉得这对于一个小公司应该高效上线，快速迭代，还要有“拿来主义”，能用第三方工具就不要自己写。基于这个出发点，他提出了如下软件开发原则。

1. Avoid Feature Branches

   作者认为团队里分出一批人去做特性分支费时费力，而且合并回主分支时需要大量时间，而且还极有可能产生新bug，这会拖累整个项目的发布进度。

2. Automate CI/CD pipeline

   作者强烈建议使用自动化的CI/CD流水线，可以节省大量手动部署服务的时间，并能让团队在一天内进行多次发布。

3. Use a monorepo

   使用单一代码库，代码更容易被找到与管理，组织CI/CD流程也更加简单。

4. Break features into small, incremental changes

   把特性打散到小的、增量变更之中，这样的好处是能够更快速地获得特性变更带来的反馈，也能提升团队的能力。另外，作者还提到了2个可以为产品和工程团队使用的原则：

   a.对于产品团队:任何任务都不应该超过3天

   b.对于工程团队:工程团队中的每个人都应该平均每一天或两天提交一个pull request

5. Use feature flags

   使用特性标志（开关），这可以在不编写代码的情况下更改产品功能，方便及时推送新功能并获得用户反馈。

6. Define owners

   定义所有人，能够划清责任。

7. Request at least one demo per week

   要求每周至少1个demo。

8. Deploy weekly

   每周都要部署。

9. Freeze the code before release

   发布之前冻结代码。

10. Write tests (or not?)

    要不要写测试用例？作者认为尽管测试很有必要，但对于一个小的创业公司而言，不值当，在测试上投入太多精力会拖慢发布速度，只做一些必要的测试就好了。

总而言之，作者的一切观点都是希望产研团队始终保持一种小步快跑的节奏，让自己的产品在市场竞争中尽快活下来。感兴趣的朋友可以去看看原文，链接如下。

原文链接：

https://growing-products.paralect.com/a-development-process-startup-founders-should-use-to-ship-features-weirdly-fast

作者：韭不黄，十余年来一直混迹于信息安全行业，扛过设备，卖过服务，做过审计，查过黑客，反过欺诈，岁月神偷带走了我的苹果肌，留下了一肚子的瘫软，貌似我将要成为一个油腻的中年男人，不过依然对世界充满好奇，依然是一颗嫩绿的韭菜~