平稳的节奏
- 职能型组织 ， 瀑布式开发模型 ， 有利于控制风险 ， 缺点是时间过长 ， 一般项目至少1个月以上 ， 面对需求变更能力较弱 。是一种偏重计划的模式 。
- 敏捷开发模式 ， 有利于团队沟通 ， 时间一般较短 ， 一般是2~4周 。至于风险 ， 考虑较少 ， 一般是先用了再说 ， 发现问题 ， 下个周期再改 。是一种偏重经验的模式 。
- 将这两者结合 ， 是希望达到风险和速度的平衡 ， 形成平稳的节奏 。将敏捷模型中原本只有4小时的计划会议和回顾会议扩展为一周 ， 是为了让跨部门沟通更充分 ， 让产品验收更全面 ， 降低风险 。
- 集中资源做“重要而不紧急的事情” 。客户需求很重要 ， 但从想法到落地 ， 并没有那么快 。所以发挥“大前端”灵活的优势 ， 让客户早一点看到想法落地 ， 可以超越客户期望 。
- “需求变更”本身 ， 也是一种潜在的客户需求 。在用上实际可用的产品前 ， 很多时候 ， 客户也不知道自己想要什么 。所以 ， 采用两阶段交付的方式 ， 用总开发成本30%左右的“大前端”半成品 ， 挖掘客户的潜在需求 ， 可以提高客户的满意度 。
- “可用的产品胜过完备的文档” ， 虽然是个半成品 ， 站在客户的角度 ， 比word文档 ， 原型设计等更实在 ， 更靠谱 。
- 技术债怎么办？是立即处理还是等累积到一定程度 ， 再集中处理？
- 让业务停下 ， 专门做重构 ， 这种机会只能说可遇而不可求 。
- 将原来敏捷中不超过4小时的回顾会议 ， 扩展为1个星期的重构阶段 ， 正是为了解决技术债不断累积的问题 。达到“一边飞行 ， 一边换引擎”的效果 。
- 这个阶段 ， 产品和业务也没有停 ， 在试用 ， 在体验 ， 在验证一开始的设计理念是否符合实际 。这样就促成了产品和技术的双赢局面 。
- 这里将敏捷开发中原本4小时的“计划会议”扩展为1周 。
- 敏捷模型在介绍时有个假设 ， 那就是需求确定 ， 原型设计 ， UI资源 ， 前后端接口设计等各种资源都准备好了 ， 相关的可行性 ， 也就是预研都完成了 ， 再开“计划会议”
- 实际情况是 ， 上面提的那些条件往往都没准备好 ， 或者有缺失 。开发在进行到一半的时候 ， 经常发现交互逻辑不落地 ， 要改原型 。或者发现UI资源缺少 ， 接口定义不合理等等 。
- 特别是职能型组织 ， 跨部门沟通 ， 这种信息缺失的事情更容易发生 。
- 在正式开发之前 ， 花1周时间 ， 集中进行沟通 ， 进行技术预研 ， 做好充分准备 ， 将问题发现在工程开始之前 ， 对减少不必要的返工是很有意义的 。
- BFF成了“大前端”和后端之间的抽象接口
- BFF需要做好两边的适配
- 可以考虑将一些公共业务也接过来 ， 实现“轻客户端”的目标
- 自然而然的“热更新” ， BFF采用了后端的技术 ， 做的是“大前端”的工作 。有修改 ， 更新服务 ， 就生效了 ， 天然的热更新 。
- 天生的“跨平台” ， BFF这一个地方修改 ， 各种端都能起作用 。
- 增加掌控力 。BFF由企业维护 ， 而各种端掌握在用户手里 。将业务由各种端移到BFF ， 可以显著提供企业的掌控力 。
这里的边界是：“能服务端（BFF）实现的 ， 就不要放到客户端去 ， 除非遇到严重的性能问题” 。 - 注意性能瓶颈 ， 这是关键节点 ， 是前后端的对接点 。并且还要注意 ， 对接之后 ， Mock数据要清除干净 ， 保证生产版本的数据是来自真正的后端 。
- “大前端”注重效率 ， 快速响应用户的需求变更 。
- 后端注重安全 ， 按照瀑布模型或者迭代模型 ， 注重风险管控 。
推荐阅读
- 被世界公认的三大天才 历史上的天才都有哪些
- 聊聊虚拟内存
- 电脑内存容量真的是越大越好吗？
- Redis命令大全，满足你的日常工作，看这一篇就够了
- 崂山红茶的功效与作用,青岛崂山大田茶开采
- 黑客大神教你：Weblogic相关漏洞复现
- 大话西游插曲都有哪些
- 原著潘金莲为什么会嫁给武大郎? 潘金莲毒死武大郎是哪一天?
- 鲜芡实的吃法大全
- 凉拌尖椒的做法大全
