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

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

项目	内容
这个作业属于哪个课程	2026 春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	[I.2] 个人作业：软件案例分析
我在这个课程的目标是	获得软件工程师应有的初步能力
这个作业在哪个 具体方面 帮助我实现目标	分析真实的软件，从初学者的角度调研软件工程的核心思想和设计要点

写在前面

选题让人苦恼。

博猪想就开源工具开展“软件案例分析”，但是苦于自己根本就没用过什么出名的开源工具，既要能横向对比还要广为人知，笨人考虑了下载工具 Motrix、隐私社交软件 Signal 等，但是一没有对比软件，二用的不多，感情不深。

纠结无果，润去做别的事了，下载老师发的资料，是一个.rar 文件，双击点开压缩包浏览内部内容...OHHH！

我暗暗惊叹，开源界的上古真神竟然被我遗忘了！后来，你已经知道我要讲什么了（

本次软件分析对象选取的是 7-zip 这款开源的文件解压缩工具，在后续的对标分析中选取了同样开源但是更为现代化的 PeaZip。

调研与评测

软件测评

1、软件使用

7-zip 貌似 是一个很简单很纯粹的软件，没有广子，没有现代化 UI，响应速度极快，安装包又极小，说轻量级一点不过分。最左上角是系统栏，下面是对文件的操作，包括添加、解压、移动等我们常用的压缩包操作，再往下就是一个常见的资源管理器的 UI，简单的路径，双击打开，左上角返回上一层目录。

2、软件分析

作为一个解压工具，7-zip 提供的最常用的就是右键文件选择用 7-zip 打开，或者设置默认选项后双击打开，进入到主页面之后就可以进行一系列对压缩包的处理操作，日常其实最常用的也就是解压缩，或者是对压缩包内部的文件进行增删。

然后本次作业还让我后知后觉一个功能————“测试”，我不确定这个内容是否有相当一部分受众，但是我认为在 解压缩前确保数据的完整性 对于游戏资源、系统镜像等重要数据相当重要。

最后值得一提的是，与大部分商业软件不同的是，开源软件往往会提供命令行工具，虽然笨人平时也没有用到，但是还是 7z --help 看了一下：

（这里考虑了一下，放命令行截屏有些眼睛不友好，遂复制粘贴，如果你读到这里了，博猪提醒你 记得休息眼睛 ！）

7-Zip 25.00 (x64) : Copyright (c) 1999-2025 Igor Pavlov : 2025-07-05

Usage: 7z <command> [<switches>...] <archive_name> [<file_names>...] [@listfile]

<Commands>
a : Add files to archive
b : Benchmark
d : Delete files from archive
e : Extract files from archive (without using directory names)
h : Calculate hash values for files
i : Show information about supported formats
l : List contents of archive
rn : Rename files in archive
t : Test integrity of archive
u : Update files to archive
x : eXtract files with full paths

<Switches>
-- : Stop switches and @listfile parsing
-ai[r[-|0]][m[-|2]][w[-]]{@listfile|!wildcard} : Include archives
-ax[r[-|0]][m[-|2]][w[-]]{@listfile|!wildcard} : eXclude archives
-ao{a|s|t|u} : set Overwrite mode
-an : disable archive_name field
-bb[0-3] : set output log level
-bd : disable progress indicator
-bs{o|e|p}{0|1|2} : set output stream for output/error/progress line
-bt : show execution time statistics
-i[r[-|0]][m[-|2]][w[-]]{@listfile|!wildcard} : Include filenames
-m{Parameters} : set compression Method
-mmt[N] : set number of CPU threads
-mx[N] : set compression level: -mx1 (fastest) ... -mx9 (ultra)
-o{Directory} : set Output directory
-p{Password} : set Password
-r[-|0] : Recurse subdirectories for name search
-sa{a|e|s} : set Archive name mode
-scc{UTF-8|WIN|DOS} : set charset for console input/output
-scs{UTF-8|UTF-16LE|UTF-16BE|WIN|DOS|{id}} : set charset for list files
-scrc[CRC32|CRC64|SHA256|SHA1|XXH64|*] : set hash function for x, e, h commands
-sdel : delete files after compression
-seml[.] : send archive by email
-sfx[{name}] : Create SFX archive
-si[{name}] : read data from stdin
-slp : set Large Pages mode
-slt : show technical information for l (List) command
-snh : store hard links as links
-snl : store symbolic links as links
-sni : store NT security information
-sns[-] : store NTFS alternate streams
-so : write data to stdout
-spd : disable wildcard matching for file names
-spe : eliminate duplication of root folder for extract command
-spf[2] : use fully qualified file paths
-ssc[-] : set sensitive case mode
-sse : stop archive creating, if it can't open some input file
-ssp : do not change Last Access Time of source files while archiving
-ssw : compress shared files
-stl : set archive timestamp from the most recently modified file
-stm{HexMask} : set CPU thread affinity mask (hexadecimal number)
-stx{Type} : exclude archive type
-t{Type} : Set type of archive
-u[-][p#][q#][r#][x#][y#][z#][!newArchiveName] : Update options
-v{Size}[b|k|m|g] : Create volumes
-w[{path}] : assign Work directory. Empty path means a temporary directory
-x[r[-|0]][m[-|2]][w[-]]{@listfile|!wildcard} : eXclude filenames
-y : assume Yes on all queries

可以看到还是相当丰富的，< Commands > 当中可以看到各种关于文件们 files 和多种格式 formats 的操作，但是...benchmark 是怎么一回事 🤔？基准测试？和我们在 GUI 中看到的 【测试】 一样吗？执行了 7z b 的指令后，得到了下面的结果：

7-Zip 25.00 (x64) : Copyright (c) 1999-2025 Igor Pavlov : 2025-07-05

Compiler:  MSC 1400.140040310
Windows 10.0 26200 : Microsoft Hv : Hv#1 : 10.0.26100.8.0.8036
x64 6.BA02 threads:16 128TB f:300005F310C2774C
13th Gen Intel(R) Core(TM) i5-13500H
(B06A2 : Intel64 Family 6 Model 186 Stepping 2) (->) 3187 MHz

1T CPU Freq (MHz):  4586  4140  4264  4620  4528  4546  4473
8T CPU Freq (MHz): 755% 3718   762% 3768
16T CPU Freq (MHz): 1329% 3273   1388% 3248

RAM size:   16108 MB,  # CPU hardware threads:  16
RAM usage:   3559 MB,  # Benchmark threads:     16

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:      70838  1364   5054  68912  |     986640  1485   5666  84131
23:      66601  1388   4889  67858  |     964723  1476   5655  83455
24:      64710  1421   4897  69576  |     942664  1497   5525  82711
25:      60911  1436   4844  69546  |     918265  1505   5427  81699
----------------------------------  | ------------------------------
Avr:     65765  1402   4921  68973  |     953073  1491   5568  82999
Tot:            1446   5245  75986

下面的表格很有意义，左右两侧分别是压缩（Compressing）与解压缩（Decompressing）的性能，Dict 指的是 压缩字典，Dict n 就指的是 2^n 字节的内存，可以理解为压缩字典包含的 内存越多，算法越容易找到 更多、更远的重复内容，从而 提升压缩率，与之相对的代价就是需要系统预留的内存就越多。

同时我们可以注意到解压缩速度和压缩速度完全不在一个量级，我们可以用平均数粗略估计一下 953073/65765≈14.5 倍，结合字典的构建与检索想想也确实如此，压缩需要反复构建更新字典，解压缩只需要查表输出，显然后者对于 CPU 更轻松。

最后我们可以看到 16 线程在 7-zip 的并行计算算法下的利用率高达 1300+%，这里参考 Gemini 3.1 的回复：

作为一个拥有 16 个逻辑线程的 CPU，这一数值意味着 7-Zip 在执行压缩任务时，能够同时调度几乎所有的核心进行高效并行运算，平均负载率超过了 85%。这一测试结果充分证明了 7-Zip 在软件工程设计上具有极强的并行处理能力。相比于许多仅支持单核处理的传统工具，7-Zip 通过科学的任务切分和调度策略，显著提升了处理海量资源时的效率，这正是其能够成为开源界标杆软件的核心原因之一。

在解决用户需求上，7-zip 做的应该还是相当令人满意。如果鸡蛋里挑骨头地说，我貌似没有找到 格式转换 的功能，无论是确实没有还是隐藏过于深入，可能都有待改善。

最后我们列表总结一下 7-zip 在各方面的优缺点：

维度	优点	缺点
数据量（处理效率）	对海量碎文件处理极快，支持多线程并行，硬件资源占用极低且稳定。	在处理超大单一文件（如数十 GB 的镜像）时，内存分配策略有时较为保守。
界面	极致精简，Windows 原生风格，无任何多余装饰，启动响应速度极快。	UI 风格过于陈旧，图标像素化严重，缺乏现代感。
功能	格式支持全面；拥有功能强大的 CLI 工具，利于自动化。	缺乏现代化的文件管理特性，如云端集成、格式转换、主题切换等。
准确度	校验算法严苛，提供 CRC/SHA 校验，具备极高的数据还原可靠性。	错误报错提示信息较为底层，缺乏对普通用户友好的修复建议。
用户体验	完全免费无广告，安装包体积小，系统集成度高，用起来清爽高效。	对初学者存在一定学习曲线，部分功能难以发觉，缺乏引导机制。

3、改进意见

1、稍微优化一下界面，不会给新用户一种上年代的感觉，可能会减少初见好感。

2、对某些功能按钮增添 光标停留时简述功能 介绍的功能，就比如“测试”可以添加描述“对文件的完整性校验”。毕竟不是每个用户都有极大的耐心阅读“帮助”当中的超长指导书。

4、用户调研

采访对象：欧阳元新老师班的同学

采访原因：文件压缩/解压缩对学习工作影响较大

用户需求：高效地压缩/解压缩文件

5、评测结论

评估指标	分数占比	评价维度 (参考因素)	你的评分
性能表现	25 分	压缩/解压速度、资源占用率、多线程利用率	25
功能完备性	20 分	格式支持广度、命令行工具(CLI)的强大程度	20
交互与 UI	15 分	界面简洁度、符合系统操作习惯、学习曲线	5
稳定与可靠	20 分	完整性校验机制、报错准确度、几乎无崩溃	20
体验与生态	20 分	免费开源、无广告、更新频率、社区文档	20
总分	100 分		90

综合上述量化指标打分，我给出一个夯中夯：e)非常推荐，唯一的扣分点就是 UI 吧，想不到任何其他缺点。

Bug 分析和提交

测试环境

• 操作系统：Windows 11 (26200.8036)
• 软件版本：7-Zip 25.00 (x64)

量化标准

指标	量化标准
核心业务逻辑崩溃、严重的数据损坏/丢失、存在可被利用的恶意代码执行漏洞	⭐⭐⭐⭐⭐
核心功能部分失效（但有绕行方法）、关键数据泄露、导致系统资源异常耗尽	⭐⭐⭐⭐
非核心功能的性能瓶颈或逻辑错误、用户体验受损、操作路径冗长或反馈不清晰	⭐⭐⭐
界面显示异常（排版错乱）、拼写错误、不影响正常使用的偶发 UI 小故障	⭐⭐
针对软件性能或交互体验的非必要改进建议，对功能完整性无影响	⭐

BUG1：突发事件下的临时文件残留

• 具体情况描述

  在解压缩较大文件时，我们从任务管理器清理 7zip 的后台，任务会中断，并在 %LOCALAPPDATA%\Temp\ 目录下生成临时文件夹，内含一个残留的、解压缩一半的文件。

  如图所示，我们解压缩.gz 文件后得到一个.tar 文件，我们用 7zip 的完整性校验做测试的结果如下：

不出意料地报错了，证明了这个文件的不完整。更严重地是，重启 7zip 后、甚至重 新执行解压缩任务 后，这个临时文件仍然不会消失。不过好在 temp 文件夹会不定期自行清理，严重性等级给到 3⭐，虽然不影响程序核心压缩逻辑，但是有可能造成用户隐私泄露或者磁盘空间被大量占据，会导致体验感较差。

• 分析与改进意见

  7zip 可能在这一部分缺少异常捕获机制，没有用类似 try-finally 来确保程序退出时删除临时文件。至于团队为什么不修复呢？我觉得大抵不是没有关注到或者懒得修复，我想可能是因为为了追求最高的性能，开发者团队可能减少了这种频繁的 I/O 同步检查，以 避免影响解压速度，毕竟 7zip 仍然是一个追求极致性能的软件，以极低的概率出现可还原的内存事故，也许也是一种技术权衡。

  在改进意见上，相比建立一个轻量级的监视进程，我更想给 文件做句柄标记 来解决问题，每次在程序启动的时候，自动扫描并删除上次异常产生的临时文件夹。当然这样也会影响启动性能，但是总比牺牲解压缩性能好，归根 结底算法高效，压缩/解压缩性能极高 才是 7zip 最核心最具竞争力的特点。

BUG2：磁盘空间不足时的静默中断

• 具体情况描述

  当解压目标磁盘的剩余空间小于压缩包解压后的总大小时，7-Zip 并没有在解压初期进行磁盘空间预检。当磁盘写满后，程序进程进入 挂起 的状态，并 未弹出任何有效的空间不足预警提示，导致用户误认为软件已死机或者程序运行已结束。这一点上会带来未知的后果，用户事先无法感知磁盘已满，事后无法确定数据完整，可能会引发一系列数据一致性问题。

  虽然核心解压逻辑正确，且可以通过清理磁盘后恢复，但由于 严重缺乏交互反馈，用户体验极其糟糕，甚至可能导致用户在困惑中误操作从而丢失部分解压进度，严重性等级给到 3⭐。

• 分析与改进意见

  磁盘空间不足的情况下，IO 系统一定会给上方的应用层，也就是 7-zip 返回一个错误码，但是不知为何这个错误码并没有在用户端体现出来，说明 7zip 的 错误处理 和 用户交互 之间仍然存在一定 不同步 的情况。

  我的改进思路大致如下：在解压之前对目标磁盘的可用空间进行校验，如果确定剩余空间不足，终止解压操作并弹窗预警。

分析

工作量分析

6 位计算机本科毕业生外加一位专业 UI 设计师，从头构建 7-zip 级别的压缩工具，这其中包括我们要设计一个和 LZMA2 比肩的高效引擎、要支持 30+解压格式、要和 Windows Shell 深度集成、要构建完善的 CLI 工具以及 Benchmark 性能测试等。

工作内容	预计耗时（周）	人员分配	难点分析
压缩算法引擎开发	14-16	3 *算法开发	需要从头了解LZ77 变体算法，并用 C/C++实现极致性能的内存操作，同时需要着重并发设计。这一部分实在难以估量，但是可以充分肯定压缩算法至高的地位与难度。
多格式兼容与协议解析	8-10	2 *业务逻辑开发	需要阅读每种格式的官方白皮书，编写对应的解析器，虽然大模型能帮助提速，但是仍要注意大量的细节处理，其中也包括我们之前提到的错误处理，这一点上结合实际情况的工程师应该做得比大模型完善许多。
系统集成与 UI/CLI 交互开发	6-8	2*系统交互开发（包含算法开发者）	将右键菜单嵌入资源管理器，需要处理复杂的 COM 组件编程和进程外通信；还原或者升级文件管理器界面并支持几十个命令行参数的解析。
边界测试、内存泄漏排查与稳定	6-8	全员交叉测试+1*专职 QA	需要构造海量的极限测试样例，测试往往在项目后期让人压力倍增，测试出每一个 bug 都有可能让开发工作从头来过。

总而言之，对于 6 名本科毕业生，调用现成的开源库做一个带界面的压缩软件，也许不用一个月就全面竣工了。但是如果要对标 7zip 这种极致的 工业级 工具，还是大概率要花上一年左右的时间，甚至更长。这正是 7zip 作者 Igor Pavlov 的伟大之处，数十年如一日打磨底层汇编和 C++代码，这也是为什么市面上很大一部分竞品都是套壳于 7zip 核心算法的核心原因。

软件质量分析

优劣分析与同类产品排名

我们将对比 WinRAR 以及同样开源且注重现代 UI 的 PeaZip：

• 7zip 的优势很明显：Igor Pavlov 独创的 LZMA/LZMA2 算法仍是绝对的行业标杆。性能极强的同时，7zip 保持着极致的轻量与纯粹，无弹窗无广告甚至几乎无额外的系统开销。此外，完善的 CLI 支持使 7zip 也具备强大的自动化能力。

• 7zip 的劣势更多浮于表面，UI 设计的落后，用户交互感较低等。我个人觉得可以用极低的时间精力成本大幅优化这些缺点，但是保留至今也不乏是 Igor Pavlov 坚持极致纯粹的 个人选择。

  综上，单从核心算法来看，7zip 是毫无疑问的 第一。综合软件工程多维度评估，客观估计是 前三名左右 的位置。

具体建议

优化算法性能的同时更多地关注 防御性编程 和 架构解耦，前者可以尽可能减少 bug 的出现，后者则可以支持 UI 独立于核心算法代码，有利于发展 UI 开发。通过这两点，用户可以从内外两个角度提升一定的体验感。

建议与规划

市场现状

竞争产品

目前解压缩软件市场虽然属于传统基础工具领域，但竞争依然激烈。主要竞品包括：

• 商业巨头：WinRAR（历史最悠久，独占 RAR 压缩算法，但商业化严重，充斥广告弹窗）。
• 现代商业新秀：Bandizip（以极致的解压速度和极佳的现代 UI 著称，但近期也开始引入广告和付费专业版）。
• 开源同位体：PeaZip（与 7Zip 同源或兼容，主打全能的格式转换和现代跨平台 UI，但相对臃肿）。
• 系统原生：Windows 11 原生资源管理器（已开始原生支持 ZIP、RAR、7Z 的解压）。

产品定位、态势与优劣势

• 7Zip 的定位：极致纯粹的高性能开源归档引擎。
• 优势：在压缩率（LZMA2）和性能消耗上具有碾压性优势；完全免费无广告；拥有强大 CLI 接口。
• 劣势：UI 极度老化，劝退普通小白用户。
• 竞争态势：随着 Windows 11 原生支持 7Z 格式解压，7Zip 面临着“普通用户流失到系统原生工具，颜值党流失到 Bandizip”的严峻态势。7Zip 必须在保持核心性能优势的前提下，补齐用户体验的短板，才能守住乃至扩大基本盘。

市场与产品生态

核心用户群

• 核心群体：所有电脑相关上班族，高校学生，游戏爱好者。
• 典型用户画像：
  • 背景：男，21 岁，计算机本科生。
  • 爱好与收入：喜欢折腾各种开源软件、大型游戏 MOD，无稳定收入。
  • 表面需求：需要一款能解压几 GB 到几十 GB 游戏资源的免费无广告工具。
  • 潜在需求：希望软件稳定不崩溃，对多种解压格式文件都能正确解压。

产品生态构建

7Zip 的本质不仅是一个终端产品，更是解压缩领域的核心设施。

7zip 及其子产品与市场上其他产品之间，其实有一定的上下游关系。其中 PeaZip、NanoZip 等工具的底层核心都是直接调用 7zip 的开源内核。如果我是 PM，我们可以利用这种内核外包装的共生关系，构建一个以 7zip 引擎为核心的开源繁荣生态：

• 确定 API 标准，实现插件化生态：剥离 UI 层与核心层，将 7z.dll 封装成标准且开放的 API 接口，鼓励全球开发者基于此核心开发各种子领域的 UI 工具。
• 构建双层用户群：提供 7zip 官方极简版与类似于 PeaZip 的高级 UI 版，分别面向程序员等专业人士与普通上班族，这两个版本的软件仍然以 7zip 为内核，持续地贡献更多的数据与反馈，从而形成一个完美的闭环产品生态。

产品规划

新功能设计与 NABCD

新功能设计有如下两点：

1. 适配 Win11 的现代化 UI 界面
2. 智能环境预检机制

NABCD 分析如下：

• Need：用户 苦于老旧的 UI 久矣；同时，在边缘情况下的文件残留与无交互信息给用户带来了困扰和数据安全隐患。
• Approach：采用“前后端分离”架构。底层继续调用 7z.dll 引擎保证性能；引入“中间件层”负责监控磁盘空间和系统状态，执行事务性解压；顶层使用轻量级的现代 UI 框架重构界面。
• Benifit：老用户依然能享受极速压缩，新用户不再被丑陋的界面劝退；尽可能解决极端情况的 bug，极大提升软件的健壮性。
• Competitors：对比 WinRAR 有无广告优势，对比 Bandizip 有完全免费和开源优势，对比 PeaZip 有原生体验优势（可以自由选择极简版或者美化版）
• Delivery：通过 7zip 官方网站、SourceForge、Github 等渠道开源公布，继续提交到 Microsoft Store 获取官方推荐，也可以进一步寻找知名评测博主做首发评测引流。

团队角色配置

1. 项目经理 (PM) 兼 架构师 (1 人)：负责进度把控、需求拆解，以及核心算法引擎与 UI 层的 中间件接口设计。
2. UI/UX 设计师 (1 人)：负责全套 现代化界面设计、右键菜单交互逻辑重构。
3. C++ 底层开发工程师 (1 人)：负责与原版 7z.dll 对接，开发智能预检机制（监控磁盘空间、临时文件清理等拦截逻辑）。
4. GUI 前端开发工程师 (2 人)：负责根据设计图，使用现代框架实现主界面和配置界面。
5. 测试工程师 (QA) (1 人)：专职负责各种边界条件的自动化测试脚本编写（如极长路径、磁盘满载、强杀进程等）。

详细计划

时间周期	阶段核心目标	主要推进任务（开发与测试重点）
第 1-2 周	需求对齐与 UI 重构设计	明确 7-Zip 现代化重构的功能边界； 完成全新主界面及操作交互的高保真视觉设计。
第 3-4 周	引擎封装与基础联调	搭建项目开发环境； 完成对底层 7z.dll 核心压缩引擎的 API 封装与基础解压/压缩指令联调。
第 5-6 周	主流程开发与界面绑定	完成现代 UI 静态界面的代码开发； 将底层指令与 UI 进度条、文件管理模块进行绑定，跑通核心业务流。
第 7-8 周	异常防御机制开发（痛点修复）	实现“磁盘空间智能预检”与“异常终止时的临时文件回收”机制，彻底解决原版静默终止与残留 Bug。
第 9-10 周	系统级集成与外壳适配	开发 Windows Shell 扩展组件； 将软件深度集成至 Windows 11 的右键上下文菜单，优化交互层级。
第 11-12 周	全量测试与体验打磨	开展覆盖全平台的兼容性测试、断电/强杀等破坏性边界测试； 集中修复中高优先级 Bug，优化高分屏显示。
第 13-14 周	Beta 公测与社区反馈	发布 Beta 测试版至开源社区； 开展团队内部试用，收集用户的真实反馈并快速迭代。
第 15-16 周	代码封板与正式发布	停止新功能开发（代码封板），专注修复致命/严重缺陷； 撰写发布文档，V1.0 现代化智能重构版正式上线。