概述
当看到大屏的设计稿, 想到的第一件事情是什么? 没错, 大脑 惯性思维 开始活动了. 我想到的是 Layering 分层 和 gridster 布局系统 以及 进出场动画.
当然 我不会在这里展开 为什么我先想到的是这些, 这不符合我们的主题 规范化.
很讨厌不是吗 惯性思维 是大脑最舒适的思维方式, 它完全凭着记忆和下意识的去得出结论. 或者说是经验学. 甚至有的时候我们把这个叫做 灵感.
但是 规范化 可以说是截然不同的思维方式.
自研框架
为什么要自研框架 ? 成本可以控制吗 ? 交付能按时吗 ? 有没有风险 ?
选择 技术方案 有成熟的方法论, 常见考虑因素包括但不限于:
客户需求
功能需求
用户体验, 兼容性, 合规性, 性能, 安全性 ...
成本
- 成熟度 受欢迎的程度
- 学习曲线
- 可伸缩 可扩展 可维护性
- 开发文档 与 开发社区
这里不长篇大论, 无非还是 经验学. 基于 非功能需求 自研框架是最佳选择. 当然花一点时间 做一个 技术探针 也是必要的.
非功能需求
Vue3 与 其它 技术栈选择
用 Vue 作为技术栈往往都写在
需求规格说明书里面. 甚至 图表组件库也要求使用 Echarts.既然是 业务需求, 照办.
局域网
- 在内网运行不能访问外部网络
- 这个对地图组件的选择有很大的影响
兼容老浏览器
- 这个对 技术栈选择 有影响
高度定制化 (客户带着设计师完成需求分析和原型设计)
- 这个决定了 第三方 技术方案 是否可行
设计维度
从头来过, 从 业务需求 出发, 设计稿里面的各种设计元素 我们怎么合理的 组织起来, 分而治之, 一个个的去实现它.
先从最重要的开始:
- 路由
- 分层
- 布局系统
- 地图
- 信息卡片
- 图表 Charts
先考虑这么多, 足够了, 这些模块即是独立的, 又是顺序相关的, 当他们要组合在一起的时候, 后面的元素必须建立在前面的元素之上.
技术细节
技术细节一开始并不重要.
可能你无法相信, 项目开始的时候, 这个项目要用的每个技术栈, 我几乎都没有 用过. 但是我却对他们又非常 "熟悉".
是的从 业务 角度 也就是目的 来说, 我很熟悉我要选择的技术栈. 从 技术 角度来说 我不记得 这些技术栈的 API 细节. 这就是我之前提到的 反转. 这反而能让我始终坚持 规范化中的原则.
随着项目的推进, 每个技术栈的 API 文档 从挑着看几页 演进到 几乎都被翻了个遍, 为了贯彻 业务目标, 每个技术栈的主要 API 甚至是 隐藏技能 都会被用到.
这不是巧合, 恰恰说明 技术栈就是对 业务目标 实现细节 的 最合理抽象.