软件工程作业——我的第一篇博客

这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS

这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710

这个作业的目标：1. 完成 GitHub、博客园账号注册配置，加入课程班级，熟悉博客园 Markdown 写作与 GitHub 基础使用，搭建个人技术输出阵地。
2. 自我复盘：梳理个人优势、专业现状，对照 IT 毕业生能力要求，评估自身技能差距，制定课程学习、代码量、时间投入计划，运用 WOOP 方法预判学习障碍并制定应对方案。
3. 研读《构建之法》，练习提出有理有据的高质量学习问题；理解课程的师生关系、作业困难应对、学术引用与抄袭剽窃的边界。
4. 阅读前辈技术博文，借鉴前人经验教训，思考个人未来发展方向，确立本学期学习规划，养成技术思考与书面输出的习惯。

后台编辑界面：

一 自我介绍
我是计算机专业的一名本科生，刚刚开通博客园个人技术博客。通过本次作业完成账号注册、头像与博客名称设置，并且加入课程班级。写技术博客是输出自己学习思考的很好方式，虽然写博客会花费不少时间，整理知识点、复盘踩过的坑，长期坚持会加深理解，沉淀个人学习痕迹。

每个人都有属于自己的闪光点，不只是课本成绩。我的优势是自学能力较强，遇到陌生技术愿意花时间去查资料、动手调试；我在三年级的时候就学会了利用网络完成了三阶四阶魔方的还原自学，在上大学之前，我自认为我有学习的热情和自律的学习，但上了大学之后，我发现我最大的缺点就是不自律，我的自律被局限在了老师发布的任务中，我很难对除了作业/任务外的学习投入长时间的精力，这也是我最苦恼和焦虑的地方，我的自学能力被限制在了自己感兴趣的方向，我很难在枯燥的复习中提起精神，但又有着无限的精力去研究新的游戏和自己感兴趣的软件。。

二 现状、经验和计划
（1）需求对齐与代码健康度：6分 期望分数：7分 智能体编排与工具使用：2分 期望分数：7分 手动掌控力与底层原理 4分 期望分数：5分 工程复现性与构建完整度 3分 期望分数：5分 云原生部署与资源优化 1分 期望分数：5分 我的预期提升方式：1. 课后多读开源项目、课程示例源码，逐段梳理代码逻辑；2. 遇到报错优先独立调试，练习看报错日志定位 bug，不直接复制 AI 生成完整解决方案；3. 完成课程作业后复盘，写下代码阅读笔记；4. 参与代码阅读类练习，看懂别人项目后画出简易流程图；5. 和同学结对互相阅读对方代码，互相提问代码逻辑。

（2）问题a:我认同专注是非常珍贵的能力。课堂上如果老师内容有价值，我会尽量跟上思路，训练自己长时间聚焦的能力；但遇到内容枯燥、收获有限的课堂，我不会机械地硬熬，而是会利用课堂时间做课程相关自学。
重点不是形式上 “眼睛盯着老师”，而是保证自己的注意力投入到专业学习这件事上。不能简单把 “课讲得不好” 当做彻底摆烂的借口，也不能全盘否定自主学习的价值。
问题b: 我在大学实际体验过路人甲 / 路人乙的师生关系：老师上完课就离开，课下几乎没有交流，学生遇到问题只能靠自己查资料。
我希望软件工程这门课是教练‑学员的师生关系：老师给出项目、作业训练任务，指出我的代码、文档存在的不足，给予及时反馈；我作为学员主动完成训练，遇到困难主动求助，接受严格标准，不能期待老师放水给分。
如果老师布置的作业对我有些困难，我选择 C：向老师和同学请教，花更多时间，把作业全部完成。
问题c:参考、引用别人资料，是站在前人的成果之上继续工作；抄袭剽窃是直接把别人的劳动成果冒充为自己的，二者有清晰界限。

1. 合理引用参考应该是：
   写文档、博客：借鉴别人观点、文字，明确标注原文链接、出处，说明哪些内容来自他人；自己有独立的理解、分析、新的观点，不是全盘复制。
   写代码：使用开源库、框架、公开工具，遵守开源协议；借鉴网上代码片段，理解逻辑之后改写适配自己项目，在注释标注来源，核心业务逻辑是自己实现。

2. 抄袭、剽窃应该是：
   文档：大段复制他人文字，不标注来源，直接当作自己的随笔、作业提交。
   代码：直接复制别人完整项目、作业代码，只改少量变量名，没有理解代码逻辑，冒充自己的开发成果。

（3）几年之后人生的出路有很多，阅读了多篇学长的博客，看到有人走科研、有人做企业开发、有人考公，每个人的路径都和自身积累息息相关。
我的选择：毕业后先考研，从事偏向后端开发的岗位，暂时不考虑读研做学术研究，也不打算考公。
当下我为未来做的准备

1. 夯实计算机核心专业课，把操作系统、计算机网络、数据结构、数据库的理论基础吃透，理论是工程实践的根基；
2. 主动动手写小型项目，把书本知识落地实践，使用 GitHub 托管自己的全部练习代码，养成版本控制习惯；
3. 坚持写技术博客，复盘自己踩过的坑，锻炼总结、文档撰写能力，这也是企业开发很看重的软实力；
4. 借鉴 UCSD 课程、国内学长的经验，重视做中学，不只看书背概念，主动接触项目分工、需求分析、测试这些软件工程的实际环节。
   和周围同学对比
   优势
5. 动手实践意愿较强，遇到 bug 愿意花时间排查，不会轻易放弃；
6. 愿意接受工程类课程的高要求，能够接纳迭代开发的思想，不追求一次性写出完美代码；
7. 习惯查阅技术博客、公开资料学习，乐于借鉴前人经验来改进自己。
   劣势
8. 大型完整项目实战经验很少，大多是课堂小 demo；
9. 算法刷题的积累不足，底层原理理解比较浅薄；
10. 团队协作做完整软件项目的经历匮乏，对需求分析、测试、项目管理的经验欠缺。

针对该方向的本学期规划

1. 认真完成软件工程全部个人、结对、团队项目，完整走完软件从需求到发布的流程，补齐工程实践短板；
2. 课余保持算法练习，每周固定刷题，巩固数据结构与算法；
3. 课余完成 1‑2 个小型后端 demo，上传到 GitHub，丰富个人项目履历；
4. 坚持输出博客随笔，记录课程作业踩坑、项目思考；
5. 刻意练习 Git、单元测试、模块化设计这些工程师必备技能，不再只关注代码能不能跑，同时关注代码可读性、可维护性。
   （4）参考几篇博客：国外 UCSD 软件工程课程以模拟公司模式做真实项目，强调过程管控；schaepher 的博文提到软件工程课不等于单纯写代码，要学会任务拆解、迭代思维；SivilTaram 的助教之路文章介绍现代实践课程模式，但我不想担任助教，原因：我现阶段首要目标是补齐个人工程能力短板，需要把时间优先投入个人编码、项目练习；助教需要投入大量时间批改作业、答疑，会挤占我本身学习软件工程实践的时间，因此我不参与助教相关工作。
   我对课程的期待：
   这门课不应该只是背诵软件工程名词概念，而是践行“做中学”。
6. 希望完整体验真实软件项目全生命周期：需求挖掘、设计、编码、单元测试、重构、团队协作；
7. 熟练掌握 Git/GitHub、文档编写、任务拆解等工程师必备工具与方法；
8. 学会结对编程、团队分工合作，懂得如何和同学沟通需求、处理分歧；
9. 养成写博客复盘的习惯；
10. 希望老师、助教扮演健身教练式角色，指出我的代码、文档存在的不足，给到及时反馈，用较高的实践标准训练我们。

我目前仅在C语言中有大约2000行左右的代码和Java大约500行左右的代码；入职一流互联网 / 人工智能软件公司：学生阶段通常需要10000 行以上有效实践代码，来源于课程作业、个人项目、开源练习；不包括直接复制粘贴教材示例；行数只是参考，更看重项目质量、代码规范、GitHub 项目履历。高校教学科研工作：代码行数不是核心评判指标，更看重论文科研成果，但也需要数千行以上代码用来完成算法复现、实验仿真。

我打算在这门课上每周投入5小时的时间，C: 比以前的课稍多一些 我计划在本课程结束时，完成新增有效代码：4000 行；除去期末复习周，每周计划完成约 280 行有效代码。

三 提有质量的问题, 给认真的反馈
《构建之法》阅读后的五个问题
问题一：第 1 章 概论 1.2 节 什么是 “足够好的软件”
引用书中原文：“软件工程的一个重要任务，就是要决定一个软件在什么时候能‘足够好’，可以发布。有些同学认为，所谓好软件，就是软件没有缺陷（Bug），所谓软件工程，就是把软件中的 Bug 都消灭掉的过程。”

我有这个问题：书中提出软件不需要追求绝对完美，达到 “足够好” 就可以发布。但是 “足够好” 是一个很主观的概念。在学生课程项目里面，没有商业用户、没有市场数据作为参考，我们该拿什么客观标准去判断自己的课程作业项目是否达到 “足够好”？

我查了资料，MVP 最小可行产品理论，主张只保留核心功能快速上线迭代，这和书中 “足够好” 思想很接近。但是 MVP 有真实用户反馈作为判断依据。
根据我的实践经验：在之前课程写小软件 demo 的时候，我经常陷入纠结：还有一堆小 bug、次要功能还没做完，我不知道该不该提交。我既担心提交太早质量太差，又害怕无限拖延，总想把所有功能做完再交。老师打分又是看完整度与 bug 多少，和工业界 “足够好” 的判断逻辑不一样。

我的困惑：工业界可以靠用户、市场来判断 “足够好”；那学生课程项目没有真实用户，该如何平衡 “尽早发布迭代” 和课程作业的质量评分要求？学生项目的 “足够好” 标准到底是什么？

问题二：第 2 章 个人技术和流程 2.1 单元测试

引用书中原文：“单元测试必须由最熟悉代码的人（程序的作者）来写。”

我有这个问题：代码作者写单元测试，很容易陷入 “按照自己的思路去写测试用例”，很难想到自己思维盲区里的异常输入，容易写出 “只能通过正确案例，测不出边界错误” 的单元测试。那是否完全不可以交给别人写单元测试？

我查阅网上开发资料，很多大型企业有专门的测试工程师，会独立写测试案例，不完全由开发本人写全部单元测试。
我的实践经验：自己写练习代码，写单元测试的时候，我大多只会测试正常输入，经常漏掉非法参数、空输入这些边界情况；如果同学来阅读我的代码，反而更容易找出我没有考虑到的场景。

我的困惑：书中强调单元测试必须由代码作者写，但是开发者容易思维固化，存在盲点。那么单元测试的主要负责人是开发者，那外部人员写测试用例应该放在什么样的位置？学生练习单元测试的时候，该如何克服自己思维盲区带来的测试用例不全问题？

问题三：第 6 章 敏捷流程 6.2 敏捷开发的原则

引用书中原文：敏捷流程依靠燃尽图来展示剩余工作量，要求团队对任务工作量进行估算。

我有这个问题：敏捷开发非常依赖团队对任务工时的准确估算，但是对于像我们这样缺少项目实战经验的学生，经常严重低估任务难度，预估工时和实际耗时差距巨大。当学生团队估算完全失准时，敏捷的燃尽图是否还有参考价值？

我查阅资料了解，敏捷里面有故事点，不完全以小时为单位做估算，允许团队根据历史速度调整。
我的实践经验：课程小组作业，我们一开始预估一个功能两天做完，实际写代码加调试花了五天，燃尽图直接完全失真。

我的困惑：敏捷很多实践建立在团队有大量项目历史数据的前提下。对于几乎没有项目历史参考的学生新手团队，如果工时估算大面积出错，我们还能不能照搬敏捷、燃尽图这套工具？学生做敏捷项目的时候要做哪些修改适配？

问题四：第 16 章 IT 行业的创新 16.2 创新的迷思

引用书中原文：迷思四：成功的团队更能创新。书中解释：成功团队拥有资源、人才，更容易做持续性创新；但是成功的团队往往会忽视颠覆性创新。

我有这个问题：书中说成功团队擅长持续性创新，但是容易被既得利益束缚，很难做颠覆性创新；而小团队更容易做颠覆性创新。那对于普通在校学生，几乎没有资源、没有用户基数，想要做颠覆性创新，除了想法之外，最缺少的条件是什么？仅仅依靠想法是否足够产生真正有价值的颠覆性创新？

查阅相关互联网案例：很多颠覆性创新并不是凭空来自小团队的灵光一闪，也需要基础技术积累，很多小团队有好想法，但是受限于算力、资金、流量，最后难以落地。
我的间接经验：看到很多学生课程项目有很新颖的点子，但是仅仅停留在 demo 原型，没有办法真正变成可以面向大量用户使用的产品。

我的困惑：学生很容易产生很多新奇想法（颠覆性想法），但是绝大多数只停留在 demo。如果小团队想法很好，但是缺少资源，那么颠覆性创新是不是仅仅只能停留在原型阶段？对于学生来说，我们应该优先打磨持续性改进，还是去追求颠覆性创新？

问题五：第 17 章 人，绩效和职业道德 17.2 团队的绩效
引用书中原文：书中提到不建议单纯用代码行数衡量工程师的工作绩效，代码行数多不代表产出价值高。

我有这个问题：既然代码行数不能作为绩效衡量标准，那对于学生课程软件工程团队项目，我们没有商业收入、没有真实用户数据，我们用什么客观指标来评价每个团队成员的贡献？

查阅资料，工业界可以看需求交付、bug 修复、用户反馈。但是学生课程项目没有真实用户。
我的实践经验：小组作业经常遇到情况：有的人写大量模板脚手架代码，行数很高，但是业务价值有限；有的人重构精简代码，代码行数变少，但是极大提升可维护性；还有同学主要做文档、需求调研，几乎不写代码。如果只看代码行数，会严重低估后两类同学的贡献。课程作业又需要给每个人区分贡献分。

我的困惑：去掉代码行数这个简单指标，在学生课程团队项目中，有哪些简单可落地、可操作的指标，用来客观衡量每个人的贡献？课程中我们该如何避免 “写越多代码分数越高” 的误区？

四 前车之鉴
感想一：读辜新星《时刻调整方向 找到人生的蓝海》
文章链接：[https://book.douban.com/subject/4006425/discussion/22803733/](https://book.douban.com/subject/4006425/discussion/22803733/]()

这篇文章里面提到学长从高年级同学学到ABCD 四象限时间分类方法：
A—— 紧迫且重要；B—— 重要不紧迫；C—— 紧迫不重要；D—— 不重要不紧迫。按照优先级处理事务，在专属的时间段专心处理任务，避免多任务并行带来的低效。
读完这篇我很有共鸣。回顾我自己平时的学习状态，我常常把大量时间消耗在 A 类紧急任务（赶作业、赶截止日期），一直在 “救火”，却挤压了B 类重要但不紧急的事情：比如主动看书拓展技术、练习代码、写博客复盘、预习课程。B 类事情不会立刻有截止压力，所以总被我往后拖，等到临近考试、临近交作业才慌忙补救。

我目前并没有稳定坚持 ABCD 分类的习惯，偶尔会用待办清单记录任务，但很少区分重要与紧急。看完辜新星学长的经历，我意识到真正拉开差距的恰恰是 B 类任务。A 类只是完成最低要求，B 类才是自我提升。

我的反思与改变计划：
以后做每日规划，优先给 B 类重要不紧迫的学习任务分配固定时间，例如软件工程的预习、写代码练习、阅读技术博客，不要等到事情火烧眉毛才动手。减少被 C 类紧急但不重要的琐事抢占精力。同时也要学会舍弃 D 类无意义的消遣，避免看似忙碌实际进步很小。就像文中骑单车的比喻，前进不是车头一直笔直不动，而是时刻不断校正自己的方向。

感想二：读刘帅《在失望中寻找希望》

文章链接：[https://book.douban.com/subject/4006425/discussion/22803961/](https://book.douban.com/subject/4006425/discussion/22803961/]()

文中刘帅学长的经历让我印象很深：虽然是计算机科班学生，考试成绩不错，拿过奖学金，但是感觉自己并没有真正学懂计算机。上课只是机械听课、完成作业，缺少主动思考和动手实践；很多课程仅仅停留在纸面理论，缺少动手编码训练。即使考试得分高，遇到真实项目、面试底层问题的时候，就暴露出来 “知其然，不知其所以然” 的短板。旁听朱仲涛老师的数据结构课之后，才意识到计算机课程不是纸上的数学题，而是要动手写代码、理解背后整套逻辑。

我看到这段描述的时候，感觉在说部分阶段的自己。很多专业课我可以看懂课本、完成课后习题，考试可以拿到还不错的分数，可是让我自己从零动手实现一个算法或者小模块，就会卡顿。很多知识停留在记忆层面，没有转化为实践能力。

学长的教训对我的启发有两点：

1. 科班身份不等于真正懂计算机。考试分数只是一部分评判标准，动手实践、主动追问 “为什么” 更加关键。不能满足于听懂课、做完书面作业。上完一门课要反问自己：能不能动手实现？能不能讲清楚底层原理？
2. 不能被动等待老师把所有知识喂给自己。如果课堂讲授偏向理论，自己要主动补齐实践环节。不能机械记忆答案，要训练独立思考，多动手敲代码，多追问原理，否则哪怕拿了奖学金，遇到真实项目和面试也会碰壁。

结合软件工程这门课，我提醒自己：不能只背课本上软件工程名词，要借着课程的个人、结对、团队项目，强迫自己动手，把理论落实到代码、文档、测试中，避免走上 “科班但没学懂计算机” 的老路。

Github作业：https://github.com/Duan-12345/Duan-12345