[I.2] 个人作业：软件案例分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [I.2] 个人作业：软件案例分析 |
| 我在这个课程的目标是 | 学习软件工程的基本理论与实践方法，通过团队合作编码能力训练和工程协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过调研现有软件增进对软件工程的理解 |
选题
Files (files-community/Files) 是一款基于 MIT 协议开源的 Windows 文件管理器。它能提供类似于 Windows 资源管理器(下称 File Explorer)的功能，并且支持文件预览、多标签页、双栏窗口、git集成和其他高度可定制的丰富特性，可以作为 Windows 资源管理器的替代品。
调研与评测
软件评测
软件使用
Files 基于 WINUI 3 开发，采用 Fluent Design 设计语言，支持 Windows 10 及更新版本。
打开 Files，在短暂(不到1s)的加载时间后，主界面呈现在用户面前。侧边栏与 File Explorer 布局类似，有一个额外的 Tags 区域，用于访问自定义文件标签。
主界面：
打开一个目录，在列表模式下，界面与 File Explorer 类似。右侧边栏可以展示文件的详细信息或预览，预览支持图片、Office 文档、PDF、视频等多种文件类型。底部状态栏有“在 VS Code 中打开”和 git 操作按钮。
Files 共有五种视图模式：详情、列表、卡片、网格和分栏，前四种与 File Explorer 类似，而特有的"分栏"布局下，主界面分为若干纵列，每列显示一个目录，直观地展示文件夹的层级结构。
每种视图均可自定义项目尺寸。打开“自适应布局”选项，Files 会根据页面内容和历史设定自动调整视图模式。
Files 支持丰富的自定义选项。打开设置界面，可以调整语言、外观、布局、快捷键等各种设置。
软件分析
Files 经过数年迭代开发，目前已经发布 3.9.1 版本。在我的日常使用场景中可以完全替代 File Explorer，而且功能更加丰富，界面更加美观。
从以下几个角度评价 Files：
- 界面：Fluent Design 设计语言，风格现代化，界面美观。相比之下，File Explorer 的界面从 Windows 7 时代开始就没有太大变化。
- 功能：绝大部分 File Explorer 的功能在 Files 中都能找到对应（例外：高级文件权限设置，右键拖拽文件的菜单等），而 Files 还支持更多额外功能。
- 准确度：作为替代品，Files 在搜索、访问网络存储设备、与外部应用的互操作（拖拽）等方面的行为存在与 File Explorer 的不一致，其中一些行为会影响用户体验。
- 性能：Files 在大部分场景下的性能表现良好，但部分用户反映使用时出现明显卡顿。
- 稳定性：Files 偶尔会发生崩溃，但如果不是故意触发，频率较低。相比之下，File Explorer 久经沙场，几乎不会出现可以稳定复现崩溃。
改进意见
- 继续提升软件稳定性，减少崩溃发生。
- 增进与 File Explorer 行为的一致性。
- 改善键盘操作体验，部分功能在仅使用键盘时不可达。
- 改进性能
采访
评测结论
e) 非常推荐
Bug 分析和提交
这个简单。我给 Files 找过不少bug，还修过不少bug。但是我们这里找一些没提交过的。
下述 bug 将于不久后提交 issues 到 Files 仓库。
严重性评级标准
| 严重性 | 描述 |
|---|---|
| ⭐⭐⭐⭐⭐ | 系统完全崩溃或不可用。 造成严重数据丢失或损坏。 导致安全漏洞，用户数据泄露。 |
| ⭐⭐⭐⭐ | 主要功能模块无法正常工作。 可能导致数据损坏。 |
| ⭐⭐⭐ | 部分功能模块受影响，但不影响核心功能。 用户可以找到临时解决方案。 对用户体验有一定影响，但不严重。 |
| ⭐⭐ | 仅影响极少部分功能或边缘情况。 用户体验影响轻微，几乎不影响正常使用。 有临时解决方案或可以忽略。 |
| ⭐ | 纯粹的视觉或排版问题，不影响任何功能。 用户体验影响极小，可以忽略不计。 |
BUG1: git merge 冲突状态时使用 Files 集成工具切换分支导致崩溃
测试环境： Windows 11 10.0.26100.3323, Files 3.9.1.0
可复现性： 100% 复现
复现步骤：
首先创建一个冲突状态的 git 仓库：
mkdir test
cd test
git init
echo "master" > test.txt
git add test.txt
git commit -m "master"
git branch b1
git branch b2
git checkout b1
echo "b1" > test.txt
git add test.txt
git commit -m "b1"
git checkout b2
echo "b2" > test.txt
git add test.txt
git commit -m "b2"
git checkout b1
git merge b2
在 Files 中进入 test 目录，点击 git 集成工具，切换到 b2 或 master 分支，Files 立即崩溃。
log:
2025-03-16 12:05:05.8033|Error|LibGit2Sharp.UnmergedIndexEntriesException: cannot create a tree from a not fully merged index.
at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
at LibGit2Sharp.Core.Proxy.git_stash_save(RepositoryHandle repo, Signature stasher, String prettifiedMessage, StashModifiers options) in /_/LibGit2Sharp/Core/Proxy.cs:line 2854
at LibGit2Sharp.StashCollection.Add(Signature stasher, String message, StashModifiers options) in /_/LibGit2Sharp/StashCollection.cs:line 129
at Files.App.Utils.Git.GitHelpers.Checkout(String repositoryPath, String branch)
at Files.App.Views.Shells.BaseShellPage.GitCheckout_Required(Object sender, String branchName)
at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_0(Object state)
at Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext.<>c__DisplayClass2_0.<Post>b__0()
分析
会用到这个功能的用户看到 log 一定可以理解发生了什么。对于 Files 开发者来说，应该 catch 所引用库的异常，然后给用户一个友好的提示。
-
成因：开发者未处理 Git 操作时抛出的异常。
-
严重性：⭐⭐⭐
用户只需要使用 Git 命令行工具或其他 Git GUI 客户端即可避免此问题。考虑到此功能的目标用户群体，这是一个很影响体验但不是特别严重的问题。但是如果用户在 Git 操作时同时在后台执行复制等操作，则可能导致数据不一致。
-
开发者未修复的原因：开发者可能没有意识到这个问题，即未对这个边界情况做测试。
BUG 改进建议
预期行为：Files 不应该崩溃，而是应该告知用户当前操作无法完成的原因。
改进方案：
- 捕获 Git 操作时抛出的异常，避免程序崩溃。
- 给用户一个友好的提示，告诉用户当前操作无法完成的原因。
BUG 反馈
https://github.com/files-community/Files/issues/16934
我可能会自己交 PR，也可能不会。
BUG2: 内置解压缩工具不能解压 .gz 压缩文件
测试环境： Windows 11 10.0.26100.3323, Files 3.9.1.0
可复现性： 100% 复现
复现步骤：
- 选中一个 .gz 压缩文件
- 观察到 Files 识别到压缩文件，在工具栏中出现解压缩按钮
- 点击解压缩按钮，Files 状态栏显示“解压失败”，没有相关日志。
分析
-
成因：Files 内置解压缩工具不支持 .gz 格式的压缩文件。
-
严重性：⭐⭐
用户可以使用其他解压缩工具解压缩 .gz 文件。但是考虑到 Files识别了 .gz 文件并显示了解压缩按钮，用户会认为 Files 支持 .gz 文件的解压缩，这很容易引起用户的困惑。
-
开发者未修复的原因： .gz 压缩格式在 Windows 平台上不常见，开发者可能没有做相关测试。
BUG 改进建议
预期行为：Files 显然应当支持 .gz 文件(以及其他罕见压缩文件格式)的解压缩。
考虑到 Files 是引用了第三方库实现压缩功能，可能是第三方库不支持 .gz 文件的解压缩。Files 开发者可以考虑替换第三方库，除此之外似乎没有更好的解决方案。
BUG 反馈
还没交
分析
- 工作量分析：
目前， Files 3.9.1.0 由大约 10 位有丰富 C#、Windows 开发经验的核心开发者和超过 40 位 commit 超过 10 次的开发者，经过 6 年时间开发形成。对于 6 位计算机专业本科毕业的开发者，如果想要完整重复实现 Files 的功能，需要的时间可能不会少于 5 年。
- 软件质量分析：
Files 作为文件管理器，最重要的竞品是 Windows 自带的 File Explorer，还有开源的 Explorer++ 和付费软件 Total Commander等。
与其他文件管理器相比，Files 的优势在于界面美观、功能丰富、易用性高，劣势在于 Files 的稳定性不如 File Explorer 和一些竞品。
在开源第三方文件管理器中，Files 以 36.5k Stars 的优势取得当之无愧的第一。 但其代码质量相比微软的 File Explorer 差距。
该项目的一个问题是提交代码不需要撰写测试，导致项目中测试覆盖率很低。在软件工程方面，如果增加对非交互部分测试的要求，可以提高软件质量，减少 bug 数量，如上方提到的两个 bug 均可通过测试避免。
建议和规划
- 市场现状：
- 市场概况：Windows 系统用户数量庞大，文件管理器是每个用户必备的软件之一，但绝大多数用户使用 Windows 自带的 File Explorer。少部分用户希望通过第三方文件管理器提升效率。
- 竞品分析：Files 与 File Explorer 的竞争关系不大，因为后者是 Windows 内置软件。Files 的竞品主要是其他第三方文件管理器。
- 产品定位：与其他开源竞品相比，Files 功能全面、界面美观、更新积极。与付费竞品相比，Files 最大的优势在于可以免费获取。
- 市场与产品生态
- 这个产品的核心用户群是自带 File Explorer 不满意的 Windows 用户，这些用户一般对 Windows 的了解程度较高，对软件的要求也较高。
- 这个产品不依赖用户群
- 这个产品的功能是单一的文件管理器，不依赖其他软件，也不被其他软件依赖
- 产品规划
- Files 的核心功能不应当改变。
- 用户通过 Github 和 Discord 反馈了很多 bug 和 feature request，可以整理这些反馈，按一定的优先级进行处理。
