[T.13] 团队项目：Alpha 阶段项目总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.13] 团队项目：Alpha 阶段项目总结
我在这个课程的目标是	掌握软件工程的基本概念和方法，提高团队合作能力，增强问题解决能力，熟悉现代软件开发工具和技术，提升编程技能
这个作业在哪个具体方面帮助我实现目标	进行alpha阶段的总结，更好地开启Beta阶段

Part 1 设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

主要解决的问题是满足用户的高质量内容推送和低压力创作社交要求，为用户提供一款沉浸式的内容聚合与记录APP。我们对用户的需求定义得十分清楚。我们在T5博客中对于典型用户和典型场景有清晰的描述，主要的用户是针对学生，职场新人和文艺创作者。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

我们的目标基本达到。在规格功能说明书中提出的主要功能都已在alpha阶段实现。主页的3D化虽然已经实现，但是考虑到美观性以及整体UI的适配性，将其转化为更符合整体风格的2D精美主页。并且我的星球部分的完成程度超过预期，几乎将这个模块做成了一个完整强大的笔记软件，感谢两位成员的付出@王怀阳 @曹玮琳 。

基本按照原计划交付时间交付了，部分功能因为体量庞大在交付时间可能有一两个功能不完整没有同步上线，但是在交付后一两天内均完善并交付。

用户数量达到了预期，因为alpha阶段我们是内测版本，不仅在我们邀请的用户中很多用户很活跃，在我们发布内侧到小红书平台后，收获了很多意料之外的用户。

3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么？

我们的用户日活量达到了20多人，并没有达到我们最初预想的上百人，原因是因为处于软件宣传发布的初期，主要的用户校内成员，我们还需要持续的在小红书和知乎上进行产品宣传。

用户对重要功能的接受程度和我们预估的一致，用户非常认可我们的音乐，短句和美文推送以及自己进行碎片创作的功能，这是碎星集作为一个文艺性app的亮眼点。用户也给我们反馈过我们配置的ai辅助创作非常好用，有的时候创作突然卡壳的话可以让ai补全提供灵感。

4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

@孟烜宇 经验教训就是调研一定要做好，要尽可能的在设计阶段把东西弄明白，可以省去很多荣誉工作。改进就是会把ui设计的更加完整，防止打回。

@周佳琪 在一开始确定产品设计的时候需要确定尽可能多的功能和设计，一开始就让大家对于这个产品有比较清晰的认识。

@尹祺霖 或许在讨论产品设计的时候可以更具体的定下功能让接口可以确定下来

@曹玮琳 在代码合并时应该仔细核对，以免在合并时出现新的bug

@王怀阳 在ui设计阶段尽量设计清楚，让前端的推进更加顺利

@卢裕轩 UI设计时要考虑前端实现，部分设计细节可以以具体实现为准

@王寅 app的设计不够详细，应该把ui设计得更好一点，而不是只是大致地描述，导致后面其那段开发时还要考虑具体的实现。

Part 2 计划

1. 是否有充足的时间来做计划?

是的，我们有充足时间来做计划。磨刀不误砍柴工的道理，在Alpha开始之前预留了足够的时间进行调研、讨论和计划，前后召开了三次会议认真的对待这件事情，从ui设计到功能设计，做了完整的计划。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

团队通过会上集体讨论，并采取少数服从多数的原则来统一意见

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

@孟烜宇 全部做完

@周佳琪 全部做完

@尹祺霖 全部做完

@曹玮琳 全部做完

@王怀阳 放弃了文件管理和用户发布数据的实现，否则来不及在alpha阶段结束前完成自己的part推出mvp

@卢裕轩 全部做完

@王寅 全部做完

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

这样的事情比较少，因为我们的计划做的很完善。但是有一件这样的事情出现。比如@王寅 在刚开始的时候花了很大的力气突破了主页的3d化实现以及动画，但是由于风格不符合，所以最后舍弃了。

5. 是否每一项任务都有清楚定义和衡量的交付件?

有 ，详情请见：[T.6] 团队项目：技术规格说明书

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

开发过程中主要出现了任务量估计出现偏差，主要出现在我的星球页面和主页。

我的星球是没有估计到，因为@王怀阳 的实现的部分功能超出要求。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

我们为每个小阶段（UI设计阶段、后端开发阶段、前端开发阶段）都设了一定的缓冲区。缓冲区的作用十分关键：一方面，它能有效应对开发过程中难以预料的风险，像突然出现的技术难题、开发工具故障等情况，有了缓冲区就能争取时间去解决，不至于打乱整个项目节奏。另一方面，当需求发生变更时，缓冲区可用于灵活调整任务安排和资源分配，确保项目依然能够稳步推进，按时交付。

8. 将来的计划会做什么修改？

随着开发过程的推进，难免发现计划不完善的情况，这是很合理的。重要的是能随着开发过程发现计划的问题而修改完善，这样才能保障计划的前瞻性和有效性。比如，开发创作页的过程中，一开始计划中没有关于呼出输入法后自动调整文字高度，以保证当前被用户编辑的行保持在可见范围内，以及自定义背景，切换背景等功能相关的计划，但是随着开发的推进，发现这些功能很有必要，因此加入了计划。

9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

@孟烜宇 学会了合理的计划和准时的完成是十分重要的。改进是会把计划的ddl强化。

@周佳琪 学会了团队合作和与队友的及时沟通，改进还需要及时关注文档

@尹祺霖 及时和队友沟通，合理改进计划

@曹玮琳 应当及时关注任务文档，学会使用飞书强大的功能来创建、查看任务

@王怀阳 在任务分配阶段时需要做好沟通，避免工作量的分配不均

@卢裕轩 任务难度不同，分配时可能出现不平均，如“我的星球”页面难度过高，应该详细拆分任务

@王寅 要将任务细化，估算好各任务的工作量。

Part 3 资源

1. 我们有足够的资源来完成各项任务么?

有。团队在开发工具（如Flutter、Django）、服务器资源（腾讯云CVM服务器部署后端）、冷启动内容（音乐/短句/文章库）、发布场景（小红书、github、网页）等方面准备充分。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

由于我们的团队成员具备安卓开发经验，在估计任务所需时间时，参考了过往类似的 UI 设计及前端开发任务耗时。以先前任务用时为基础，结合本次任务的复杂程度进行相应调整。同时，我们对任务进行了精细拆解，按页面划分任务单元，实现了更为细粒度的时间估算。

在精度把控上，大部分任务的实际完成时间与计划时间较为契合。然而，由于一些时间冲突和部分页面功能的复杂程度超出预期，对实际进度造成了一定影响。未来，我们将通过及时沟通调整任务分配、预留缓冲区等举措，进一步确保任务按时完成。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

我们分前后端进行了充分的功能测试和压力测试，我们是完全按照alpha阶段的安排在五一周进行了测试，测试的时间和人力以及软硬件资源都是足够的。

我们项目中不需要编程的资源分为美工设计和冷启动文案、音乐、短句收集两个部分。我们充分重视美工设计在alpha阶段开始前就预先分配了一位同学进行UI设计并由成员讨论确定了我们的UI设计，因为对于文艺性app来说美工设计是关键。对于冷启动资源收集，我们最开始考虑了音乐的版权问题导致了我们的冷启动资源显得有些冷门和无聊，之后在这部分进行了革新。

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

有。主要体现在代码架构方面。在我进行我的星球页面开发时，为追求快速完成任务，将页面所有代码一股脑地写进了一个 dart 文件中，而未对 utils 等常用功能进行子组件提取。随着开发推进，代码逐渐变得冗长杂乱，耦合度极高。

经过反思后，我认为如果有在代码架构设计上经验更为丰富的人员介入，能更好地进行代码拆分与组件化设计，不仅可提升代码的可读性与可维护性，还能提高开发效率，避免后续因代码混乱带来的修改与 debug 上的问题。

5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

@孟烜宇 这一方面更多的是体会，我们做到的好的工具和资源及时共享，大大地提高了团队的效率。

@周佳琪 在讨论的时候需要更多和队友交流，和大家一起沟通想法。

@尹祺霖 更加重视冷启动资源的质量，和收集资源的队友及时沟通。

@曹玮琳 会把服务器的带宽增大一些，提升用户上传下载体验

@王怀阳 达者为先，多多请教同学。

@卢裕轩 在代码实现方面，公共的功能组件应该提取出来，以避免重复开发

@王寅 要保证服务器资源的充足，尤其是带宽。

Part 4 变更管理

1. 每个相关的员工都及时知道了变更的消息?

我们使用飞书进行沟通和任务管理，基本大家都能清楚自己的职责和任务。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们项目设计了几个基础页面，包括主页、观察室、收集室、发布页、我的星球、星环，这些基础页面涉及到的基本功能，如我的星球页面的富文本编辑、观察室/收集室页面的阅读、星环页面的收藏等，为“必须实现”的功能；其他功能，如动态效果、筛选功能、分享功能等，为可以“推迟”的功能。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

我们对项目出口条件进行了较为全面清晰的定义，主要涵盖功能实现与测试验证两大维度：

功能条件

功能名称	出口条件
注册	支持用户输入邮箱和密码，发送验证码到邮箱并验证，验证通过后新建账户
登录	支持用户输入邮箱和密码登录
星环	支持展示收藏碎片的封面，点击后可查看完整碎片
观察室	支持文章，音乐，短句三种形式的推送，每一种推送都支持收藏和分享
火箭	支持用户查看所有自己已经创作的内容，并且选择发布
收藏室	支持接收并显示碎片，点击后可以进行收藏
我的星球	支持更改查看的视图，支持，支持进入创作页面和设置页面，通过日历直观显示每日创作，支持数据统计和模板功能
创作	支持用户编辑标题和内容，支持用户上传图片和音乐，支持AI创作
主页	支持跳转到星环，我的星球，火箭，收藏室页面
设置	支持修改密码，头像，用户名，支持修改推送设置

测试条件

编写并通过全部功能测试，单元测试和压力测试，尽量做到更高的覆盖率。保护用户的信息安全，能够应对高并发场景。

4. 对于可能的变更是否能制定应急计划?

可以，比如在开发我的星球页面时，任务量相当大，因此不得不制定应急计划对任务量在一定程度上重新进行分配。同时，在开发这个页面时，因为粗糙的合并出现了大量bug导致app无法使用，因此制定了应急计划来将严重bug紧急修复。

5. 员工是否能够有效地处理意料之外的工作请求？

可以，有的时候后端没法连接上服务器的时候需要负责部署的同学及时排查故障并反馈，并且后端和前端在被指出明文传输的问题以及网站安全的问题后及时处理了加密传输和网站证书的问题。

6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

@孟烜宇 这一方面我们做的很不错，大家的交流非常的频繁，颗粒度对的很齐。

@周佳琪 有问题及时在群里交流。

@尹祺霖 及时看飞书。

@曹玮琳 及时关注新任务。

@王怀阳 及时关注群消息。

@卢裕轩 及时反馈实现情况，及时沟通

@王寅 及时和队友交流。

Part 5 设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在Alpha启动之前由@周佳琪 完成，在团队会议中由@卢裕轩 进行了细化，团队中其他成员也提出了相关的意见。负责设计工作的主要二人都是一开始就志愿选择前端工作的人员，属于合适的人。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有。我们一开始对于宇宙主题的设计就出现了模棱两可的情况。一开始我们想做一个文艺APP，为了做出一个与众不同和个性的APP，我们提出了宇宙主题，但是我们在如何平衡宇宙主题和内容方面产生了分歧，比如哪部分选择宇宙的主题，哪部分是正常的内容主题。还有就是具体的设计问题，比如在创作笔记的时候是否需要加一个发布按钮，还是只在发布页面处理所有待发布的内容。而且在实现的时候，考虑到开发难度，我们也做了取舍，最后实现宇宙主题的时候比较克制。最后是在激烈的讨论过后，少数服从多数解决的。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

团队主要采取单元测试的方式来帮助设计和实现。我们将任务拆分后下发给具体负责的成员，该成员在开发过程中需要使用单元测试来保证所开发的模块是符合要求的。此外，在提出pr前，成员需要保证新增功能不影响已实现功能，为此需要进行详细测试。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

“我的星球” 页面是本次开发过程中产生 Bug 数量最多的功能模块。该页面由于涉及笔记管理、编辑器实现等多项核心功能，其业务逻辑本身就较为复杂。加之开发过程中需要多个团队成员协同合作，在接口对接、功能整合等环节，不同开发人员的代码风格、设计思路存在差异。

值得庆幸的是，在产品发布后，尚未发现严重影响用户体验或系统运行的重要 Bug。目前发现的问题主要集中在页面样式设计方面，如部分元素在不同设备屏幕上的显示错位、颜色搭配不协调等，并未干扰功能的正常使用。在设计和开发阶段，我们将主要精力集中于功能实现与逻辑校验，对样式在多平台下的适配性考虑不足，同时缺乏对细节的全面审查，这才导致部分样式问题未能在前期及时发现和修正 。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

主要利用GitHub的pull request对代码复审进行人员指派，并且严格执行了我们自己定义的代码规范以及分支命名规范。

6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

@孟烜宇 熟悉了flutter框架下的前端开发。如果重来，会更关注一些复杂逻辑的实现，同时更注重代码的工程化和鲁棒性，更多考虑响应式布局和安全问题。

@周佳琪 学到了设计和UI方面的基础知识和Figma的使用。如果重来，需要在UI设计方面更加下功夫。

@尹祺霖 熟悉了使用Django进行后端开发以及熟悉数据库管理等。

@曹玮琳 学会了Django后端开发，数据库管理，flutter进行安卓开发，以及GitHub代码管理相关的一些知识。

@王怀阳 学会使用 flutter 进行安卓开发，拓宽了技术栈。可以在代码架构的设计方面进行改进，更好地提升代码的可维护性与复用性

@卢裕轩 了解了UI设计方面的基础知识；了解了Flutter框架的特性，学会了使用Flutter框架进行开发；学会了如何使用Git进行团队协作。可以在开发前组织团队统一学习Flutter。

@王寅 学会了flutter的多平台开发。可以在代码开发时注意代码结构的规范化。

Part 6 测试/发布

1. 团队是否有一个测试计划？为什么没有？

团队有测试计划并在五一周实施了，首先是我们全员对我们的每个板块进行了测试，我们将发现的bug及时反馈到了T10博客的前后端bug收集的表格中并@相应负责人进行提醒及时修复。

其次是前后端的功能测试以及压力测试，前端围绕CPU、网络和内存进行了压力测试，后端进行了单元测试和api接口的压力测试。

2. 是否进行了正式的验收测试？

是。在顺利完成 alpha 版本的开发工作后，由@王寅 @孟烜宇 进行了统一的验收测试。在验收过程中，我们针对 APP 的核心功能模块、界面交互以及性能表现，分别在 iOS 端和安卓端上进行了全面测试，确保了 APP 在不同系统环境下都能保持较为良好的运行状态。

3. 团队是否有测试工具来帮助测试？

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

对于前端后端的功能测试和压力测试我们使用了测试工具。

前端压力测试使用了Android Studio 中的 Android Profiler 工具，它能够便捷地对运行中的 Flutter 项目进行性能监控、实时收集并展示应用在运行过程中的各项性能指标数据，为压力测试提供全面且准确的分析依据。

后端的api压力测试使用了Locust，与传统的性能测试工具（如 JMeter）相比，Locust 更轻量、可扩展。主要是对用户登录注册，接受验证码，创作发布碎片，收藏碎片以及修改个人信息部分进行了压力测试

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们使用工具对核心API 接口进行基准测试，评估吞吐量、延迟和并发处理能力以及模拟极端并发和负载，观察系统在瓶颈点的表现及容错能力来测量并跟踪软件的效能。我们使用Locust模拟了100个用户同时登录以及用这个api接口的情况。

从软件的实际运行结果来看这些测试工作是有一定作用的，之后可以将压力测试加入CI/CD定期回归执行。

5. 在发布的过程中发现了哪些意外问题？

因前期对安卓端应用发布流程了解不足，未提前筹备软件著作权申请事宜。而该申请流程耗时漫长，至少需要一个月时间，这一疏忽导致安卓端应用无法按计划上线，打乱了整体发布节奏。同时，iOS 端发布所需的开发者账号注册费用及相关资金投入也超出了预期规划，所幸我们通过及时与助教沟通协调，顺利解决。

6. 我们学到了什么? 如果重来一遍, 我们会做什么改进?

@孟烜宇 我们初期着重于进行开发这件事情上了，没有太注意到测试流程和框架，主要依赖于开发者自己的测试经验和能力。如果可以重来的话，我们会在初期同样调研测试的相关内容，形成完善的测试工作流，提升项目的质量，也能减少我们后期debug的痛苦，特别是我的星球。

@周佳琪 应该更多试着把精力放在测试方面，在代码提交之前在本地做好充分的测试。

@尹祺霖 熟悉了更多的后端测试工具，测试和开发同样重要，充分进行压力测试和功能测试能保障用户更加流畅更加完整的体验。

@曹玮琳 应当在合并前测试检查bug在哪里，合并过程要仔细一点，合并后再测试是否出现了新的bug。先做好每个模块，然后仔细合并，以免出现大量bug且难以定位。

@王怀阳 写了很多行代码，踩了很多坑，收获了很多经验。改进还是主要在代码架构方面做好设计与规划。

@卢裕轩 了解了不同平台对相同代码具有不同的处理方式。在开发时就要充分考虑不同平台的适配性。

@王寅 学会了测试的方法。在开发的过程中，要及时进行测试，不要等到最后一起测试。

Part 7 团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

团队创建之初，我们按照大家的能力和兴趣初步进行了分工的划分：杰杰Bond团队成员介绍

在项目进行的过程中，我们也根据实际情况进行了一定的调整和进一步的细化。

框架比较新，但是所有队员都齐心协力，付出了很多，并且都在自己擅长的领域发光发热，做到了人尽其才。

2. 团队成员之间有互相帮助么？

是的，我们的团队成员互帮互助，做得相当好。

尽管平时课业繁忙，我们仍能做到4h内一定回复和解决问题，遇到需要联动讨论的内容时，我们通过伟大的阵地456寝室，高效集中互帮互助解决。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

如果出现项目管理合作方面的问题我们会在每次ScrumMeeting时进行集中沟通，按照团队管理方案进行及时的解决和任务分配，发挥每位同学的长处。如果遇到非常棘手的问题，我们会进行线下集中讨论与敏捷开发。此外我们还开发了感谢信机制，对自己有帮助的同学发放感谢信，优化团队合作氛围，我们认为这是一个非常好的机制。

Part 8 总结:

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

基于我们团队对项目过程的系统性度量和数据分析实践，例如对关键质量指标和过程性能数据的跟踪与利用，并设定和管理定量的过程目标，我们认为团队目前的状态已经具备了 CMM/CMMI 定量管理级（Level 4）的主要特征，即能够利用量化数据来理解、控制和预测我们的软件开发过程表现。

2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

规范阶段。我们的协作逐渐顺畅，有明确流程和规则 ，形成初步默契，开始遵循共同规范，互相信任 。

3. 你觉得目前最需要改进的一个方面是什么?

目前项目最需要改进的是代码质量管控环节。由于任务量繁重，且采用敏捷开发模式快速迭代，团队在开发过程中更注重功能的快速实现，而对代码规范和质量把控有所松懈。不同成员在代码编写时缺乏统一风格指引，导致大量冗余代码产生，不仅增加了代码维护成本，也降低了代码的可读性与可复用性。未来需要建立更严格的代码审查机制，制定统一的编码规范，通过定期的代码评审和重构，消除冗余代码，优化代码架构，从根本上提升代码质量与开发效率。

4. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

原则1： 在整个项目过程中，业务人员与开发者必须每天都一起工作。

具体事例1：在开发过程中，团队会经常交流并反思某些功能的设计，比如用户笔记的保存和同步问题，我们综合考虑服务器带宽、软件特性等因素给出了一个折中可行的方案，最终成功开发。

原则2：面对面交流是最有效的沟通方式。

具体事例2：在冲刺阶段，团队开发人员每天都花费至少5个小时线下集体开发，保证了可以时刻进行面对面交流。

5. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

规范开发流程。我们将统一代码风格，推行代码评审机制，确保每一行代码都经过审核，从而提升整体代码质量和可维护性。同时，明确版本控制策略，避免多人协作中出现代码冲突和版本混乱。

完善需求与文档流程。通过建立需求评审机制，确保在开发前明确目标和边界。

构建自动化测试体系，并配合持续集成和持续部署（CI/CD）工具，提升产品稳定性和发布效率。

优化团队协作机制。促进知识共享，提升团队整体工程素养。

6. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

提高代码管理质量需建立标准化流程：采用Git分支策略与自动化CI/CD工具确保版本可控；通过合理的分支、PR命名来标注要实现的或修改的功能，强制规范执行。代码复审应实行多人交叉评审机制，重点审查逻辑漏洞与架构合理性，通过PR模板规范评审流程。代码规范需根据确定规则（比如django的flake8），在提交前使用IDE中集成的代码风格规范工具，确保代码风格一致，没有问题。

7. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

在架构层面，采用模块化设计，确保各部分职责单一、低耦合。通过分层架构（如MVC/MVT），明确表示层、业务逻辑层和数据访问层的职责分工，使系统结构更加清晰。进一步地，引入接口和抽象层来实现模块间的解耦，并在架构中考虑可扩展性（如插件机制）与性能优化（如缓存、异步、限流等）。

在代码层面，通过持续的重构提升代码质量。例如，删除重复代码、简化复杂函数、优化命名与注释、提升代码可读性。将业务逻辑封装进独立类或服务中，分离关注点。避免过长的函数和类，拆分出单一职责的模块，提升代码可测试性和可维护性。

为了衡量质量提升效果，我们将采用静态分析工具（如检测代码复杂度、重复率、Lint 报错数）和动态运行指标（如测试覆盖率、缺陷率、系统响应时间）进行评估。质量提升不仅体现在指标上，更体现在开发效率和系统稳定性上的实际改善。

8. 其它软件工具的应用，应该如何提高？

提高软件工具应用主要靠两点：

• 多实践：在项目中主动尝试用新工具解决问题，通过实际操作熟悉功能，比如学 Git 时，就多在项目里练习分支管理、合并代码，练多了自然就会了。

• 多交流：与团队中的同学多多交流，每个人把自己用工具的技巧和踩过的坑讲出来，大家互相学习。

9. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

计划将用户的每日发碎片平均值以及发碎片的中位数还有发布碎片的质量提取成表格来改善推送方式。

我们可以在user中记录了最后一次登陆的时间以及可以在数据库中查看每天的用户碎片发布的数量和收藏情况，借此我们可以了解每日/周活跃用户情况。

10. 项目文档的质量如何提高？

项目文档的质量一方面取决于我们的工作成果，另一方面取决于文档记录人员的工作。在记录之前，需要明确这个文档面向的对象以及要传达的信息，而且需要将项目文档的规范完全确定。在记录的时候，为了更加准确地记录，需要和所有相关的开发人员进行对接，确保将所有功能和特性理解正确，记录完全，必要的时候加一些图表使我们的说明更加清楚。如果是由开发人员记录自己负责的工作，就负责文档的人员需要在最后合并的时候进行修改。在最后文档成型的时候，由团队成员一起审核，最终进行发布。

11. 对于人的领导和管理， 有什么具体可以改进的地方？

团队在沟通效率与透明度方面有改进空间。优化信息的传达方式，确保项目目标、个人任务和任何变更都能清晰及时地传达给每位成员，同时鼓励大家进行开放和诚实的交流。

应进一步明确并细化团队成员的角色与职责。确保每个人都清晰地知道自己的定位、具体负责的任务范围以及期望达到的成果，以减少模糊和潜在的冲突。

促进团队内部的协作与知识共享也非常关键。可以建立一些机制来鼓励成员之间的互助、经验交流和技术分享，以此增强团队的整体能力和凝聚力。

改进反馈与激励机制是提升管理水平的重要一环。提供更及时、具体且具有建设性的绩效反馈，并对团队成员的贡献给予适当的认可和激励，能够有效激发工作积极性。

最后，pm@孟烜宇 觉得增强团队成员的参与感和责任感不容忽视。鼓励大家展现主动性，并在团队的决策和流程改进中给予他们更多参与和表达意见的机会，从而提升大家对团队的归属感。

12. 对于软件工程的理论，规律有什么心得体会或不同意见？

@孟烜宇 软件工程的理论和规律为我们指明了方向，但真正的挑战和乐趣在于如何结合团队的实际情况，创造性地应用这些原则，并通过持续的沟通、协作和反思，共同提升开发效率和软件质量。这次经历让我更加相信，一个高效协同的团队，是任何软件工程理论成功实践的最重要基石。

@周佳琪 软件工程是一门理论和实际相结合的课，我们在实践的过程中需要以理论作为指导。在实际进行项目开发的时候，会遇到各种各样的问题，软件工程理论不可能直接解决，而我们解决问题的时候需要用到的是背后的思想。

@尹祺霖 软件工程理论给我带来了多方面的提升，我觉得良好的团队氛围是最重要的，大家都对我们的项目保有热情也都及时沟通前后端对接问题，推进我们的项目，使得开发的过程非常愉快。

@曹玮琳 软件工程理论为开发提供了系统框架，但实践需灵活适配。团队曾忽视模块化与规范，导致后期出现大量bug，这体现出架构设计的重要性。团队的高效协同比流程更关键，通过敏捷迭代与持续沟通平衡效率与质量。理论是基石，而人的协作、创造性与务实调整才是真正推动项目落地的核心动力。

@王怀阳 以前总觉得软件工程的理论都是 “纸上谈兵”，但实际做项目才发现，这些理论真的很有用。比如代码规范和模块化设计，之前为了赶工没在意，结果后期代码越来越乱，找一个小问题都要翻半天，这才明白提前做好架构设计、把功能拆成小模块有多重要。

@卢裕轩 系统学习软件工程前，在之前的开发经历中，我总是不能很好地进行团队协作，有种"1+1<2"的感觉。学习后，在实践过程中，发现软件工程的理论对于团队开发很有指导意义，团队真正实现了高效协作。比如敏捷开发部分的理论，可以大大提高团队的协作效率、开发效率。

@王寅 软件工程的理论为开发提供了规范和指导，但实践中需要灵活应用。流程和文档固然重要，但不能拘泥于形式，需结合项目实际调整。人的因素常被低估，良好的沟通与协作往往比流程更关键。敏捷等理念更贴近现代开发。

13. 对比敏捷的原则，你觉得你们小组做得最好的是什么？

我们小组在交流方面做得最为突出。在开发时，团队成员一直保持饱满热情，积极友好地交流；对于加减分问题，团队成员欣然接受。

14. 什么是在下个阶段要改进的地方？越具体越好。

我们按照优先级排序，明确了下阶段目标：

1. 功能性 bug修复：优先解决影响使用的功能性问题，比如 “我的星球” 背景保存的问题。我们会和内测用户多聊天、多沟通，仔细收集他们遇到的问题和反馈并进行修复与测试，确保功能稳定好用。

2. 样式调整：集中处理之前遗留的样式问题并完善在手机、电脑等不同平台的适配，让页面在各个设备上都能整齐、美观地呈现 。

3. 性能优化：着手实现音乐和笔记的缓存功能，提前把用户常用的音乐、常看的笔记缓存，减少卡顿，提升用户体验。

大家都很开心的样子