[I.2] 个人作业：软件案例分析

项目 内容
这个作业属于哪个课程 https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里 [I.2] 个人作业：软件案例分析 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是 学会编写一个完整软件项目的技能，为职业发展打下坚实基础；培养批判性思维和解决复杂工程问题的能力。
这个作业在哪个具体方面帮助我实现目标 在已有的产品中分析其背后的设计哲学，培养批判性思维的能力。同时深入研究一个软件的功能特性，设计原则等有助于培养解决复杂工程问题的能力

第零部分：选题

我的选题是✈Open source is FREE!

VS Code是我们学习生活中非常重要的工具，但很少有人知道它其实是一个开源软件！！！

第一部分：调研与评测

1. 软件评测

1.1 软件使用

作为一名计算机系的学生，从大一开始我就和VS Code打交道。从开始的完全陌生，到现在的熟练运用，我也算是VS Code的老朋友了。在本次评测任务中，我模拟了用VS Code打开python文件，并且运行python文件的功能。

Pasted image 20260317222126

1.2 软件分析

  • 基本流程： 用户通过“打开文件夹”进入项目 -> 侧边栏搜索并安装语言扩展 -> 编写代码 -> 利用终端或调试面板进行反馈 -> 通过内置 Git 插件完成版本管理。基本流程如下：

    • 打开文件夹进入项目：
      Pasted image 20260317222440

    • 侧边栏搜索并安装语言扩展：
      Pasted image 20260317222532

    • 利用终端或调试面板进行反馈
      Pasted image 20260317222924

  • 需求解决： 极好地解决了“轻量级编辑器与重型 IDE 之间平衡”的需求。

  • 多维度评价：

    • 数据量/性能： 采用 LSP (Language Server Protocol) 协议，将耗费资源的语言扫描（如自动补全、定义跳转）放在独立进程中，即便处理百万行级别的项目（如 Chromium 源码），UI 线程依然流畅。

    • 界面 (UI)： 极致的简约主义，侧边栏（Activity Bar）布局已成为行业事实标准。

    • 功能 (Functionality)： 核心功能极其克制，几乎所有高级功能（Java 支持、Docker、远程开发）都交给插件，这种“微内核”设计是其成功的关键。

    • 准确度： IntelliSense 的补全准确度依赖于具体插件，官方维护的 Python/C++ 插件表现优异。

    • 用户体验： 快捷键逻辑自洽，Command Palette ($Ctrl+Shift+P$) 极大地降低了寻找隐藏功能的成本。

1.3 改进意见

  1. 内存占用： 虽然性能优化到了极致，但 Electron 的底子决定了其基准内存开销（约 500MB+）对于低配电脑仍不友好。

  2. 插件冲突管理： 当安装多个相似功能的插件（如多个 AI 助手）时，代码建议框（Suggest Box）会出现相互覆盖或排序混乱的问题，缺乏一个更智能的冲突协调机制。

2. 用户调研

采访对象： 吴际老师班上的学生刘锦涛

选择原因： 刘锦涛同学是是典型的“极客”用户，长期使用 VS Code，对 IDE 的便捷性和性能平衡有挑剔的要求。

  • 采访记录：

Pasted image 20260318153053

3. 评测结论

结论：e) 非常推荐

定量评分 (1-10分)：

  • 启动速度： 8.5（同类 Electron 应用第一，但弱于文本编辑器 Sublime）

  • 功能扩展性： 10（无可挑剔的生态）

  • 系统稳定性： 9.0（多进程架构保证了 UI 不假死）

  • 上手难度： 7.5（JSON 驱动配置对纯新手有一定门槛）

4. Bug 分析与提交

4.1 指标量化标准

  • ⭐⭐⭐⭐⭐ (5星)： 致命 Bug。导致系统崩溃、数据丢失或严重安全漏洞。

  • ⭐⭐⭐⭐ (4星)： 严重 Bug。核心功能不可用，且没有简单的绕过方法。

  • ⭐⭐⭐ (3星)： 普通 Bug。功能异常，但有替代方案，影响工作效率。

  • ⭐⭐ (2星)： 体验 Bug。UI 错位、文案错误或不符合用户直觉的操作逻辑。

Bug 1：markdown预览的左右不匹配

  • 测试环境： macOS, VS Code v1.86.0, 处理包含 50 万个文件的项目。

  • 可复现性： 几乎一直都有

  • 复现步骤：

    1. 打开一个markdown文件

    2. 点击右上角的预览

    3.上下滑动

  • 具体现象描述： 左右文献对应预览不匹配

  • 原因分析： 可能是markdown自身插件的设置问题。

  • 严重性：⭐(1星)。几乎没有任何影响，对某些强迫症有点影响。

Pasted image 20260318115917

Bug 2：集成终端中的“光标渲染偏移”

  • 测试环境： macOS Sonoma, 开启 GPU 加速渲染，使用非等宽字体或特殊中文字体。

  • 可复现性： 必然发生（在特定缩放比例下）。

  • 复现步骤：

    1. 将编辑器缩放比例调整为非整数倍（如 110%）。

    2. 打开集成终端，输入长字符串，包含中英文混合。

    3. 使用退格键删除。

  • 具体现象描述： 光标的位置与实际字符删除的位置不符，会出现“光标漂浮在空处”或“字符重叠”的视觉 Bug。

  • 原因分析： VS Code 的终端是基于 Canvas 渲染的，在非整数倍缩放时，字符宽度的计算精度丢失（Rounding error），导致像素对齐失效。

  • 严重性：⭐⭐ (2星)。虽不影响代码逻辑，但极度折磨强迫症，干扰输入。

4.2 为什么这些 Bug 没在发布前修复？

  1. 环境差异性（Bug 2）： 用户使用的字体、缩放比例、显卡驱动千差万别，测试矩阵很难覆盖所有排列组合。

  2. 边界情况（Bug 1）： 这种性能相关的“僵尸进程”往往在极端负载下才出现，开发团队可能认为这属于 “Edge Case” (边缘情况)，在优先处理核心功能迭代时被置后了。

  3. 设计限制： VS Code 追求极快的搜索响应，可能在进程调度逻辑上采取了较为激进的策略，导致在异常操作下出现同步失效。

4.3 改进建议

  • 针对 Bug 1： 引入更严苛的搜索进程超时与强制杀除机制（Watchdog），并限制同时运行的搜索子进程上限。

  • 针对 Bug 2： 在 Canvas 渲染层引入更精确的坐标四舍五入算法，或者为非整数倍缩放提供专门的对齐补丁。

第二部分：分析

1. 工作量分析

如果我们要组织一个 6 人左右的计算机专业毕业生团队（配备专业 UI 支持），从零开发一个达到目前 VS Code 核心水准（即支持多语言、扩展机制、LSP 协议、集成终端）的服务，我们需要评估的不仅是“代码量”，更是“工程复杂性”。

基于《构建之法》8.6 节对任务的估计模型，我将工作量拆解如下：

阶段 核心任务 估计耗时（月） 复杂度理由
基础架构 基于 Electron 的多进程模型搭建，IPC 通信机制设计 3 需处理渲染进程与主进程的隔离，保证 UI 不假死。
文本编辑器内核 高性能文本渲染（Canvas/WebGL）、虚拟滚动、大型文件加载优化 5 这是核心，处理 10万行代码不卡顿是技术壁垒。
插件系统与协议 LSP (语言服务协议) 与 DAP (调试协议) 的实现与兼容 4 协议的标准化实现要求极高的软件建模能力。
通用功能 Git 集成、终端仿真、智能感知 (IntelliSense) 底层 3 功能点的琐碎与跨平台兼容性测试。
工程质量与生态 自动化测试框架、CI/CD 流水线、插件市场服务端 3 确保 6 人团队产出的代码能够稳定迭代。

  • 总计时间：约 18 - 24 个月。

  • 分析理由： 虽然 6 名毕业生拥有理论基础，但 VS Code 的精髓在于极致的性能调优和高度解耦的插件架构。毕业生团队在处理“内存泄漏排查”、“跨平台 I/O 差异”以及“异步竞态条件”上会耗费大量调研时间。

  • 注意： 这仅仅是实现“核心编辑器”，不包括 VS Code 背后数千名社区贡献者维护的成千上万个插件。

2. 软件质量分析

2.1 优劣势评估与排名

在目前的开发工具市场中，VS Code 属于“泛用型轻量级 IDE”领域。

  • 优势 (Pros)：

    • 极致的解耦： 它是 LSP 协议的制定者。这意味着它不需要为每种语言写代码分析，只需作为客户端接入，质量极高。

    • 冷启动速度： 远超 IntelliJ 和 Visual Studio。

    • 生态壁垒： 拥有目前全球最活跃的扩展社区，几乎任何冷门语言都能找到支持。

  • 劣势 (Cons)：

    • 配置成本： 相比“开箱即用”的 IDE（如 PyCharm），VS Code 需要用户自己组装（安装各种插件），这对新手不够友好。

    • 重度负载下的内存开销： 毕竟是封装了 Chrome 内核，在同时打开多个大型项目时，内存压力依然显著。

  • 同类排名：第 1 名。

    理由： 尽管在特定语言的深度重构上不如 JetBrains 系列，但从市场占有率、生态多样性、跨平台一致性以及**引领软件工程标准（LSP/DAP）的角度来看，VS Code 是当之无愧的霸主。

2.2 团队软件工程建议

基于对 VS Code 近年迭代的观察，我推测其开发团队在软件工程方面可以提高的一个重要方面是：插件运行时的资源配额与健康监控（Resource Quotas & Health Monitoring）。

  • 问题推理：

    VS Code 秉承“微内核”原则，将大量能力交给插件。但这导致了一个质量黑盒：用户遇到编辑器卡顿、CPU 飙升时，往往不知道是哪个插件导致的。虽然目前有“Extension Host”进程，但缺乏精细化的资源管控。

  • 具体工程建议：

    1. 引入“沙盒配额机制”： 在软件架构中为每个 Extension 设定动态的内存和 CPU 使用上限。一旦某个插件（如某小众语言服务器）持续占用 100% CPU 超过设定阈值，系统应自动挂起该进程并弹出“性能诊断报告”。

    2. 增强“用户感知质量”： 仿照手机系统的“耗电排行”，在 VS Code 内部集成一个插件资源排行面板。

    3. 价值： 这符合《构建之法》14.1 节中关于“软件质量 = 功能性 + 易用性 + 可靠性”的论述。通过技术手段强制规范插件质量，可以进一步提升核心产品的稳健性。

第三部分：建议和规划

1. 市场现状

1.1 市场概况

  • 直接用户： 根据 Stack Overflow 的最新调研，VS Code 在开发者中的渗透率已超过 75%。全球约有 2700 万专业开发者，这意味着其直接用户在 2000 万以上。

  • 潜在用户： 随着“全民编程”和 AI 辅助开发的普及，潜在用户包括：在校大学生、数据分析师（非计算机专业）、甚至是通过 AI 提示词进行低代码开发的非技术人员，这一群体规模预计在 5000 万以上。

1.2 竞争产品与产品定位

目前市场呈现“一超多强”且“AI 逆袭”的态势：

产品 定位 优势 (Pros) 劣势 (Cons) 态势
VS Code 通用的轻量级编辑器 插件生态无敌，标准化（LSP） 插件冲突多，内存占用随插件线性增长 行业霸主，防御状态
JetBrains 工业级深度的 IDE 开箱即用，代码重构与静态分析极强 启动极慢，收费高昂，内存黑洞 高端市场，稳扎稳打
Cursor AI 原生代码编辑器 AI 深度集成至内核，代码补全更懂上下文 生态完全兼容 VS Code 但缺乏独立壁垒 挑战者，增长势头极猛
Zed 极致性能的编辑器 Rust 编写，GPU 加速，响应延迟极低 插件生态刚起步，目前功能较单一 极客心头好，潜力股

2. 市场与产品生态

2.1 典型用户分析

  • 核心用户群： 18-35 岁，计算机相关专业，互联网从业者。

  • 典型用户画像：

    • 姓名： 小张（24 岁）

    • 背景： 某大厂前端开发工程师，本科学历。

    • 爱好： 关注开源社区，追求极致的工作效率和炫酷的编辑器主题。

    • 表面需求： 语法高亮、快速 Git 提交、流畅的远程调试。

    • 潜在需求： 减少重复造轮子（AI 自动写样板代码）、在不同设备间无缝同步开发环境。

2.2 用户与产品生态关系

  • 用户生态： 开发者不仅是使用者，更是贡献者。用户通过编写插件上传到 Marketplace，吸引更多用户使用，从而形成强大的网络效应。这种“创作者经济”是 VS Code 最深的护城河。

  • 产品生态： VS Code 并非孤立存在，它与 GitHub（版本控制）、Azure（云服务）、Copilot（AI 助手）构成了微软的“开发全家桶”。利用这种关系，用户可以实现“从写下第一行代码到云端部署”的全流程闭环。

3. 产品规划

作为新任 PM，面对 Cursor 等 AI 原生编辑器的威胁，我将把 VS Code 的改进重点放在“从插件外挂 AI”转向“内核级 AI 驱动”。

3.1 NABCD 创新分析

  • Need (需求)： 用户厌倦了在对话框和编辑器之间来回复制 AI 生成的代码，他们需要 AI 能够直接、精准地修改局部逻辑，并理解整个仓库的架构。

  • Approach (做法)： 开发名为 "DeepContext Kernel" 的功能。将 AI 引擎下沉至 VS Code 核心层，通过嵌入向量数据库（Vector DB）对本地代码库进行实时索引。

  • Benefit (好处)： 极大地提升代码生成的准确率，支持“一键重构整个模块”而非仅一行代码。

  • Competitors (竞争)： 比起 Cursor，我们的优势在于官方的稳定性以及与 GitHub Copilot 的原生深度协议优化。

  • Delivery (交付)： 通过 VS Code Insider 版本灰度发布，利用现有的 2000 万用户基数快速迭代。

3.2 团队配置（6 人团队）

针对这 16 周的改进任务，角色分配如下：

  • 项目经理 (PM) 1 名： 负责需求定义、跨部门沟通及进度把控。

  • 开发工程师 (Dev) 3 名：

    • 1 名侧重内核（Rust/TypeScript），处理代码索引与性能。

    • 1 名侧重 AI 协议实现（LSP 扩展）。

    • 1 名侧重 UI/UX 实现。

  • 测试工程师 (QA) 1 名： 负责性能压力测试（防止 AI 索引导致卡顿）与插件兼容性测试。

  • UI/UX 设计师 1 名： 负责设计 AI 交互的“非侵入式”界面。

3.3 16 周详细规划

周次 阶段 关键任务
第 1-2 周 调研与设计 进行用户调研，产出 PRD 与 UI 原型；确立本地向量索引的技术方案。
第 3-4 周 架构搭建 开发人员搭建本地索引服务的 MVP 版本，测试评估对 CPU 的影响。
第 5-8 周 核心开发 (Sprint 1) 实现代码全库语义检索功能；UI 设计师输出 AI 交互组件（如内联对话框）。
第 9-11 周 功能集成 (Sprint 2) 实现 AI 直接修改代码（Apply Changes）逻辑；QA 开始介入黑盒测试。
第 12 周 性能优化 针对大型仓库进行压力测试，解决由于索引导致的内存泄漏问题。
第 13 周 内测与反馈 邀请部分软工班级学生（如调研对象）进行 Insider 测试，收集 Bug。
第 14-15 周 修复与磨光 修复反馈的 Bug，完善文档，录制演示视频，优化 UI 细节。
第 16 周 正式发布 在 VS Code 官方博客发布改进版本，进行首个 Release。
posted @ 2026-03-18 15:35  chasing-star  阅读(30)  评论(0)    收藏  举报