在日常开发中，不同的组织结构喜欢采用不同的开发模式。基本上可以分为三大类：
- Outside-in: 始于前端，终于后端
- Inside-out: 始于后端，终于前端
- Parallel: 前端后端并行开发
团队中到底选择哪种模式？能带来哪些便利/弊端？有幸这三种方式我都尝试过，也想借此分享点自己的收获.
在基于看板的敏捷开发活动中, 每一个故事卡从出生起直到部署到生产,都是为了交付业务价值而存在的,而业务价值往往通过交互界面而体现,由代码逻辑作为支撑, 所以我有理由认为 Outside-In 是业务开发中性价比最高的开发方式.原因如下:
- 交互界面是最贴近用户需求的入口,基于此设计出的数据接口是最准确的,有效避免过度设计,避免浪费
- 团队能共同建立前后端技术能力
如果使用 Inside-out 模式,也就是先设计一个功能强大的数据接口,考虑到基本情况,在设计-开发-部署之后有信心前端可以直接使用,但往往前端开始使用的时候会发现缺少个别字段,也许你会说那一开始为什么不确定好呢?其实每一次设计都是团队一起合作,也难免会忽视必要字段.毕竟有时候前端包含了:业务交互,用户行为数据分析等. 然而使用这种模式的原因:
- 基于团队的发展优势和内部能力来推动业务发展,也就是有足够的成熟度和自信认为自己设计的东西是用户需要的
- 团队能共同建立前后端技术能力
看到一篇文章提到, Inside-out 一个很好的例子是苹果公司, 它开发的产品首先回答了为什么,并能给用户一定指导作用.
苹果并没有说一个企业有一个好的产品和好的设计——用这些话来销售它——而是从圈子的中心开始，把它的本质放在最前面。 这家公司一直很明确地说，它的目标是挑战现状，思考不同。 结果是精心设计的产品，易于使用，用户友好的界面。 根据 Simon Sinek 的说法，这种逻辑让人们购买“因为”苹果生产它，而不是苹果生产的“什么”。 我们知道这种策略给苹果带来了很大的成功，但这并不一定意味着由外而内的方法无效。
但其实文章说的 Inside-out 和我说的不一样, 我说的是具体的日常开发, 而文章提到的更是从产品的角度. 所以从日常开发的角度, 还有一种是 Parallel 的方式, 就是团队成员分为两组, 同时开发前端和后端, 通过高频的沟通来确保数据服务的正确性, 且不需要花费额外的时间和精力去学习自己不熟悉的领域,而缺点也同样明显,需要频繁的修改保证前端后端交互的正确性,团队的能力建设受限,可能有深度,但是缺乏广度,团队的能力弹性不能保证.而且作为软件工程师,理解全部的生态很重要,不过那是另一个话题了.