Vue.js

Appearance

On this page

场景3——做技术选型决策 ​

场景描述 ​

领导找你：

"我们要做一个新项目，前端框架你来定，
Vue、React都行，你评估一下用哪个。"

这是技术选型场景。

常见的错误做法：

  • 选自己熟悉的（没有客观评估）
  • 选最流行的（没有结合实际情况）
  • 各种对比表格（看起来专业但没抓住重点）

正确的做法是从实际需求出发，找最适合的。

CPERF应用 ​

C - Capture 捕获 ​

第一步：定义问题

"选Vue还是React"是结论层面的问题。

真正的问题是：什么框架最适合这个项目？

收集信息：

关于项目：
1. 项目类型：企业内部的管理后台
2. 复杂度：中等，大概50个页面
3. 时间要求：3个月上线
4. 后续维护：长期维护，可能有新人接手

关于团队：
1. 团队规模：3个前端
2. 技术栈：2人Vue熟练，1人React熟练
3. 招聘计划：近期可能招1-2人

关于公司：
1. 现有项目：大部分是Vue
2. 组件库：有Vue版本的内部组件库
3. 技术氛围：没有强制要求，但倾向于统一

问题重新定义：

问题：为企业管理后台选择前端框架
约束条件：
- 3个月上线
- 团队2Vue+1React
- 公司现有Vue组件库
- 需要长期维护

P - Process 处理 ​

评估维度：

技术选型不是比谁"更好"，而是比谁"更适合"。

评估维度：
1. 开发效率：能不能按时完成？
2. 团队成本：学习成本和协作成本
3. 生态配套：组件库、工具链是否匹配
4. 长期维护：代码可维护性、人员替换成本

方案对比：

markdown
### Vue方案

开发效率：★★★★★
- 团队2人熟练，可以立刻开始
- 有现成的组件库，不用造轮子

团队成本：★★★★☆
- 1人需要学Vue，学习成本约1周
- 团队协作无障碍

生态配套：★★★★★
- 公司组件库是Vue版本
- Element UI等成熟方案

长期维护：★★★★★
- 公司主要技术栈，人员替换容易
- 新人入职适应快

### React方案

开发效率：★★★☆☆
- 只有1人熟练，另外2人要学
- 没有现成组件库，需要选型或自建

团队成本：★★☆☆☆
- 2人需要学React，学习成本约2-3周
- 初期协作可能有摩擦

生态配套：★★★☆☆
- 需要重新选型组件库
- Ant Design等方案都可以

长期维护：★★★☆☆
- 公司React人才储备少
- 新人入职可能需要专门招

决策分析：

关键因素权重：
1. 开发效率（时间紧）：权重40%
2. 团队成本：权重30%
3. 生态配套：权重20%
4. 长期维护：权重10%

得分对比：
Vue：5*0.4 + 4*0.3 + 5*0.2 + 5*0.1 = 4.7
React：3*0.4 + 2*0.3 + 3*0.2 + 3*0.1 = 2.7

结论：选Vue。

E - Express 表达 ​

向领导汇报选型结论：

"关于前端框架选型，我建议用Vue。

主要考虑三点：

第一，开发效率。
团队3人里2人熟悉Vue，可以立刻开始。
如果用React，2人要先学，项目启动会延迟2-3周。

第二，生态配套。
公司有现成的Vue组件库，用起来直接套用。
如果用React，需要重新选型或自建组件库。

第三，长期维护。
Vue是公司主流技术栈，后续维护和人员替换都更方便。

总的来说，对于这个项目，Vue的综合匹配度更高。

React本身是好技术，但在当前团队和项目条件下，
选Vue的收益更大、风险更小。"

R - Review 复盘 ​

项目结束后回顾选型决策：

验证结果：
- 项目按时上线
- 组件库复用顺利
- 团队协作没有障碍

假设验证：
- 假设"Vue开发效率更高"成立
- 假设"组件库复用节省时间"成立

如果重新选择：
- 仍然会选Vue
- 这次决策的思路是对的

可改进的点：
- 对React那位同学，可以安排一些组件开发的任务
  让他用Vue也做一些有挑战的工作

F - Form 固化 ​

记录技术选型的方法：

技术选型不是比"谁更好"，而是比"谁更适合"。

评估框架：
1. 明确约束条件（时间、团队、生态）
2. 确定评估维度（效率、成本、配套、维护）
3. 根据项目情况分配权重
4. 对比分析，选择综合得分最高的

避免的误区：
- 选自己熟悉的（个人偏好）
- 选最流行的（盲目跟风）
- 做复杂的对比表格但不抓重点

关键要点 ​

要点1："更好"不等于"更适合" ​

技术没有绝对的好坏，只有适不适合。

React很好，但如果团队不熟悉、时间又紧，就不适合。
Vue可能"技术上没那么酷"，但如果团队熟练、有现成生态，就很适合。

要点2：从约束条件出发 ​

先搞清楚约束条件：
- 时间约束：多久要上线？
- 团队约束：团队熟悉什么？
- 生态约束：公司有什么现成的？
- 维护约束：后续谁维护？

约束条件决定了哪些选项是可行的。

要点3：评估维度要和项目相关 ​

不是所有维度都同样重要。

时间紧的项目：开发效率权重高
长期维护的项目：可维护性权重高
创新项目：技术先进性权重高

要点4：决策要有理由，不是个人偏好 ​

❌ "我觉得Vue好"（个人偏好）
✅ "基于团队熟悉度和现有生态，Vue更适合这个项目"（有理由）

决策要经得起追问：为什么选这个？

本场景的CPERF检查清单 ​

markdown
□ Capture
  - 项目的具体需求清楚吗？
  - 约束条件（时间、团队、生态）明确吗？
  - 收集了足够的信息做对比吗？

□ Process
  - 确定了评估维度吗？
  - 根据项目情况分配了权重吗？
  - 做了客观的对比分析吗？

□ Express
  - 决策结论清晰吗？
  - 理由充分吗？
  - 说明了为什么不选其他方案吗？

□ Review
  - 项目结束后验证决策了吗？
  - 假设成立吗？
  - 有什么可以改进的？

□ Form
  - 总结了选型方法吗？
  - 记录了避免的误区吗？

技术选型模板 ​

markdown
## 选型背景
- 项目类型：
- 项目规模：
- 时间要求：
- 维护要求：

## 约束条件
- 团队情况：
- 现有生态：
- 公司要求：

## 评估维度和权重
| 维度 | 权重 | 选项A | 选项B |
|------|------|-------|-------|
| 开发效率 | X% | ★★★ | ★★★ |
| 团队成本 | X% | ★★★ | ★★★ |
| 生态配套 | X% | ★★★ | ★★★ |
| 长期维护 | X% | ★★★ | ★★★ |

## 结论
选择：
理由：
1. 
2. 
3. 

## 风险和应对
潜在风险：
应对措施：

小结 ​

技术选型的核心方法：

  1. 先搞清楚约束条件
  2. 确定评估维度和权重
  3. 客观对比，选综合得分最高的
  4. 决策要有理由，不是个人偏好

记住：没有最好的技术，只有最适合的技术。

下一章，我们看向领导汇报工作的场景。

在 GitHub 上编辑此页