Files

T

sanbuphy f35cddeb8b feat(appendix): 重构工程实践章节，添加交互式演示组件

## 新增组件 (14个)
- CodeSmellDemo.vue: 代码异味识别演示
- DecisionMatrixDemo.vue: 决策矩阵工具
- DesignPatternCatalogDemo.vue: 设计模式目录
- DocStructureDemo.vue: 文档结构示例
- LicenseComparisonDemo.vue: 开源许可证对比
- OpenSourceWorkflowDemo.vue: 开源协作流程
- PatternPlaygroundDemo.vue: 设计模式演练场
- RefactoringDemo.vue: 重构实战演示
- SecurityChecklistDemo.vue: 安全检查清单
- TDDCycleDemo.vue: TDD 循环演示
- TechRadarDemo.vue: 技术雷达图
- TechWritingPracticeDemo.vue: 技术写作实践
- TestPyramidDemo.vue: 测试金字塔
- WebSecurityDemo.vue: Web 安全演示

## 文档更新 (7篇)
- code-quality-refactoring.md: 代码质量与重构
- design-patterns.md: 设计模式
- open-source-collaboration.md: 开源协作
- security-thinking.md: 安全思维
- technical-writing.md: 技术写作
- technology-selection.md: 技术选型
- testing-strategies.md: 测试策略

## 其他变更
- 将 browser-as-os.md 内容合并到 computer-networks.md
- 更新 .gitignore 和 theme/index.js

2026-02-24 13:03:21 +08:00

4.8 KiB

Raw Blame History

技术选型方法论

::: tip 前言 React 还是 Vue？MySQL 还是 PostgreSQL？ 技术选型是每个项目开始时最重要的决策之一。选错了，可能要花几个月重写；选对了，团队效率翻倍。

本章带你建立系统化的技术选型思维，不再凭感觉选技术。 :::

这篇文章会带你学什么？

章节	内容	核心概念
第 1 章	技术雷达	了解技术的成熟度
第 2 章	选型维度	从哪些角度评估技术
第 3 章	决策矩阵	量化对比做决策
第 4 章	常见陷阱	避免选型中的坑

学完本章，你将掌握一套系统化的技术选型方法，能为项目做出理性的技术决策。

0. 全景图：技术选型的本质

技术选型不是"哪个技术最好"的问题，而是"哪个技术最适合当前场景"的问题。就像选交通工具——飞机最快，但去隔壁小区不需要坐飞机。

::: tip 选型的核心原则

没有银弹：没有一种技术适合所有场景
场景驱动：先明确需求，再选技术
团队优先：团队熟悉的技术往往是最好的选择
可逆性：优先选择容易替换的方案 :::

通过下面的交互组件，了解当前技术生态的全景：

1. 选型维度

1.1 核心评估维度

维度	关注点	权重建议
团队能力	团队是否熟悉？学习成本多高？	高
社区生态	文档质量、第三方库、Stack Overflow 答案数	高
性能需求	是否满足性能要求？	中-高
维护状态	是否活跃维护？最近一次发布是什么时候？	中
许可证	是否与项目的商业模式兼容？	中
招聘市场	能否招到熟悉这个技术的人？	中

1.2 实际案例：前端框架选型

项目：企业内部管理系统
团队：5 人，3 人熟悉 Vue，1 人熟悉 React，1 人新手
需求：表单密集、权限复杂、不需要 SEO

分析：
- 团队 60% 熟悉 Vue → Vue 优先
- 表单密集 → Element Plus 生态成熟
- 不需要 SSR → 不需要 Next.js/Nuxt
- 结论：Vue 3 + Element Plus

2. 决策矩阵

当多个选项难以直觉判断时，用决策矩阵量化对比。

通过下面的交互组件，体验决策矩阵的使用方法：

2.1 如何使用决策矩阵

列出候选方案：比如 React vs Vue vs Svelte
确定评估维度：团队能力、生态、性能、学习曲线
分配权重：根据项目需求，给每个维度打权重（总和 100%）
逐项打分：每个方案在每个维度上打 1-5 分
加权求和：得出最终得分

2.2 示例

维度	权重	React	Vue	Svelte
团队能力	30%	3	5	1
社区生态	25%	5	4	2
学习曲线	20%	3	4	5
性能	15%	4	4	5
招聘市场	10%	5	4	2
加权总分		3.75	4.35	2.75

3. 常见陷阱

3.1 简历驱动开发

"用这个新技术，我简历上又能多写一条"

选技术应该基于项目需求，而不是个人简历。新技术意味着更多的未知风险和更少的社区支持。

3.2 盲目追新

心态	现实
"新的一定比旧的好"	新技术可能有未发现的 Bug
"大厂在用，我们也该用"	大厂的场景和你的可能完全不同
"这个技术 Star 数最多"	Star 数不等于适合你的项目

3.3 忽视迁移成本

选型时不仅要看"用起来怎么样"，还要看"如果要换，代价多大"。优先选择：

遵循标准协议的方案（如 SQL vs 私有查询语言）
有清晰迁移路径的方案
不会深度锁定的方案

4. 总结

技术雷达：了解技术的成熟度，区分采纳/试验/评估/暂缓
选型维度：团队能力 > 社区生态 > 性能需求 > 维护状态
决策矩阵：量化对比，减少主观偏见
避免陷阱：不追新、不跟风、考虑迁移成本

::: tip 终极思考最好的技术选型往往是最无聊的选型。选择成熟、稳定、团队熟悉的技术，把创新的精力留给业务本身。记住：技术是手段，不是目的。用户不关心你用了什么框架，他们只关心产品好不好用。 :::

4.8 KiB Raw Blame History Unescape Escape