以用户的视角看体验，以开发的视角看软件。
本文对本学期软件工程课程进行总结，记录项目开发的过程与心得体会，贯穿技术与感悟。
回溯
期望
软件工程，是指导软件开发的方法论；而实践软件工程，又能反作用于方法论，让理论更贴近实际需求。
在学习本课程之前，我参与过一些需求评审。一个功能从需求到上线，远比想象中复杂。它往往需要经过产品反馈或需求文档的撰写、前端UI设计、前后端开发、测试验收等多个环节，每个环节都有可能成为“堵点”。
我之前参与过一个大数据爬虫项目，要求较为复杂，如多级页面爬取、固定格式存储以及可视化展示等。实现预期功能后，我并没有进一步维护这个项目，也没有深入思考如何提升它的可扩展性。
借助这次软件工程课程，我希望能够系统地、全流程地参与一次完整的产品开发，从需求分析到最终上线，真正体会每一个环节的协作和重要性。
从9月2日开课至今，已三月有余。在这段时间里，我参与了从UI设计到需求分析再到产品开发的各个环节。通过流水线式的开发模式，深入体验了一个完整的软件开发生命周期。
在此过程中，体会颇丰，应用的技能包括但不限于技术开发文档的撰写、单元测试的实施、Burp+curl测试等。在更细节的层面，包括关注用户体验、进行权限划分、多个模块下的多表查询及安全开发等。至于实现的目标、存在的不足和由此产生的实践心得，我将穿插在接下来的叙述中。
初探
第一次作业的任务是搭建一个 Github 个人主页，并在页面中介绍自己的兴趣爱好、专业知识与能力，以及未来的发展设想。这次作业中，老师给我们提出了一个发人深省的问题：“本学期结束后，你希望累计的代码量是多少？” 对这个问题，我会在后文中作答。
受挫
第二次作业的目标是参考题目提供的代码，完成一个拟“羊了个羊”小游戏的实现。虽然代码功能基本跑通，但最后的结果却没有完全符合产品需求。我没有抓住“风格”这个关键词，这是我在软件开发中踩到的第一个“雷区”——产品定位，而这也促进了后面我对软件开发的思考。
磨合
第三次作业是一个团队任务，我和队友陈亮腾合作，共同完成了跨专业合作平台的用户痛点分析、功能点整理、原型设计及细节优化。
我的主要职责是开发项目大厅界面、标签详情界面、项目详情界面、发起招募界面、申请项目界面，以及个人中心界面。在完成这些任务的过程中，我逐步熟练了团队协作的流程，尤其深刻体会到尽早敲定最终方案的重要性。
为什么这样说？一个好的方案可以简化许多不必要的流程，当团队中的每个成员彻底了解自己的任务分工时，就能够避免许多重复劳动。
这个结论来源于我对结对合作和团队合作的对比。
落地
第四次作业是对第三次作业原型设计的实际开发实现。而这次，我踩到了第二个雷。是的，我发现虽然原型设计和文档写得很完整，但在开发落地时，成品的效果却不如预期，更何况我是从用户和开发人员两方面的视角出发的。
归结下来，问题在于：在开发过程中，我们往往会忘记自己的出发点。设计时的功能点并未充分考虑用户体验，结果在实际开发时需要频繁调整逻辑，而这些临时修改又受制于时间和技术水平的限制，导致最终的项目虽然完成了，但总觉得“差点什么”。
推倒
接着，就到了我们的团队开发环节。这次的任务是开发一个基于 LLM（大语言模型）接口的软件，为传统软件赋予全新的体验和功能。
这是我第一次参与十个人的大型项目开发。上一次类似的经历，是和五个朋友一起完成网安靶场的搭建。这次规模更大，任务复杂度也高得多。正因为如此，在后续的开发中，同样踩了雷。
如果你打开我们提交的这份作业，会发现一个明显的设计问题：我们的原型是小程序，但最终呈现的 UI 却是Web。尽管我们在后期重新设计了 Web UI 并按时完成任务，这仍然是一个值得反思的问题：在产品开发过程中，必须在最初就明确“自己要做什么”，否则推倒重来的时间成本会非常高。
定位
最近我学习了软件开发中的三种文件：BRD、MRD、PRD，并且稍作总结。如果感兴趣，可以点击查看或者自行搜索了解。
简单来说，BRD 文件中有一个核心概念：定位。在软件开发初期，明确产品的市场定位和核心功能是至关重要的。
我们的产品定位非常清晰：为用户提供海量历年考试资源，并构建一个氛围良好的交流互助平台。这正是当前大学生群体的一个痛点。
接下来的原型设计、概要设计和数据库设计等工作，为后期开发奠定了一定但不够完美的基础。
因为我在后面就踩了第三个雷，稍后会详细讲述。
轻账
11 月 2 日，我们进行了一次现场编程作业。任务是设计一款记账工具，我给它起了个名字——“轻账”。之所以叫这个名字，是因为它满足了个人记账的基本需求，同时功能简单、轻便易用。
我看过一篇文章，它深入分析了字节跳动的发展历程。今日头条的日活跃用户数超过1.2 亿人，不仅在于其强大的推荐算法，还在于“今日头条”这个四个字清晰且贴合用户需求的品牌定位。同样，对于“轻账”，我希望它的名字和功能也能给人一种直观的轻便感。
由于记账本的数据无需与服务器交互，这带来了新的挑战。通过调用 UNI 函数实现数据的本地存储，是我克服这一问题的收获。
Alpha
随后进入 Alpha 冲刺阶段，我们对项目的不足进行了分析，并进一步完善了项目逻辑。在当时，我写下了一段体会：
应用程序开发过程中，需要同时兼顾用户体验与产品需求，给方案一个沉淀时间。若没有，这种双重考量往往使得原有开发逻辑需要大幅调整。因此最终方案应该在前期调研时就敲定。
而这段话恰好就为我踩的第三个雷埋下了伏笔。
Beta
11 月 20 日：Beta 冲刺发布。
在团队项目《卷卷福》中，我主要负责前后端开发。前期的框架搭建由我完成，包括登录模块和资源中心页面的基础功能框架，这为后续开发提供了清晰的技术指引。团队成员根据这些框架，各自实现对应的功能模块。
在 11 月 15 日的团队会议中，我详细阐述了自己的技术方案，并展示了初步的框架设计。会议还重点讨论了预览功能的技术细节，并达成了一致意见。
在后续的两次冲刺过程中，我对前端界面和后端逻辑交互进行了多次重构，主要目的是优化用户体验，同时增强产品的视觉吸引力。
除了开发工作，我还担任了 AI 功能开发和社区功能的负责人。期间，我解决了队友在技术实现中的疑难问题，还对部分代码进行了修正和优化，确保功能的完整性。
在 Beta 阶段，我们进行了大量的优化和调整，其中很多都推翻了原有的前后端设计。前端部分的改进尤为显著，我们重新设计了 UI，突出了“化蝶”这一核心特色。同时添加了以下功能：
- 更具吸引力的产品 UI
- 动态粒子特效增强交互感
- 登录校验功能以提高安全性
接下来，我开始开发管理员审核模块，包括管理后台的开发及管理审核、福币发放等。
而随之出现的问题是：由于按界面功能分配人员进行开发，导致每个界面对应的后端 SQL 语句和变量很难保持一致，同时表的部分属性缺失。这也是我在团队协作记录中提到的一个关键问题：
我相信，在数据库设计不够严谨的情况下，这种问题在许多大型项目中都是常见的。
在经过调整和优化后，我们最终实现的功能如下：
审核通过后，系统会向对应用户账户发放福币：
对应的后端部分代码如下，我们使用了参数化 SQL 语句来进行数据库操作：
$updateCoins = "UPDATE users SET coins = coins + 100 WHERE student_id = ?";
if ($updateStmt = $conn->prepare($updateCoins)) {
$updateStmt->bind_param("s", $student_id);
if ($updateStmt->execute()) {
echo "<script>alert('用户福币更新成功');</script>";
} else {
echo "<script>alert('更新福币失败: " . $updateStmt->error . "');</script>";
}
}
回到文章开始提到的问题，“本学期这门课完成后，你希望达到的代码量是多少？”
关于这个问题，我估计可能有1w以上，其中也包括了那些最终被推翻的代码。而这个数量也超过了我写在第一次作业中的预期：
总结来看，各次作业分别花费的时间如下：
| 作业 | 花费时间 |
|---|---|
| 第一次个人作业 | 2h |
| 第二次个人作业 | 6h |
| 第一次结对作业 | 3.3h |
| 第二次结对作业 | 8.2h |
| 第一次团队作业 | 3.5h |
| 第二次团队作业 | 4h |
| 现场编程作业 | 4h |
| 团队作业beta冲刺 | 24h |
软件工程中，有个词叫“按时交付”，我在每个时间段都完成了特定的指标：
| 累计时间 | 实际周均时间（按九周算） | 预计周均时间 |
|---|---|---|
| 55h | 6h | 7.5h |
在这门课中，有些技术我早已熟悉，有些则是见过但没实际动手做过。以下是我在技术方面的收获：
- 使用PHP处理JSON数据。这是我不怎么熟悉的，因为之前在搭建靶场或者开发新项目时，通常直接通过 MySQL 交互，返回的是 HTML 格式的数据。
- 墨刀，Figma、Axure RP，这些原型设计工具为开发做了充分的铺垫，帮助我高效地进行界面设计和功能规划。
- Hbuilder，这款支持 HTML5 的 Web 开发 IDE 性能极佳，提升了我们的开发效率，尤其是在轻账上。
- 使用Python写“羊了个羊”。通常我使用 Python 写脚本（例如生成固定格式的数据等），通过这次实践，我拓宽了自己的技术视野。
- 使用语雀进行团队协作。这是一款团队协作工具，界面简洁且功能丰富，之前用它记录过笔记，现在发现它在团队项目中的协作功能很强大。
- Xshell、Xftp。这两个工具帮助我管理远程主机，使用它们将项目部署到 Web 服务器上。
- 单元测试与代码审计，我在开发过程中，也注重了代码的单元测试与审计，确保代码质量。
除了技术上的进步，整个项目过程中，我还提升了以下几个方面的能力：
- 在结对开发中，我队友的开发效率较高，这得益于我们事先敲定了技术细节，思路清晰明确，从而提高了我的团队协作能力。
- 在项目过程中，我学会了从更苛刻的角度出发，主动提问，分析项目的不足之处，以便及时改进。
印象深刻的事件之一是11月9日的答辩，那天是《卷卷福》第一次与大家见面。在答辩前，我提前理清了项目的业务逻辑，甚至从更高的标准来审视项目，因此答辩时并没有遇到太大的意外。
直到现在，项目仍然有一些不足，尤其是在用户活跃度方面的提升尚未完全实现。我认为，历年卷资源共享平台具有很高的实际价值，虽然它可能不适用于所有高校，但至少在本校有其存在的意义。
致谢
鼓掌难鸣，要感谢结对开发的同学陈亮腾以及团队中的其他成员，没有他们的参与，项目无法顺利完成。他们解决了许多项目中的问题，也给我带来了不少启发。
同时，我也要感谢吴越钟老师和张栋老师，为我们提供了完整的软件开发平台，促进了我在理论与实践结合方面的思考。
感想
今天，我重新审视了这三个月来的过程，也重新审视了一遍自己做过的所有项目。
回顾我的第一次前后端开发，时间是在 2023 年 4 月 9 日，当时用的技术栈也是 PHP，不过那时我入门不久，仅实现了一个简单的留言板功能，链接如下：PHP+MySQL留言板项目搭建教程及报错详析。
而此次本学期的项目均用PHP开发，算是对过往的一次回顾、对PHP的致敬。
接下来，是我关于代码冗余的一些思考。
冗余
在团队项目源代码中，我单独拿出一个脚本文件，就发现它已经超过了1500行，而这并不是因为它功能复杂。一个文件尚且如此，如果有多个文件，这对于后期的重构工作来说是非常不易的。
在后期如果希望修改程序的设计模式和架构使其合理，却往往无从下手。
我想这也是许多开发人员所遇到的问题，甚至有些项目的代码量已经达到了几万行。
很多时候，不合理的耦合是问题的根源。但耦合又是不可避免的，随着项目的发展，最初的架构可能会逐渐失效。之后，任何在这种失效架构上进行的修补，都会进一步加剧其腐化，导致代码变得更加难以理解。
举个例子，一个产品经理提出了一个需求，要做一个活动系统，用于发放优惠券、打折促销、积分奖励等活动形式，让用户在不同的功能场景中都能参与并获得奖励。乍一看，这个需求很正常，基本的逻辑也很简单，但深入分析之后，我们发现问题并不小。
1、优惠券系统需要支持各种自定义活动逻辑（例如满减、打折等）。
2、积分系统需要增加接口来支持活动期间的特殊加成或奖励逻辑。
3、价格计算模块需要引入额外的折扣规则解析逻辑。
于是，原本独立的业务模块因为活动系统的引入，产生了隐形的耦合关系。
同时，活动入口需要出现在首页、商品详情页、搜索结果页、订单结算页等多个地方。搜索结果页需要在每个商品上展示活动标识，提示用户参与优惠。商品详情页需要展示活动规则、优惠金额等信息。订单结算页需要实时计算用户参与活动后的优惠金额。
每个页面对活动的展示需求和逻辑不同。如果要做到统一，活动系统就必须为不同的展示场景适配不同的规则逻辑，最终导致一个系统承担了过多的职责，复杂度剧增。
由于我们的《卷卷福》项目并未意识到重构时需要关注低耦合性，导致某些功能的流程难以辨认，很难知道从哪里入手。而且，在新增功能点时，由于需要与多个界面交互来实现有意义的功能，这就使得开发过程变得像是抽丝剥茧般困难，极大地增加了我的认知负担，至少在我实现管理员审核模块的前后端开发时是这样。
文章开头提到，软件工程是指导软件开发的方法论。我之所以选择《以用户的视角看体验，以开发的视角看软件》这个标题，是因为我深刻感受到，软件工程确实为我们提供了如何“以用户的视角看需求，以产品的视角看细节”的思维方式。
在这三个月的过程中，我接触了很多软件开发的流程和方法，学会了站在用户的视角上看需求，也学会了如何提高软件开发的流程效率，同时在学习中扩展了自己的知识面。我看到了许多技术的产生历程，例如 Redis 分布式锁，它们的精妙之处让我感叹不已，而这些细节对于用户来说是完全透明的。这些经历无形中提高了我思考的深度。
有需求，就有开发，就有软件工程。如何解决难题、提高开发效率？如何直击用户痛点、实现低耦合并扩展功能？到底怎样才能把软件做得更好？
这些问题值得屏幕前的你思考。
