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

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

项目 内容
这个作业属于哪个课程 2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里 [I.2] 个人作业：软件案例分析
我在这个课程的目标是 掌握现代软件工程的核心玩法，不光是背理论，更是想弄明白怎么把书上的模型用到真实的、充满变数的开发环境里，培养架构规划和风险规避的能力。
这个作业在哪个方面帮助我 通过调研具体的软件并进行横向对比，了解软件的实际开发流程与后期维护

随着 Notion、Confluence 等知识管理与协作工具的普及，数据隐私和高昂的订阅费用促使许多开发者将目光投向了开源社区。本次案例分析选取了开源界备受瞩目的 AppFlowy（被誉为 Notion 的开源平替）作为主要分析对象，并引入 Docmost（一款开源的实时协作 Wiki 工具）作为竞品进行对比，探讨其产品设计的优劣、软件工程的质量，并规划未来的迭代方向。

第一部分 调研，评测

软件评测

软件使用

image-2


图1：AppFlowy 主界面展示

image-3


图2：AppFlowy 下拉功能菜单展示

AppFlowy 的主要功能与Notion等笔记软件类似，可以选择自己的工作区，创建面板。在笔记页面有丰富的功能，例如AI Transcript，PDF 嵌入分析等新颖功能以及插入Audio，Video，Image等传统功能，作为Notion的开源平替整体体验相对不错。

软件分析

AppFlowy 能够很好地解决用户"构建个人知识库与任务管理"的需求，其通过Block(块)编辑器和多视图数据库(Grid,Board,Calendar)的结合，提供了极高的自由度。

根据我的亲身体验与社区上用户的普遍反馈，我总结出AppFlowy的优缺点如下:

  • 优点
    • 主打“本地优先（Local-first）”和极致的隐私保护，用户拥有数据掌控权。
    • 底层基于Rust和Flutter开发，原生支持跨平台，启动和响应速度极快，远超许多套壳的Electron应用。
    • 社区活跃，定制化潜力大，开源扩展性强。
  • 缺点
    • 中文字体存在简繁体混杂、渲染不规整的问题，整体界面的精致度相较于成熟商业软件仍有差距。
    • 虽然对单机本地支持极好，但多端同步偶尔存在冲突，且多人实时协同编辑的体验尚不成熟。

改进意见

综合上述软件分析，对AppFlowy提出以下改进建议:

  • 修复本地化排版: 重点修复中文字体渲染问题，统一简繁体，提升中文用户的基础阅读体验。

  • 优化协同编辑能力: 解决多端同步冲突问题，优化协同开发体验。

用户调研

为了更客观的对软件进行评价，我邀请了一位非本软工教学班的同学对AppFlowy进行了深度体验与访谈。

  • 采访对象背景: 王祺中同学(软件工程欧阳元新班级)
  • 为何选择TA: TA 平时重度依赖 Typora 进行笔记记录。Typora 擅长单文档的 Markdown 渲染，但在面临知识库体系化构建时往往力不从心。TA 代表了从“纯文本编辑器用户”向“结构化知识库用户”转型的典型群体。
  • 用户痛点与核心需求: 痛点是笔记管理极度不便，功能较为单一。核心需求是需要一个能体系化管理笔记、支持多维视图，且不要过于臃肿的工具。
  • 实际体验的栏目： AppFlowy 的文档编辑块、网格数据库以及层级目录管理。
  • 用户反馈
    • 亮点: 相比 Typora，AppFlowy 提供了丰富的数据库视图和层级管理，极大地便利了知识的归纳；相比 Notion，它显得更加轻量，启动快；且作为开源软件，扩展潜力强。
    • 槽点: 体验过程中遇到了一些不成熟的 Bug；页面 UI 在细节上不够美观；最明显的是中文字体不太正规（简繁体混杂）。

1

2

3

4

评测结论

  • 定性评价： d) 好，不错 （总体评价较为不错。对比本次调研的协作竞品 Docmost，AppFlowy 在离线单机体验和隐私保护上更胜一筹，可作为 Notion 的极佳开源替代品，尤其适合注重隐私的极客和开发者）。

  • 定量评价： 功能丰富度 8.5/10；运行流畅度 9.0/10；界面美观度 6.5/10；本土化体验 6.0/10。

Bug分析与提交

Bug 严重性量化标准说明：
本次评测的 Bug 严重程度以星级（1-5星）进行量化，具体标准如下：

  • ⭐⭐⭐⭐⭐（致命）：导致系统崩溃、数据丢失或核心功能完全不可用，且无替代方案。
  • ⭐⭐⭐⭐（严重）：严重影响核心用户体验或重要功能受阻，但存在繁琐的规避手段。
  • ⭐⭐⭐（中等）：某个辅助功能异常，或在特定高频场景下影响操作连贯性（如 UI 交互静默失败）。
  • ⭐⭐（轻微）：界面偶发错位、字体渲染瑕疵，不影响功能逻辑。
  • ⭐（极小）：极低频场景下的边缘问题或错别字。

Bug1: 新建空白页后立即插入 Block (块) 静默失败

  • 测试环境: Windows 10，AppFlowy v0.11.4

  • 可复现性及具体复现步骤: 在操作较快的情况下必然发生

    • 步骤:
      1. 启动AppFlowy
      2. 点击侧边栏的 + 或 Add a page 创建一个新的空白页面
      3. 立即将光标聚焦到第一行的空行
      4. 点击左侧的 + 图标（或通过输入 /）呼出块选择菜单 (Block Menu)
      5. 点击任意一种块类型（例如：Table 或 To-do list）
      6. 观察现象： 菜单消失，但没有任何元素被插入

  • Bug具体情况描述:
    当新建页面并极其迅速地尝试插入一个新块时，操作会发生“静默失败”。下拉菜单正常关闭，但编辑器内没有任何响应，也没有弹出任何错误提示 (Error toasts)。用户必须在空白处点击一下，或者按几次 Enter 键，才能让插入功能重新恢复正常工作。参见下面的gif

AppFlowy-Bug1

  • Bug分析:

    • 可能成因： 这有可能是一个典型的竞态条件导致的Bug。前端编辑器的 UI 已经渲染完毕并且接受了用户的点击事件，但底层的文档树或状态机尚未完全初始化完毕。前端的插入指令发送给了未就绪的底层模型，导致指令丢失。

    • 严重性： ⭐⭐⭐（影响核心体验）。虽然用户可以通过多按次回车来绕过该问题，但“新建文档并立即输入”是知识管理软件最高频的场景，首次交互的静默失败会严重破坏用户的“沉浸感”，让人觉得软件极其“不跟手”。

    • 未修复原因猜想：开发和 QA 团队在进行功能验收时，往往是按部就班地操作，或者自动化测试脚本在各个步骤之间存在隐式的延迟时间 ，导致这种依赖于“人类手速”触发的初始化时间差问题被遗漏。综合来看，这属于 “测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试”（尤其是缺乏对极端高频并发操作的边界测试）。

  • Bug改进建议:
    在状态同步机制上进行优化。如果底层文档状态尚未准备就绪，前端 UI 应该暂时禁用菜单交互（例如将 + 按钮置灰），或显示一个极短暂的 Loading 状态。根本的修复方案是：通过状态锁或异步回调，确保编辑器 UI 的“可交互状态”严格依赖于底层文档树模型返回的“已就绪”信号。

  • Bug反馈:

AppFlowy-Bug1

image-4

Bug2: 重新安装后软件无法启动（仅在后台运行无界面）

  • 测试环境: Windows 10，AppFlowy v0.11.4

  • 可复现性及具体复现步骤: 在覆盖安装及重装时必然发生

    • 步骤:
      1. 卸载旧版本的 AppFlowy
      2. 下载并安装最新版的 AppFlowy
      3. 双击运行 AppFlowy.exe
      4. 观察现象： 屏幕上没有任何应用窗口弹出，也没有任何报错提示。但打开 Windows 任务管理器，可以发现 AppFlowy.exe 进程正在后台运行（占用约 70MB 内存），只能手动结束进程

  • Bug具体情况描述:
    软件在启动时发生了“静默崩溃”或“假死”。UI 界面完全没有渲染出来，但后台进程却一直挂起。用户除非知道极客的临时解决办法（手动通过 Win+R 进入 %AppData%/io.appflowy 目录并强行删除里面残留的旧数据文件夹），否则软件将永远无法正常打开。参见下图:

AppFlowy-Bug2

  • Bug分析:

    • 可能成因： 可能是状态持久化兼容性故障。卸载软件时，系统并没有清空存放在 AppData 中的本地数据库（SQLite）或窗口缓存配置。新版本启动时，Rust 后端尝试读取旧版残留的、可能发生 Schema（表结构）变更的脏数据。由于未能正确捕获异常（或者 Flutter 前端等待后端数据超时），导致 UI 渲染线程死锁，最终没有任何窗口被创建。

    • 严重性： ⭐⭐⭐⭐（严重阻碍使用）。虽然只是特定场景触发，但对于普通用户来说这是致命的，因为他们完全不知道如何通过删除隐藏的系统文件夹来解决，会直接认为软件“坏了”从而彻底弃用。

    • 未修复原因猜想：开发团队在测试更新流程时，通常是在干净的虚拟机环境（Clean Install）下进行，忽略了带有各种异常历史脏数据的“覆盖安装（Dirty Upgrade）”测试场景。综合来看，这同样属于 “测试把关不严，没有注意在特殊的配置或环境下测试”。

  • Bug改进建议:

    • 短期修复： 在卸载程序中增加“是否保留本地应用数据”的勾选项；
    • 底层架构优化： 在软件的启动初始化流程 (main 入口) 增加全局的 try-catch 异常捕获机制。如果底层数据库读取失败或版本不兼容，不应该直接挂起，而是应该弹出一个安全模式窗口，提示用户：“检测到数据损坏或版本不兼容，是否重置本地数据？”

第二部分 分析

工作量分析

模块 核心子功能 估算时间（人月）
底层架构与数据 本地 SQLite 数据库设计、数据持久化机制、跨平台 FFI 接口封装、数据同步 8-10
核心块级编辑器 Block 树状数据渲染、富文本输入控制、斜杠命令菜单、Block 拖拽机制 10-12
多维数据库视图 Grid/Board 视图渲染、属性字段筛选与排序、多视图动态转换 6-8
前端与 UI 设计 跨平台外壳适配、侧边栏多级页面树、主题切换、国际化与用户设置 4-6
基础设施与测试 自动化 CI/CD 部署、多语言自动化回归测试脚本、打包与分发机制 3-6
合计 - 31-42

考虑到团队 6 人之间的配合问题，最终实现 AppFlowy 的基本功能大约要 8 到 11 个月。

软件质量分析

  • 同类排名: 在“开源笔记/协作工具”赛道中，AppFlowy 的底层架构和性能绝对名列前茅（Top 3），但在用户体验和本地化细节上，目前落后于 Logseq 等同类开源产品，也略逊于其主要对标的商业软件 Notion。

  • 软件工程建议： 该团队在软件工程方面最需要提高的是 “多语言适配”。大量的中文字体和排版瑕疵反映出他们在需求验收阶段缺乏跨文化用户的测试覆盖。建议引入自动化的多语言视觉回归测试，并建立不同语种的 Beta 测试志愿者群。

第三部分 建议和规划

市场现状 (竞品分析: AppFlowy vs Docmost)

  • 市场概况: 知识管理与生产力工具市场潜力巨大。直接用户包括极客、程序员、研究人员，潜在用户覆盖所有需要整理资料的大学生和职场团队。
  • 竞争产品与定位对比:
    • Notion (商业龙头): 占据绝对的商业市场份额，功能大而全，但数据锁死在云端。
    • Docmost (开源竞品)： 主打“多人实时协作”，定位更像是开源的 Confluence。它天生为团队知识库设计，服务端部署依赖强。优势在于多人在线实时协同编辑顺畅；劣势在于单机离线体验差，页面定制自由度不如基于 Block 的编辑器。
    • AppFlowy (本品定位)： 定位为保护隐私的 Notion 开源替代品。优势在于“本地优先”、极致的数据安全和高度自由的多视图数据库；劣势在于团队协作场景下的冲突处理不如 Docmost 完善。

市场与产品生态

  • 核心用户群 (典型用户): AppFlowy 的核心群体是注重数据安全、有一定动手能力的开发者、极客和专业知识工作者。他们通常具备较高的学历（本科及以上），对数字资产隐私有强烈的“表面需求”，同时具有构建高度定制化个人知识库的“潜在需求”。
  • 用户群体之间的关系 (用户生态): AppFlowy 的开发者用户与普通使用者之间形成了良好的“反哺”生态。开发者不仅是重度用户，还会通过提交 PR、编写插件或提供多语言翻译来完善产品；而普通非技术用户则提供丰富的真实使用场景和 Bug 反馈。这种开源社区的共建关系是构建其产品生态的核心护城河。

产品规划(NABCD)

基于上述对竞品 Docmost 的分析，以及纯本地笔记在信息关联上的局限性，我决定在 AppFlowy 现有基础上新增两大核心功能 ：A. 多人实时协同编辑引擎（补齐对标 Docmost 的短板，进军团队协作市场）；C. 双向链接与全局知识图谱视图（强化个人知识库的网状关联能力）。

NABCD分析:

  • N (Need 需求)： 用户不只满足于单机记录，他们需要在保护隐私的前提下与团队进行协作（Docmost 证明了这一市场的巨大需求）；同时，面对海量笔记，用户需要网状的图谱来辅助发现灵感。

  • A (Approach 做法)：

    • 对于协作：引入基于 Yjs 框架的 CRDT（无冲突复制数据类型）算法，结合 Rust 极速服务端，提供低延迟的协同体验。

    • 对于双链：开发基于 WebGL 的力导向图（Force-directed graph）组件进行可视化展示，并在底层建立元数据关联表。

  • B (Benefit 好处)： 打破“只能单机自嗨”的局限，填补 AppFlowy 在团队场景下的薄弱环节；大幅提升个人知识的串联效率。

  • C (Competitors 竞争)： 相比 Docmost，我们不仅能协作，还有更强大的个人多视图数据管理底座和断网可用性。

  • D (Delivery 交付)： 依托现有的 GitHub 开源社区发布 Beta 版，吸引极客用户试用反馈，并通过技术博客介绍我们的 CRDT 协同架构来吸引开发者关注。

角色配置与 16 周详细计划

团队角色配置

角色 人数 主要职责
项目经理 (PM) 1 负责竞品调研、需求定义、进度把控、协调开发资源以及与开源社区对接。
后端开发 2 负责搭建 Rust 实时协同服务端框架、CRDT 算法实现、数据库表结构设计及接口开发。
前端开发 1 负责双向链接知识图谱的前端可视化开发、协同模块的 UI 接入以及跨平台适配联调。
UI/UX设计师 1 负责新功能的高保真交互设计、图谱动效原型以及界面的本地化排版与细节优化。
测试工程师 1 负责编写自动化测试用例，进行高并发协同压力测试、断网边界测试及多语言回归测试。

16周甘特图规划：

阶段 周次 核心任务 责任人 产出物/里程碑
需求与设计 W1 - W2 竞品调研（深度拆解 Docmost 协同），确定 CRDT 选型，图谱视图 UI 原型设计 PM, UI PRD 文档，UI 高保真图
架构与基建 W3 - W4 搭建 Rust 实时协同服务端框架，设计双向链接的本地 SQLite 表结构 后端 (2人) 数据库 Schema，接口定义
核心开发 Sprint 1 W5 - W7 (协同)：实现基础文本块的实时双向同步；
(双链)：前端 [[ ]] 语法解析与关联		 前端, 后端 协同模块 Alpha 版本
核心开发 Sprint 2 W8 - W10 解决复杂视图（如 Grid）的协同冲突；整合前端图谱数据接口 前端, 后端 核心功能联调通过
图谱视图开发 W11 - W12 前端引入图形渲染库，完成全局知识图谱的可视化开发与动效调试 前端, UI 知识图谱功能演示
综合测试与修复 W13 - W14 进行高并发协同压力测试、断网重连测试及回归测试；全员修 Bug 测试, 全员 测试报告，Bug 清单清零
Beta 发布 W15 社区发布 Beta 版，收集种子用户反馈，进行最后的功能与体验微调 PM, 全员 用户反馈分析报告
V1.0 正式发布 W16 代码冻结，完善开发者文档，合入主分支并向全网发布 全员 新版本正式 Release
posted @ 2026-03-18 19:07  Tanhhhhtjy  阅读(134)  评论(0)    收藏  举报