软件工程个人随笔

软件工程课程随笔：我的技能树、自我评估与学习期待

本文为软件工程课程的开篇随笔，目的是在学期初梳理自己"会什么、不会什么、想学什么"，并借助 AI 工具生成一份学习指南，分析其对个人的参考价值。

一、技能树与技术偏好

1.1 已具备的专业知识与能力

能力 A：计算机底层原理与系统实践

  • 掌握操作系统内存模型、进程调用机制、数据类型差异，熟悉程序运行时栈、函数调用链路的底层逻辑。
  • 写代码前优先梳理数据存储方式与边界条件，严谨区分不同数据类型的行为差异，规范处理参数传递；注重代码健壮性与可读性，能够从底层视角解释高级语言的执行逻辑。

能力 B：数据结构与算法基础

  • 掌握线性表、栈、队列、树、图等常用数据结构，以及排序、查找等基本算法，能在具体问题中选用合适的结构。
  • 具备基本的复杂度分析意识，写代码时会考虑时间 / 空间开销，而不只是"能跑就行"。

能力 C：计算机基础理论

  • 修读过计算机组成原理、数据结构等基础课程，对计算机系统的层次结构（硬件—指令集—操作系统—应用）有整体认识。
  • 具备一定的英文技术文档阅读能力，能够借助参考文档、示例资料，学习工具与库的基础使用，解决开发里遇到的常见小问题。

能力 D：程序设计语言基础（C / C++、Python）

  • 能用 C / C++ 完成课程作业与小型程序，理解指针、结构体、函数等核心概念。
  • 了解 Python 基础语法与编程思路，具备基础的代码编写与程序调试能力。

1.2 感兴趣的技术方向

  1. 软件安全与程序可靠性方向：有底层编程学习基础，关注软件健壮性、程序异常与安全问题，希望探究软件运行时各类问题的产生原因与规避方案。
  2. 工具链与开发效率：对编辑器、构建工具、命令行工具、版本控制等"写代码之外的工程能力"感兴趣，希望把开发流程打磨得更顺畅。
  3. 前端与大型交互系统：希望深入学习前端工程化开发，了解大型前端项目的架构设计、代码规范、组件封装与团队协作模式，突破单一页面、简单课程作业的开发局限，掌握企业级前端项目的开发与维护逻辑。

1.3 欠缺的能力（自我认知）

欠缺项 具体表现
工程化实践 Git 仅停留在 add / commit / push 基本操作；没有系统学过分支策略、单元测试、CI/CD。
软件工程方法 对大多数软件工程相关专业术语只停留在"听过名词"的层面，没有实际用过。
团队协作 缺乏多人协作开发经验，不熟悉任务拆分、接口约定、代码评审等协作流程。
后端开发 对服务框架、数据库调优、接口设计等后端相关技术接触较少，缺少服务项目实战经验。
文档与表达 写代码时注释和文档意识不足，习惯"代码即文档"，不擅长把设计思路写成别人能看懂的文档。

小结：我目前的状态是"能写代码，但还不会做软件"——底层和算法有一定基础，但工程化、协作化、系统化的能力几乎是空白，而这正是软件工程课程要补的课。

二、代码量现状与目标

2.1 截至目前的代码量

截至目前，我累计的代码量大约在 5000 行左右（粗略估算，主要来自课程作业与小型练习）

需要说明的是，这个数字偏"课程作业导向"，代码以单文件、短程序为主，真正有完整工程结构（多文件、模块化、有文档）的项目很少。

2.2 本学期目标代码量

完成本学期软件工程课程后，我希望累计代码量达到 10000 行以上，增量重点放在：课程项目（团队开发）、课外小项目、刷题与练习等。

代码量只是一个量化指标，更重要的是代码质量的提升：本学期我希望写出的代码是"有设计、有测试、有文档、别人能维护"的，而不只是行数的堆砌。

三、本课程最期待学习的知识与期望收获

3.1 最期待学习的知识

  1. 软件完整开发流程：熟悉需求分析、设计、编码、测试、维护整套环节，重点补齐自己比较薄弱的设计与测试相关内容，明白各环节产出物与常用工具。
  2. 团队协作开发实践：体验任务拆分、Git 分支协作、代码评审等团队开发流程，把书本上的软件工程知识落到实际项目里。
  3. 代码质量与重构：学习基础设计模式，能够识别劣质代码，对代码做优化重构，提升代码可读性与可维护性。

3.2 希望获得的收获

  1. 一个能拿得出手的课程项目：有完整文档（需求文档、设计文档、测试报告）、能演示、代码结构清晰，最好能放到个人作品集里。
  2. "先设计后编码"的习惯：不再拿到需求就直接开写，而是先画类图、定接口、写测试骨架，再填实现——这是我认为从"学生代码"到"工程师代码"最关键的转变。
  3. 对软件工程的整体认知：理解软件工程不是"写文档的繁琐流程"，而是"在有限时间、有限人力下交付高质量软件的方法论"，建立起工程思维。

四、AI 生成的学习指南与分析

4.1 生成过程

我选择使用的 AI 工具是 DeepSeek。

  • 提问内容："请为软件工程课程生成一份简要的学习指南，面向有一定编程基础（C / 汇编 / Python）但缺乏大型项目经验的本科生，要求覆盖课程主线、重点概念、学习方法、推荐资源和常见误区。"

  • 生成时间：2026 年 9 月

  • 以下为 DeepSeek 生成的原文（未做修改）。

4.2 指南原文（DeepSeek 生成）

软件工程课程学习指南（简要版）
一、课程主线
软件工程 = 方法 + 过程 + 工具，核心目标是 "在预算内按时交付高质量软件"。把握软件生命周期主线：需求 → 设计 → 编码 → 测试 → 维护，每个阶段都有明确的输入、输出和验收标准。
二、重点概念
软件过程模型
：瀑布模型、迭代模型、敏捷开发（Scrum / XP），理解各自适用场景，不要迷信某一种模型。
需求工程
：功能需求 vs 非功能需求；用例图、用户故事；需求的可验证性。
UML 建模
：用例图、类图、时序图、活动图，重点掌握类图与时序图。
设计原则与模式
：SOLID 原则；常用设计模式（工厂、单例、观察者、策略、装饰器）；识别代码坏味道并重构。
软件测试
：单元测试、集成测试、系统测试、验收测试；黑盒 vs 白盒；测试驱动开发（TDD）；代码覆盖率的意义与局限。
配置管理
：Git 分支策略（Git Flow / GitHub Flow）、版本号规范、变更管理。
项目管理
：工作量估算（功能点 / 用例点）、风险管理、进度跟踪、团队协作。
三、学习方法
项目贯穿学习
：选一个真实的小项目（哪怕是待办清单、博客系统），把每个知识点都用到项目里，边学边做，不要只背概念。
工具趁早熟悉
：Git、IDE 调试、构建工具（Maven / Gradle / Make）、单元测试框架（JUnit /pytest），第一周就搭好环境。
文档即沟通
：把需求文档、设计文档、测试报告当成 "和未来的自己、和队友沟通" 的工具，而不是应付老师的作业。
主动参与团队
：课程项目中主动承担模块，积极参与代码评审，学会给别人提建设性意见，也学会接受别人的意见。
每周复盘
：每周花 30 分钟回顾本周学了什么、项目推进到哪、遇到什么坑，写进个人学习日志。
四、推荐资源
教材：《软件工程：实践者的研究方法》（Pressman）、《软件工程》（张海藩）
设计模式：《Head First 设计模式》《设计模式：可复用面向对象软件的基础》（GoF）
代码质量：《代码整洁之道》（Robert C. Martin）、《重构：改善既有代码的设计》（Martin Fowler）
工具：
draw.io/PlantUML（UML 画图）、Pro Git（Git 免费电子书）、JUnit /pytest 官方文档
五、常见误区
把文档当负担
：文档是沟通工具，不是形式主义；好的文档能省下大量返工时间。
轻视测试
：测试不是 "写完代码再补" 的环节，而是设计的一部分；TDD 能显著减少 bug。
最后一刻才集成
：频繁集成、小步提交，避免 "集成地狱"。
不写提交信息
：git commit -m "update"，是对队友和未来自己的不负责。
只学不用
：软件工程是实践学科，不落到项目上的概念很快就会忘。

4.3 合理性分析

合理之处：

  1. 主线把握准确：指南把软件工程概括为 "方法 + 过程 + 工具"，并以软件生命周期为主线串联所有知识点，这与大多数软件工程课程的大纲结构一致，没有跑偏。

  2. 重点概念覆盖全面：过程模型、需求、UML、设计模式、测试、配置管理、项目管理七大块基本覆盖了本科软件工程课程的核心内容，没有明显遗漏。

  3. 学习方法务实："项目贯穿学习"" 工具趁早熟悉 ""文档即沟通" 这几条都抓住了软件工程 "实践导向" 的特点，比 "多读教材多背书" 的建议有效得多。

  4. 常见误区有针对性："最后一刻才集成"" 不写提交信息 ""只学不用" 这几条精准命中了学生在课程项目中最容易犯的错误，有实际警示价值。

不足之处：

  1. 内容偏通用，缺少个性化：指南是面向 "所有有编程基础的本科生" 的，没有针对我个人的短板做定制 —— 比如我 C 底子好但工程化空白，指南没有建议 "如何把底层思维迁移到抽象设计思维"，也没有针对我前端薄弱的情况给出补全路径。

  2. 未结合具体课程场景：指南没有考虑本课程的教材、课时安排、考核方式（考试占比、课程设计评分标准、答辩要求），知识优先级是 "通用最优" 而非 "本课程最优"。

  3. 资源推荐存在阅读门槛：推荐的 Pressman、GoF 等都是英文大部头或经典但偏难的书，对刚接触软件工程的本科生来说，直接读 GoF 可能会劝退，缺少 "入门级 → 进阶级" 的梯度。

  4. 对 "考试" 维度关注不足：本科课程最终有考试和答辩，指南完全聚焦于 "能力提升"，没有提到如何应对概念性考试、如何准备答辩演示，这对学生来说是实际需求。

  5. 部分表述偏绝对：比如 "TDD 能显著减少 bug"——TDD 的效果在学术界和工业界都有争议，并非 universally accepted，指南把它说成确定结论不够严谨。

总体判断：指南整体合理、结构清晰、可操作性强，可以作为本学期学习路线图的骨架；但需要结合本课程大纲、评分标准和我个人的短板做二次裁剪，不能直接照搬。

4.4 对个人的帮助评估

有帮助的部分：

  1. 明确了知识版图：让我第一次系统地看到软件工程 "到底学什么"，把之前零散听到的名词（敏捷、UML、TDD、设计模式）放进了一个有逻辑的框架里，知道了 "我不懂什么"。

  2. 工具清单可直接落地：Git 分支策略、PlantUML、JUnit /pytest 这些工具我之前只听过名字，指南给了明确的 "第一周就搭好环境" 的行动建议，我可以直接照着做。

  3. 常见误区有预警作用："最后一刻才集成"" 不写提交信息 " 这两条我预感自己很可能会犯，提前看到相当于打了预防针。

帮助有限的部分：

  1. 通用指南无法回答 "我这学期具体要交什么"：课程的作业要求、项目选题、评分细则只有老师和课程大纲能给，AI 指南替代不了。

  2. 无法替代实践：软件工程是 "做" 出来的，指南写得再好，不落到课程项目上就是纸上谈兵 —— 真正的提升来自把指南里的每一项都亲手做一遍。

  3. 对个人短板的针对性不足：我最缺的是 "从底层思维切换到抽象设计思维" 的能力，指南没有针对这一点给出路径，需要我自己结合项目去摸索。

五、结语

写这篇随笔的过程，本身就是一次 "需求分析"—— 我需要先搞清楚自己的现状（会什么、不会什么），才能定义本学期的目标（想学什么、达到什么）。

我目前的优势在底层和单点能力，短板在工程化和协作化；本学期软件工程课程恰好是补短板的关键一课。AI 生成的指南给了我一个清晰的骨架，但真正的成长要靠自己把每一个概念落到项目里、把每一次提交写清楚、把每一次团队沟通做扎实。

希望学期末回头看这篇随笔时，我能说："当时列的目标，大部分都做到了。"

bye~👋🏻👋🏻

posted @ 2026-09-08 23:29  yitt  阅读(10)  评论(0)    收藏  举报