江苏龙网

  1. 主页 > 生活百科 > >

大前端架构思考与选择( 四 )

前端架构

平稳的节奏

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

上一篇：历史上封侯的人物有哪些 三国时期有哪些名将

下一篇：被世界公认的三大天才 历史上的天才都有哪些