ARTS - Share 补2019.1.16

快速迭代与流程开发的一点思考

软件工程与互联网

我们很早接受了软件工程的思想，有一套非常标准的工作流程： 客户谈需求、形成用例、完成文档、开发、测试、上线部署等。如果有需求变更，就再走一遍流程，变更的需求大约在下一期上线。

这样的工作流程或准则在业务变更不频繁，时间充裕的传统企业是比较适合的，因为比较好控制质量、成本等。但是在瞬息万变的互联网行业是不行的，因为互联网的特点就是新颖的事物层出不穷，快速响应变化。因此需求变更是常态。如果哪家互联网企业严格按照软件工程那一套，必然容易失去先机，不会成为一流。

技术架构的多变

以业务导向为核心，需求的频繁变更不可避免，那么架构就要适应这个变化。然而现实很容易走极端，过度架构设计保证灵活性可能带来复杂性，如果变更的一点需求需要大量的时间开发、测试，然后上线，最后发现付出的成本远超产生的价值；不进行架构设计，又容易造成重复开发，疲于应付各种意外，造成项目越来越臃肿，直到改无可改，开始重构。那么，该如何思考架构设计？答案是，适度设计。

不可避免的不够“优雅”的代码

面对复杂多变的需求，和时间紧任务重压力下的产品，可能不那么精雕细琢。但是至少在长久运行中长期保持稳定，那么当一个新人接手这块功能，在开始骂代码不够好之前，请先全面的了解系统，了解之前的场景，然后在最简单影响最小的地方开始着手重构，然后测试、运维上线，走完流程后，在进行下一个，相信做过几次重构后肯定会形成更为全面的认知。

质量下降与管控

快速开发，有时不可避免有些问题想的不够周到，质量有下降，比软件工程这种标准流程下的产品质量有所下降，这也是快速的一种代价。因此这种更要注重测试，使用各种自动化的工具，在保证质量与快速迭代之间做平衡。

总结

为了快速推出市场，敏捷不可避免，因此带来的副作用是不那么稳定或bug率提高了，但是依然是值得的，也必须这么做，在做技术决策中始终要综合考虑。