软件工程实践总结——迈出的一小步

[102300309陈禹帆]

这个作业属于哪个课程	202501福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	通过课程回顾与项目实践总结，提升对软件工程全过程的理解；反思个人成长与技术能力；培养规范的文档表达与技术写作能力；思考软件开发模式与职业未来。
其他参考文献	《构建之法》

目录

• 1 第一部分：课程回顾与总结
• 1.1 深入思考的问题
• 1.1.1 问题1：在项目工作中哪些文书工作是必要的，哪些可以省略呢？
• 1.1.2 问题2：在AI发展日益迅速的今天，软件工程师是否马上会消失呢，学习这行还有意义吗？
• 1.2 项目各阶段收获最大的知识或能力
• 1.3 结合项目经历的理解与心得
• 1.4 对七大课程目标的掌握程度自我评分
• 2 第二部分：个人技术总结
• 3 第三部分：软件开发模式
• 3.1 项目开发过程
• 3.2 软件开发模式的思考

1 第一部分：课程回顾与总结

1.1 深入思考的问题

1.1.1 问题1：在项目工作中哪些文书工作是必要的，哪些可以省略呢？

最初进入“代码编程错题帮”项目时，我对繁多的文档工作抱有疑问：需求文档、接口文档、原型图、测试报告……这些真的都需要吗？直接编码不就更快？尤其在小团队、时间紧迫的情况下，我觉得很多文书只是“形式主义”，可以大幅省略。

通过本次课程和项目实践，我逐步改变了看法。需求文档和接口文档是团队协作的“契约”，它将模糊的口头讨论转化为明确、可追溯的规范。在项目初期，我们因为接口定义不够清晰，导致前后端多次返工，浪费了大量时间。后来补充详细的接口文档（包括请求参数、返回格式、错误码）后，开发效率明显提升，沟通成本大幅降低。原型图（使用Axure绘制）也帮助非技术成员快速理解产品逻辑，避免了后期“大改”。

现在我理解：必要的文书包括需求规格说明书、接口文档、关键架构设计文档和测试报告，这些直接影响质量和协作；可以适当精简的是过于细碎的会议纪要或重复性日志，但不能完全省略。省略文书的代价往往是后期更高的返工成本。一句话总结：文书不是目的，而是保障可维护性和团队同步的手段。通过与同学反复对齐需求、多次迭代文档，我一步步认识到“写清楚”比“快上手”更重要。

目前这个问题已经基本厘清，但仍有一个小困惑：如何在敏捷项目中平衡文档的“刚好够用”与“不过度”，避免文档成为负担？这可能需要更多项目经验来把握。

1.1.2 问题2：在AI发展日益迅速的今天，软件工程师是否马上会消失呢，学习这行还有意义吗？

AI工具如Copilot、Claude、Grok等代码生成能力飞速提升，我一度担心：简单CRUD很快会被AI取代，软件工程师会不会很快失业？学习软件工程还有意义吗？

通过课程讨论和项目实践，我获得了一些新理解。首先，AI目前擅长生成局部代码，但难以独立完成复杂系统的需求分析、架构设计、跨团队协调和质量保障。在我们的项目中，AI可以帮我快速生成前端组件模板或文档草稿，但需求对齐、接口设计、部署管道配置等核心决策仍需要人类判断。其次，软件工程本质上是“用工程方法解决复杂问题”，而AI只是工具，就像当年编译器没有让程序员消失，反而提升了生产力。

我通过阅读《Clean Code》、课程讲义，以及与同学讨论AI在DevOps中的应用，逐步厘清：软件工程师不会消失，而是角色会演变——更注重系统思维、产品价值和人与人的协作。学习软件工程的意义更大，因为它培养了结构化思维和工程素养，这些是AI短期无法取代的。

不过，这也产生了一个新问题：未来软件工程师的核心竞争力会转向哪里？是更深的领域知识（如教育、医疗），还是更好的提示工程与AI协作能力？

1.2 项目各阶段收获最大的知识或能力

• 需求阶段：学会使用用户故事（User Story）和原型工具（Axure）来捕捉与验证需求。最大的收获是“需求不是开发者想当然，而是通过反复对齐得到的共识”，这避免了后期大规模返工。
• 设计阶段：理解接口文档作为前后端“契约”的重要性。收获最大的是学会用清晰的表格和流程图表达API设计，让非技术成员也能理解技术逻辑。
• 实现阶段：虽然我主要辅助前端，但通过观察和参与，收获最大的是代码规范与工具链的重要性（如ESLint、Prettier统一风格），以及Git在版本管理中的协作价值。
• 测试阶段：认识到测试不止是开发者的责任，文档中清晰的测试用例能帮助团队更快发现问题。收获是学会编写可执行的测试报告，让问题追溯更高效。
• 发布阶段：体验了华为云DevCloud Pipeline的自动化部署流程。最大的收获是“持续交付”理念：发布不是终点，而是快速迭代的开始，文档和脚本的完备直接决定了发布的平稳性。

1.3 结合项目经历的理解与心得

在“代码编程错题帮”项目中，我主要负责项目文档撰写、介绍PPT制作，并辅助前端工作。通过这次实践，我深刻体会到清晰表达与有效沟通在团队协作中的重要性。

项目初期，我们以“帮助编程初学者高效复盘错题”为目标，明确了产品核心功能。在整理需求文档和撰写说明材料的过程中，我不断与开发、设计同学对齐理解，确保文字准确传达技术逻辑与产品价值。同时，在制作汇报PPT时，我注重逻辑结构与视觉呈现，力求用简洁直观的方式讲好我们的项目故事。

过程中也遇到挑战，例如如何将技术细节转化为非技术成员也能理解的语言，以及如何在有限时间内高效迭代文案。通过频繁沟通和多次修改，我提升了信息提炼与跨角色协作的能力。

这次经历不仅锻炼了我的文书与表达能力，也让我更理解了产品从构想到落地的全过程。未来，我希望能在技术与传播之间搭建更有效的桥梁，为团队创造更大价值。

1.4 对七大课程目标的掌握程度自我评分

课程目标	自评分	依据
目标1 职业道德规范与社会影响	85	通过项目实践认识到软件产品对教育初学者的帮助价值，理解了隐私保护和可访问性的社会责任。但对更广泛的国情社情影响思考还不够深入。
目标2 需求分析全过程	90	在项目中深度参与需求文档撰写和原型验证，熟练使用用户故事和Axure表达需求，能较好辨别和规范客户表述。但在处理模糊需求时的经验仍需积累。
目标3 软件开发全过程、体系结构设计与设计原则	75	参与了从需求到发布的完整流程，但主要在文档和辅助层面，对核心架构设计和构件级模型的实践较少，理解偏理论。
目标4 技术评测与方案优选	70	在PPT和文档中尝试创新表达方式（如可视化架构图），但对设计方案的正式评测和优选经验不足，创新意识有待加强。
目标5 文档标准与表达	95	这是我本次项目的主责领域，掌握了需求规格说明书、接口文档、测试报告的规范写法，多次迭代后能清晰表达，具备与团队内外交流的基础。
目标6 团队协作与沟通	90	项目中频繁跨角色沟通、协调文档对齐，深刻体会团队协作的重要性，具备良好的沟通和协调能力。
目标7 项目管理与估算	80	观察并参与了华为云DevCloud的任务管理和Pipeline配置，理解了工作量估算和进度跟踪的基本方法，但尚未独立负责复杂项目管理。

2 第二部分：个人技术总结

在本次“代码编程错题帮”项目中，我主要负责项目文档撰写和介绍PPT的制作。在这个过程中，我深刻感受到技术内容的可视化呈现对团队沟通和最终汇报的影响远超预期。尤其是在将复杂的技术逻辑（如系统架构、接口流程、错题复盘机制）传达给非技术成员或评委时，优秀的PPT可视化能大幅提升理解效率和说服力。

因此，我选择从团队开发角度总结一个细粒度的技术主题：PPT中技术内容的有效可视化呈现方法（以PowerPoint + 流程图、架构图、数据图表为例）。

这个主题源于项目中多次迭代PPT的经历：最初的版本文字堆砌严重，听众反馈“看不懂技术部分”；后来通过学习和实践可视化技巧，最终汇报获得好评。这不仅帮助团队更好地展示产品价值，也让我个人在技术传播能力上有了显著进步。

1| 个人技术总结——PPT如何有效呈现技术内容

2| 概述：
PPT中技术内容的有效可视化呈现是指使用流程图、架构图、时序图、数据图表等视觉元素，将复杂的软件需求、设计与实现逻辑转化为直观、易懂的图形表达。该技术常用于需求评审、结项汇报、产品演示等场景。我学习它的主要原因是项目中需要向非技术成员和老师清晰讲解系统逻辑，而传统文字说明效率低下。难点在于如何在有限页面内平衡信息密度、美观性和准确性，避免“图太多乱”或“图太少空”。

3 第三部分：软件开发模式

3.1 项目开发过程

“代码编程错题帮”是一个帮助编程初学者高效复盘错题的Web应用。项目目标是为用户提供错题录入、自动解析、分类标签、相似题推荐和复盘统计等核心功能，帮助用户从“做错题”转向“学会题”。

主要技术栈：

• 前端：Vue 3 + Element Plus
• 部署：华为云DevCloud

开发过程中的关键决策：选择前后端分离架构以便并行开发；使用Git进行版本管理；接口文档采用Apifox统一管理。
遇到的主要挑战：团队成员分布异地、时间协调困难；前后端接口对齐反复修改；后期功能范围略有膨胀。解决方案：通过频繁线上沟通快速迭代接口文档、控制核心功能优先级、引入每日简短站会。

3.2 软件开发模式的思考

我们团队实际采用的开发模式更接近敏捷开发（Agile）的轻量版，主要特点是：

• 无严格的瀑布式阶段划分，而是边需求边实现边调整
• 主要通过QQ群线上文字+语音+屏幕共享进行日常沟通和“站会”
• 每周迭代一次小目标，快速出demo并内部反馈
• 文档和代码同步更新，无正式Sprint规划，但有明确的截止里程碑

这种模式的优点：

• 灵活性高，适合学生团队时间不固定、需求易变的情况
• 沟通门槛低，QQ随时在线，问题能快速响应
• 迭代快，能及时发现需求偏差，避免大返工

缺点：

• 缺少正式的回顾会议（Retrospective），问题容易重复出现
• 纯线上文字沟通容易产生歧义，尤其是技术细节描述
• 无严格的燃尽图或任务看板，进度把控主要靠个人自觉，存在拖延风险
• 文档更新有时滞后于代码

总体而言，这种轻量敏捷+QQ线上沟通的模式显著提升了我们的开发效率和团队协作，尤其适合地理分散、资源有限的学生项目，最终我们按时完成了核心功能并顺利汇报。

对比不同模式：

• 瀑布模型：适合需求极度明确、变更少的项目（如政府大型系统），但在我们这种探索性项目中会因前期需求不准导致后期大规模返工。
• 敏捷/Scrum：更适合我们，但需要更规范的工具（Jira、禅道）和仪式（每日站会、Sprint评审）。
• DevOps：强调自动化CI/CD，我们部分实现了（华为云Pipeline），但学生项目中完整落地难度较大。

个人思考与建议：
对于类似的学生团队项目，我建议继续采用轻量敏捷模式，但可以优化沟通工具（如补充飞书或企业微信，支持更好线程和任务卡片），并引入简单看板（如Trello）跟踪进度。未来若项目规模更大或有商业需求，再逐步引入完整Scrum或Kanban。软件开发模式没有绝对优劣，关键是匹配团队规模、成员经验和项目不确定性——“合适的就是最好的”。