软件工程第一次作业

这个作业属于哪个课程	软件工程班级链接
这个作业要求在哪里	作业要求链接
这个作业的目标	1. 完成 GitHub 与博客园账号注册及个人信息完善；2. 学习 Markdown 排版并撰写自我介绍随笔；3. 阅读《构建之法》并提出有质量的问题；4. 制定本学期学习计划与职业规划；5. 通过阅读前人经验获得启发与反思

一、介绍自己，建博客

1.1 关于我

大家好，我是段翔晖，来自 广东工业大学计算机学院软件工程专业，目前大三。很高兴在这门软件工程课上开始我的第一篇博客。

我的 GitHub 主页：https://github.com/zayuchips/
我的博客园主页：https://www.cnblogs.com/zayuchips/

GitHub 仓库截图：

博客园后台截图：

1.2 为什么写博客

写博客对我来说是一个全新的尝试。在此之前，我的学习笔记大多保存在本地的 Notion 或者 Word 文档里，写完之后就很少再回顾。而博客不同——它是一种公开的、可追溯的、有反馈的知识输出方式。

正如娄老师所说，写博客虽然花时间，但是很有意义。它逼迫你把模糊的理解变成清晰的文字，把零散的知识点组织成体系。更重要的是，当你把想法公开出去，别人的评论和提问会帮你发现自己思维的盲区。我决定坚持一个学期，看看效果如何。

1.3 我的闪光点

很多人觉得自己没有什么特别的闪光点，我以前也这么认为。但仔细想想，我在吉他演奏方面确实花了不少功夫。

高一的时候偶然听到一首指弹吉他曲，被深深吸引。从零开始，我用了将近两年时间自学吉他。最初每天练习 30 分钟，手指磨出了茧子，大横按怎么也按不响，几乎想放弃。后来我给自己定了一个规矩：不管多忙，每天至少拿起吉他弹 15 分钟。坚持了半年之后，突然有一天发现大横按变得轻松了。到现在，我能比较流畅地演奏押尾光太郎的《黄昏》，也在学校音乐节上表演过。

这段经历教会了我一件事：很多看似需要天赋的技能，其实靠的是持续的、有方法的练习。这也是我希望在软件工程这门课上复制的学习方式。

除了吉他，我对羽毛球也有一定的研究，从大一加入校队到现在，从连发球都发不好到能参加校际比赛，这段经历同样让我体会到"刻意练习"的力量。

二、现状、经验和计划

2.1 专业选择与技能差距

我为什么选择计算机类？

坦白说，最初选择计算机类有一定的"随大流"成分——高考填志愿时，计算机类专业分数高、就业好，家人也支持。但真正进入大学后，在大一学 C 语言的时候，我第一次体验到了用代码解决问题的快感：当自己写的小程序正确运行的那一刻，那种成就感是其他学科给不了我的。从那以后，我逐渐从"被动选择"变成了"主动投入"。

技能调查——我与合格 IT 毕业生的差距

根据技能调查表，我选择了以下 6 项我认为特别重要的技能进行自我评估：

技能	目前水平 (0-9)	课程结束后目标 (0-9)	提高手段
Java/Python 编程	3	6	① 每周完成课程项目并额外刷 LeetCode 2-3 题；② 阅读优秀开源项目源码；③ 参与 Code Review
单元测试与调试	1	5	① 学习 JUnit/pytest 框架；② 每次写代码都强制编写对应测试；③ 阅读《构建之法》第 2 章并实践
Git 版本控制	2	6	① 本课程所有代码都通过 Git 管理；② 学习分支策略和 Pull Request 流程；③ 参与团队协作项目
需求分析与文档写作	1	5	① 学习 UML 建模工具；② 在课程项目中负责需求文档撰写；③ 阅读《构建之法》相关章节
团队协作与沟通	2	6	① 积极参与团队项目的每日站会；② 学习敏捷开发流程；③ 主动承担不同角色（PM、Dev、Test）
代码规范与设计模式	1	5	① 严格遵守团队代码规范；② 阅读《Head First 设计模式》；③ 通过代码复审不断改进

总结： 从表格中可以清楚地看到，我目前大多数技能都处于 1-3 的水平，距离"能通过面试"的 5 分还有明显差距。尤其是在工程化能力（测试、版本控制、文档）方面几乎是空白。这些正是我希望通过本学期的课程和项目实践来弥补的。

2.2 阅读心得

a) 我为何要来上课并且认真参与？

读了那位学生的思考以及博客下面的评论，我深受触动。说实话，在大学里我也曾经有过"这门课水一水就过了"的想法。但那篇博客里有一句话让我印象深刻："你交了学费来上学，不是为了混一个文凭，而是为了在人生最好的几年里，最大限度地提升自己。"

我来上课的原因很朴素：首先，软件工程是我未来就业的核心技能，我不能在这个环节偷懒；其次，我花了时间坐在这里，如果不认真参与，那这些时间就纯粹浪费了；最后，邹欣老师的教学方法——"做中学"，是我一直认同的理念。与其在宿舍刷手机，不如把同样的时间用来写代码、做项目、写博客，至少期末的时候我能拿出一些实实在在的东西。

b) 关于师生关系与作业态度

在我的大学经历中，大多数课程采用的是传统的"讲授-考试"模式：老师在台上讲，学生在台下听（或者不听），期末考试一锤定音。这种模式下，师生关系更像是"售货员与顾客"——老师负责"交付"知识，学生负责"接收"。

我希望这门课的师生关系更像"教练与运动员"。 教练不会替你上场比赛，但会制定训练计划、纠正你的动作、在你偷懒的时候推你一把。

如果老师布置的作业对我来说有些困难，我的选择是：

C：向老师和同学请教，花更多时间，把作业全部完成。

原因很简单：如果我只做"能保证及格的部分"（选项 D），那我学到的也只是"及格水平"的东西。而作业的难点往往恰恰是成长最快的地方。就像健身，如果永远只举自己轻松能举起的重量，肌肉是不会增长的。

c) 引用参考与抄袭剽窃的区别

这是一个非常重要的问题。在工作中，引用文献和参考别人的资料是完全正当且必要的——事实上，现代软件开发本身就是建立在大量开源项目和前人成果之上的。站在巨人的肩膀上，我们才能看得更远。

那么，引用参考与抄袭剽窃的区别在哪里？我认为核心在于三点：

是否注明出处：引用别人的代码、思路、设计，必须明确标注来源。不标注，就是把别人的劳动成果据为己有。
是否有自己的思考和增量：参考别人的工作后，你是否理解了其原理？是否在此基础上做了改进、适配或扩展？如果只是照搬而不理解，那和复制粘贴没有区别。
是否遵守许可协议：开源项目有不同的 License（MIT、GPL、Apache 等），使用他人代码必须遵守相应的协议要求。

在本课程中，我会严格遵守学校和老师的学术诚信要求：任何参考他人资料的地方都会注明出处，所有提交的代码和文档都是自己理解并完成的。 如果不确定某个行为是否算抄袭，我会先向老师或助教确认。

2.3 未来规划

几年后，我目前的打算是先进入互联网/软件公司从事开发工作，积累 2-3 年实际项目经验后，再考虑是否读研深造。

做出这个选择的原因是：我认为软件工程是一门实践性极强的学科，课堂上学到的知识需要通过真实的项目来消化。先工作几年，能让我更清楚地知道自己欠缺什么，将来如果读研，也能带着问题去学习。

相比其他同学：

优势： 我有较强的自学能力和自律性（从坚持练吉他的经历可以看出）；我对代码质量有一定的追求，不喜欢"能跑就行"的态度；我愿意花时间在文档和博客上总结反思。
劣势： 我的编程基础相比一些从高中就开始写代码的同学来说还有差距；我在算法和数据结构方面的功底还不够扎实；我的项目经验较少，缺乏大型团队协作的经历。

本学期的规划： 针对上述分析，我给自己本学期的规划是：

在课程项目中担任至少一次核心开发角色，积累完整的软件开发流程经验；
每周刷 3-5 道算法题，补强数据结构基础；
坚持写博客，每周至少一篇技术总结；
参加至少一次技术分享或代码复审活动。

2.4 课程计划与 WOOP 分析

课程计划

参考美国本科和中国软件工程本科的教学方式，我对这门课的期待是：不只是听老师讲理论，而是通过真实的团队项目来学习软件工程的完整流程——从需求分析、设计、编码、测试到部署和运维。我希望能在这门课中体验到"做中学"的教学方式。

关于当助教：如果本学期学习效果达到一定水平，我愿意在下学期申请成为助教，帮助后来的同学。

代码量统计

语言	代码行数（约）
C/C++	3,500 行
Python	2,000 行
Java	1,200 行
合计	约 6,700 行

据我了解，入职一流软件公司/互联网公司通常需要至少 2-3 万行以上的代码积累（包括项目代码和练习代码）。而从事高校教学科研工作，则需要在此基础上有更深入的算法和理论研究。我目前的代码量还远远不够，这也是我本学期要重点突破的地方。

时间投入

我打算平均每周拿出 12-15 个小时用在这门课上（包括上课时间）。

对于"是否要发奋赶上"这个问题，我的选择是：

D：比以前课要多很多，直到达到目标为止。

我计划在本课程结束时，累计完成 15,000 行以上的代码量。按照 16 周计算，每周应完成约 500 行有效代码（不含复制粘贴和自动生成的代码）。

WOOP 方法规划

第一步 Wish/确定愿望：

我希望在这门软件工程课程结束时，能够独立完成一个完整的、可运行的软件项目（从需求分析到部署），并且团队项目获得良好以上的评价。同时，我的编程能力从目前的 3 分提升到 6 分，具备通过互联网公司技术面试的基本能力。

第二步 Outcome/确定结果：

如果这个愿望实现了，我将会：

拥有一个可以写在简历上的完整项目经历，面试时能自信地讲解项目细节；

掌握了 Git 协作、单元测试、代码复审等工程化技能，不再是"只会写代码"的程序员；

博客上积累了 15+ 篇高质量技术文章，形成自己的技术影响力；

获得实习/工作的敲门砖，暑假能拿到一份不错的实习 offer。

这种感觉就像吉他练到能流畅演奏一首复杂曲子——那种从"做不到"到"做到了"的成就感，是无与伦比的。

第三步 Obstacle/找出障碍：

回顾过去的经验，以下障碍可能妨碍我实现愿望：

障碍类型	具体描述
内部障碍：拖延	作业截止前几天才开始赶工，平时总觉得"还有时间"，结果一拖再拖。具体表现为：打开电脑准备写代码，却先去刷了半小时 B 站/抖音。
内部障碍：畏难情绪	遇到复杂的 bug 或看不懂的文档时，容易产生"算了，先跳过"的想法，结果问题越积越多。
外部障碍：其他课程压力	本学期还有其他几门专业课，期末考试周可能无暇顾及软件工程的项目。
外部障碍：团队沟通	团队成员时间难以统一，线上沟通效率低，容易产生误解。

最可能的失败因素：

不能长期自律。 学期初的激情往往在第 4-5 周就消退了，尤其是当其他课程作业增多、天气变冷的时候。过去几个学期，我立的 flag 经常在期中就倒了。

第四步 Plan/使用"if-then"做风险防范计划：

如果（If）	那么（Then）
如果我打开电脑后忍不住想刷手机/视频	那么我先把手机放到另一个房间，打开电脑后直接进入编程环境，先写 5 分钟代码再说
如果我遇到一个 bug 超过 30 分钟解决不了	那么我先在纸上画出问题流程图，然后去 Stack Overflow/GitHub Issues 搜索，如果还是不行就发消息问同学或助教
如果我在周三之前没有完成本周的代码目标	那么我在周四和周五各增加 2 小时的编程时间，周末不安排娱乐活动直到补齐
如果团队沟通出现分歧或延误	那么我主动提议开一次 15 分钟的线上站会，明确每个人的任务和截止时间，并记录在共享文档中
如果期中考试周压力很大	那么我提前一周完成软件工程当周的最低任务量，不把所有事情堆到一起

三、提有质量的问题，给认真的反馈

3.1 阅读《构建之法》提出的 5 个问题

通过快速阅读《构建之法》全书，以下是我提出的 5 个问题：

问题 1：单元测试的"彻底性"是否在实践中可行？

出处： 第 2 章"个人技术和流程"，2.1 单元测试（约第 25-28 页）

书中提到好的单元测试标准之一是"彻底性"——要测试 API 中的每一个方法及每一个参数。

我的问题： 在一个实际的大型项目中，一个模块可能有上百个方法，每个方法有多个参数和边界条件。如果要求对每一个方法都编写单元测试，测试代码的行数可能会超过业务代码本身。我查了资料，Google 的工程实践中提到他们的测试代码和业务代码比例大约是 1:1 甚至更高。

根据我的实践，在学校课程的小项目中，写单元测试的时间大约是写业务代码的 50%-80%。如果项目规模扩大 100 倍，这个比例还能维持吗？

我的困惑是： 在实际工程中，如何平衡单元测试的"彻底性"和开发效率？是否存在一个"足够好"的测试覆盖率阈值（比如 80%），超过这个阈值后，继续增加测试的边际效益就急剧下降了？

问题 2：代码复审中如何处理"审美分歧"？

出处： 第 4 章"两人合作"，4.4 代码复审（约第 65-70 页）

书中介绍了代码复审（Code Review）的重要性和基本流程，强调复审能发现缺陷、提高代码质量。

我的问题： 在实际的代码复审中，很多争议并不是"对与错"的问题，而是"风格偏好"的问题。例如，一个函数应该拆成三个小函数还是保持一个长函数？变量名用 data 还是 processedResult？这些往往没有绝对的对错。

我在 GitHub 上看过一些知名开源项目的 PR 讨论，发现即使是资深工程师之间，也经常因为代码风格问题产生长时间的争论，甚至导致 PR 长期无法合并。

我的困惑是： 书中是否建议团队在项目开始时就制定一份详细的代码规范文档（Style Guide），并在复审中严格按照规范执行，从而减少"审美分歧"带来的效率损耗？还是说应该保留一定的灵活性，让工程师有发挥个人风格的空间？

问题 3：敏捷开发的"拥抱变化"是否会被滥用？

出处： 第 6 章"敏捷流程"，6.2 Scrum 的介绍（约第 105-115 页）

书中介绍了敏捷开发的核心理念之一是"拥抱变化"，鼓励团队快速响应需求变更。

我的问题： 我在一些技术论坛上看到过不少开发者的吐槽：有些产品经理以"敏捷"为借口，频繁修改需求，导致开发团队疲于奔命，代码质量反而下降。有人甚至说："敏捷开发就是让程序员没有理由拒绝需求变更。"

我反对作者的部分观点： 虽然"拥抱变化"的理念在理论上是正确的，但在实践中，如果没有对需求变更的严格控制机制（比如变更影响评估、变更冻结期），敏捷很容易变成"混乱开发"的代名词。我认为书中应该更加强调变更管理的纪律性，而不仅仅是"拥抱变化"的理念。

问题 4：如何衡量一个软件工程师的"成长"？

出处： 第 3 章"软件工程师的成长"，3.1 个人能力的衡量与发展（约第 43-50 页）

书中讨论了软件工程师的能力衡量标准，提到"在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面"。

我的问题： "稳定一致的交付时间"确实是一个好的指标，但它是否过于结果导向？一个工程师可能因为任务本身难度低而"稳定交付"，另一个工程师可能因为承担了更有挑战性的任务而偶尔延迟。如果只看交付时间，是否会鼓励大家去挑简单的任务？

此外，我查了一些资料，发现 Google 在评估工程师时使用的是"影响力"（Impact）而非单纯的交付速度。一个工程师写的代码可能被整个团队复用，其价值远超完成多个小任务。

我的困惑是： 是否存在一个多维度的工程师成长评估体系，能够同时考虑交付稳定性、技术深度、团队影响力和创新贡献？书中的技能评估表是否就是这个体系的雏形？

问题 5：创新是否真的可以"教"出来？

出处： 第 16 章"创新"，16.1 创新的迷思（约第 310-320 页）

书中讨论了创新的本质，提到创新不完全是天才的灵光一现，而是有方法可循的。

我的问题： 作为一个编程经验还不多的学生，我对这一章特别感兴趣。书中提到创新可以通过系统的方法（如 TRIZ）来培养。但在我的经验中，身边那些"最有创意"的同学，往往不是成绩最好的，而是涉猎最广泛的——他们看杂书、玩游戏、参加各种社团，似乎在不务正业中获得了灵感。

我查了资料： 乔布斯在斯坦福的演讲中提到，他大学时旁听的书法课，后来直接影响了 Mac 电脑的字体设计。这说明创新的素材往往来自看似不相关的领域。

我的困惑是： 如果创新依赖于跨领域的知识积累和偶然的灵感碰撞，那软件工程课程能在多大程度上"教"出创新能力？也许课程更应该做的是创造有利于创新的环境（如 Hackathon、跨学科交流），而不是直接教授创新方法？

3.2 认真反馈

关于课程反馈，我的选择是：

D：经常提问题，平时就经常给老师和助教提反馈。

我认为反馈是双向受益的：对老师来说，反馈能帮助改进教学；对我来说，提出问题和给出反馈本身就是一种深度学习——它要求我不仅要理解内容，还要能批判性地思考。

四、前车之鉴

4.1 读《IT 小小鸟》——把每天做的事分类

参考文章：A. 把每天把要做的事情分成 ABCD 四类

这篇文章中提到了时间管理的 ABCD 分类法：A-紧迫且重要；B-重要不紧迫；C-紧迫不重要；D-不重要不紧迫。

我的感想： 这个分类法听起来很简单，但真正做起来却很难。我发现自己经常把大量时间花在 C 类（紧迫但不重要）的事情上——比如回复群消息、处理社团琐事——而忽略了 B 类（重要但不紧迫）的事情，比如系统学习算法、阅读技术书籍。

B 类事情的特点是：今天不做不会有什么后果，但长期不做会严重影响你的竞争力。这正是"温水煮青蛙"的危险所在。读完这篇文章后，我开始每天晚上花 5 分钟列出第二天的 ABCD 清单，虽然还不能完全执行，但至少让自己意识到了时间分配的失衡。

4.2 读《偏科生自学摸索的道路》——实习经验的重要性

参考文章：D. 偏科生自学摸索的道路

这篇文章讲述了一个"偏科生"如何通过自学和实习，最终找到自己在技术领域的方向。文章中有一句话让我印象很深："实习不仅仅是为了简历好看，更重要的是让你知道业界真正在做什么。"

我的感想： 我目前正处于文章中描述的"迷茫期"——学了很多课本知识，但不知道在实际工作中它们是怎么被使用的。比如，我学过了数据库原理，但从来没在一个真实的项目中设计过数据库架构；我知道 HTTP 协议，但从来没调试过一个真实的 RESTful API。

这篇文章让我更加坚定了本学期要积极参加课程项目的决心——虽然课程项目比不上企业实习，但至少是一个"模拟真实场景"的机会。同时，我也计划在暑假积极寻找实习机会，哪怕是从最基础的测试岗位做起。

4.3 读《技术栈和大佬的爆栈之旅》——技术广度与深度的平衡

参考文章：I. 技术栈和大佬的爆栈之旅

这篇文章详细记录了一位技术大佬从入门到精通的成长路径，涉及的技术栈之广令人叹服。但仔细看，他的成长路径其实是先深后广的——先在一门语言（C#）上扎下了深厚的根基，然后才向其他领域扩展。

我的感想： 我身边有不少同学（包括我自己），犯了一个常见的错误：贪多嚼不烂。今天学 Python，明天学 Go，后天又去看 Rust，每种语言都只会写 Hello World。这篇文章让我意识到，与其学十种语言的皮毛，不如精通一种语言的核心——包括它的内存模型、并发机制、标准库设计哲学等。

我目前选择了 Java 作为主要深耕的语言（因为它在企业级开发中应用最广），计划在学期结束前读完《Effective Java》这本书。在精通一门语言之后，再学习其他语言会发现很多概念是相通的，效率会高得多。

五、总结

这篇随笔是我进入软件工程课程的第一份作业，也是我第一次如此认真地审视自己的学习状态和未来方向。

总结几个关键要点：

写博客是一种高效的学习方式，我会坚持一学期，期末再回顾效果。
我目前的工程化能力严重不足，需要通过课程项目和刻意练习来弥补。
WOOP 方法帮我把模糊的愿望变成了具体的行动计划，尤其是"if-then"预案让我对可能遇到的障碍有了心理准备。
前人的经验是最好的教材，他们踩过的坑可以帮我少走弯路。

本文使用 Markdown 编写，遵循中文文案排版指北规范。

posted @ 2026-09-04 19:13 zayu 阅读(10) 评论(0) 收藏举报

刷新页面返回顶部