软件工程第一周作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/CSgrade2026
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/CSgrade2026/homework/51710
这个作业的目标	完成一篇完整的个人博客，包含自我介绍、现状分析、课程计划、阅读提问和前人心得，同时练习 Markdown 排版与 GitHub 基础操作。

1. 介绍自己，建博客

大家好，我是刘旭波，目前就读于广东工业大学计算机科学与技术专业。

选择通过博客园来记录自己的学习历程，是因为我认同"写作本身就是一种有效的思考整理方式"。虽然写博客确实很花时间，但我愿意先坚持一段时间，看看自己在表达能力和技术理解上能否有进步。

说到闪光点，说实话，我认真想了一下，觉得自己确实没有什么特别突出的才艺或特长——不会乐器、不擅长运动、没有参加过演讲比赛，也没有拿过什么竞赛奖项。但我觉得这本身也是一种真实的起点：承认自己的普通，然后脚踏实地去积累。我相信大多数同学也和我一样，是在平凡中慢慢成长的。如果说有什么值得分享的，那就是我遇到不懂的问题会愿意花时间去查、去试，虽然进度不快，但能保持向前走。

关于做作业的底线，我的态度是：不抄袭、不敷衍，能保证及格的部分一定做到，超出能力范围的会尽力去学，但如果实在做不完，也不会硬撑到崩溃——至少把能拿的分拿到。

2. 现状、经验和计划

（1）专业选择与技能差距

我选择计算机科学与技术专业的原因，其实没有太多戏剧性——高考分数到了这个线，计算机又是热门专业，家人也觉得出来好就业，就填了。进来之后发现确实不讨厌写代码，甚至有时候调通一个程序还挺有成就感，就这么读下来了。

对照行业技能要求，我从中抽取了以下 5 项我认为对我特别重要的技能，并给自己做了一个现状评估和目标设定：

技能项 ①当前水平 (0-9) ②期望水平 (0-9) ③提升手段
算法与数据结构 4 7 刷力扣，每周至少 3 道题，整理错题笔记
前端三件套（HTML/CSS/JS） 6 8 做实际项目，遇到问题问 AI 并理解其思路
React 框架 4 7 跟着项目练，结合 AI 辅助学习，逐步减少对 AI 的依赖
Node.js 3 7 从简单后端项目做起，配合 AI 边学边做
Java 4 8 做项目为主，遇到问题问 AI 并深究原理

我计划通过以下 5 种手段来提高这些技能水平：

① 以项目驱动学习——不单独学语言，而是直接拿一个小项目练手，在实战中掌握技能。

② 善用 AI 辅助——遇到问题先问 AI，但要求自己理解每一行代码的含义，而不是直接复制粘贴。

③ 定期复盘总结——把学到的知识点写成笔记或博客，巩固记忆。

④ 利用力扣保持手感——每周保持 3-5 道题的练习量，维持对算法和数据结构的敏感度。

⑤ 扩展技术视野——关注行业动态，了解新技术，避免只盯着课内那点东西。

（2）阅读心得

a）为何要来上课并且认真参与

我读了参考材料中那位学生的思考，深有感触。大学课堂对我来说，最大的价值不在于老师讲得多好，而在于它提供了一个结构化的学习环境和时间框架。如果完全自学，我很可能因为没有外部约束而无限期拖延。上课至少保证了我每周有固定的时间在接触专业知识，这是一个底线。认真参与是对自己时间的尊重——既然坐在教室里了，听一点是一点，总比刷手机强。

b）师生关系与困难应对

在过去的学习中，我体验的是典型的大学散养式师生关系——上课见一面，下课各走各的，老师基本不主动管你，全靠自己自觉。对于这门课，我希望建立的是健身/教练式的关系——老师给出明确的目标和训练计划，我主动练习、主动反馈，双方共同为"我的成长"负责。

如果老师布置的作业对我来说有些困难，我的选择是：D——只做到能保证及格的部分，其他都放弃。

我的具体做法是：先把作业拆解一遍，识别出哪些是基础分、哪些是加分项。优先保证基础部分全部完成且正确率 ok，加分项或者特别难的部分，如果花了时间还是搞不定，就不死磕了，把精力留给其他科目。毕竟精力有限，要懂得取舍。

c）引用、参考与抄袭的区别

经过阅读相关文章和了解学校规定，我理解的核心区别在于：是否标明来源、是否将他人的成果当作自己的原创。

• 引用/参考：在别人成果的基础上继续开发，明确注明出处，用自己的语言重新表达或做增量贡献。这在学术和工程中都是正常的合作方式，比如我们写代码时用开源库、参考 Stack Overflow 上的解法，只要注明来源就是合理使用。
• 抄袭/剽窃：直接复制粘贴他人的文字、代码、设计而不加任何说明，或仅做微小改动就声称是自己的成果。这属于学术不端，严重的话会被开除或取消学位。

在本课程中，我会遵守"可借鉴思路、可参考公开代码、但必须注明来源"的原则，个人作业独立完成，不直接复制他人代码。

（3）未来规划与优劣势分析

几年后，我的选择是：考公务员。

这是我经过比较长时间考虑后做的决定。相比互联网公司的高压节奏和快速迭代，我更倾向于稳定、可预期的工作环境。当然，考公也不是退路，竞争同样激烈，需要认真准备。

选择这条道路后，我相比其他同学的优势在于：

• 做题水平还可以，笔试的行测和申论需要一定的逻辑和写作能力，这方面我不算一窍不通，有一定的底子。
• 对计算机专业知识的理解比纯文科考生要好，在一些技术岗的竞争中可能有一些优势。

劣势可能在于：

• 自控力没那么好，能不能坚持每天按计划复习是一个很大的未知数。
• 开发技能不够深入，万一考公失利，想转头找技术类工作，竞争力可能不如专心做项目的同学。

针对这个选择，我本学期的具体规划是：

• 学业上：保证课程不挂科，成绩至少混到中等水平，不影响毕业。
• 技能上：继续学习考试相关内容（行测、申论），同时兼顾开发技能，防止将来技术太差连保底工作都找不到。
• 软实力上：多了解国家政策相关知识和传统文化知识，扩展知识面，这对申论和面试都有帮助。

（4）本课程计划与代码量

我对这门课程的期待是：不要太理论化，多一些实践环节，让我能真正体验一次相对完整的软件项目流程，而不是背书应付考试。参考美国本科和中国软件工程的教学案例，我希望能有团队协作的机会，哪怕是模拟的也好。

我打算这样度过这门课程：课前简单翻一下课件，课上尽量跟着听，课后作业尽力完成。能跟就跟，跟不上至少保证及格。

关于助教，我的想法是：暂时不想当——自认技术水平和时间精力都有限，当助教怕误人子弟。

当前代码量：

• JavaScript（含前端框架）：约 1500 行
• Java：约 1000 行
• C/C++：约 500 行
• 总计约 3000 行

关于"入职需要多少代码量"这个问题，我的看法是：现在是 AI 时代，手敲代码的恐怕没有多少了，所以无法简单地用代码行数来量化能力。 重要的不是你写过多少行，而是你理解多少、能设计多少、能调试多少。当然，纯从门槛来说，要入职一流的软件/互联网公司，至少得有 1 万行以上的有效代码经验；从事高校教学科研工作，则更看重论文和理论深度，但代码量最好也不低于 5000 行。

我计划平均每周拿出 8 小时（含上课时间）用在这门课上。

关于投入态度，我选择 A：刚才是随便说说的，我打算混过这门课。

这不是消极躺平，而是一种诚实的自我定位——我知道自己精力有限，考公才是主线任务，这门课我尽力做到不挂科、能及格就行。与其骗自己说"我要发奋图强"，不如坦诚地分配好时间。

在本课程结束时，我计划完成代码量视作业多少而定，作业多就多写，作业少就少写，不给自己定硬性指标。

WOOP 计划

• W（Wish/愿望）：在这门课中顺利通过，不挂科，同时保持考公复习的节奏不受太大影响。
• O（Outcome/结果）：如果实现了，我可以平稳地度过这个学期，既拿到了学分，又没有耽误主线任务，心态会比较从容。
• O（Obstacles/障碍）：
  • 内部障碍：容易分心，刷手机停不下来，学习时经常走神。
  • 外部障碍：多门课程作业同时压过来，时间不够用。
  • 最可能导致我失败的因素是：拖延——总觉得时间还多，结果拖到最后一刻才开始赶。
• P（Plan/风险防范）：
  • 如果 我在学习时忍不住刷手机，那么 我就立刻关闭娱乐软件，先完成手头的东西再休息，把学习任务拆成小块，做完一块才能看手机。
  • 如果 多门课程任务冲突，那么 我就做好任务优先级排序，拆解为每日小目标，按紧急程度一件件完成，不贪多。
  • 如果 某个周末完全不想动，那么 我就只做最小的事——比如打开电脑看 10 分钟课件，一旦开始了，往往就能继续下去。

3. 提有质量的问题（基于《构建之法》）

我快速阅读了《构建之法》的部分章节，以下是我的 5 个问题：

问题 1（第 1 章 概论 1.3 软件工程目标：足够好的软件）

书中提到：软件工程的目标，是在约束条件下做出"足够好"的软件，而不是无限追求完美。

我有这个问题：如何判断软件已经达到"足够好"？ 我担心自己会走向两种极端——一种是不断加功能导致无限延期，另一种是仓促上线留下大量隐患。

我查了资料，发现 MoSCoW 优先级方法可以划分"必须、应该、可以、暂不做"的需求，MVP（最小可行产品）思想也强调优先交付核心功能。根据我的实践，我之前构思过一些小工具，总是想一次性做完全部功能，结果项目还没开始就胎死腹中了。

但我还是不太懂：针对课程级别的小型项目，"足够好"的量化标准应该怎么设定？ 比如，是功能完整度达到 80%？还是核心流程能跑通就算？有没有一个简单的判断框架？

问题 2（第 2 章 敏捷开发 2.1 敏捷原则）

书中提到：敏捷强调可用的软件高于完备的文档，个体和互动高于流程和工具。

我有这个问题：新手团队如果过度弱化文档，会不会导致后续维护困难、交接成本高？ 我在小组合作中见过这种情况——代码写完了，但没人知道整个系统是怎么设计的，改一个 bug 要花半天时间读代码。

我查了资料，发现敏捷并不是不要文档，而是拒绝冗余文档，提倡"刚好够用"的文档。根据我的实践，我自己写代码也不爱写注释和文档，过一个月回看时经常看不懂当初的思路。

但我还是不太懂：在单人课程项目里，敏捷流程是否还需要保留需求说明、架构设计这类基础文档？ 还是说一个人做就不需要这些了？

问题 3（第 13 章 软件测试 13.1 单元测试）

书中提到：单元测试由代码作者编写，用来验证模块逻辑正确性，是质量保障的基础。

我有这个问题：当项目工期紧张时，单元测试的优先级是否可以降低？ 我身边很多同学觉得写单元测试性价比低，不如多做几次手工功能测试来得直接。

我查了资料，很多企业实践表明，前期的单元测试能大幅减少后期调试和修复 bug 的总耗时。根据我自己的习惯，我写代码通常是写完直接手动跑一遍，几乎不写单元测试。

但我还是不太懂：对于小型后端工具项目，单元测试覆盖到什么程度就算够用了？ 是核心函数全覆盖，还是关键路径覆盖即可？

问题 4（第 16 章 IT 行业的创新 16.1 创新的迷思之五）

书中提到一个迷思：要成为领域专家，才能创新；事实是 70% 的创新来自本领域之外。

我有这个问题：作为技术基础不够深厚的学生，如果想依托自己的兴趣（比如游戏）做一些小工具创新，会不会因为技术能力不足而限制创意的落地？

我查了资料，很多成功的工具类产品，创新点不在于底层技术的突破，而在于挖掘了用户未被满足的需求。根据我的实践，我在玩游戏或看直播时确实能发现一些玩家的痛点，但经常因为代码能力不够而没法实现。

但我还是不太懂：这种偏需求层面的创新，如何评估它是否属于软件工程意义上"有效"的创新？ 还是说，只有技术实现出来了才算数？

问题 5（第 8 章 需求分析 8.2 Kano 模型）

书中介绍了 Kano 模型，把需求分为基础需求、期望需求和兴奋需求三类。

我有这个问题：面向游戏玩家的工具类产品，怎么快速区分哪些是玩家真正需要的基础功能，哪些只是他们一时兴起提的花哨想法？

我查了资料，可以通过问卷、用户访谈来收集反馈进行分类。根据我的实践，我在直播互动中经常收到观众提的各种功能建议，很多听起来很酷，但很难判断是不是真的有必要做。

但我还是不太懂：用户的主观喜好波动很大，Kano 模型在小众玩家群体里会不会失效？ 如果样本量不够大，分类结果是不是就没有参考价值了？

关于课程反馈，我的态度是 C：有问题就问，至少一学期提三个问题，认真按时填写反馈。 既然老师要求了，我就按要求做，不抵触。

---

4. 前车之鉴

我阅读了以下参考文章，写下我的具体感想：

文章一：刘帅《在失望中寻找希望》

原文链接https://book.douban.com/subject/4006425/discussion/22803961/

读这篇文章时，有好几处我都觉得"这不就是我吗"。

作者说自己是科班出身，学过数据结构、编译原理、操作系统，但"却没有学懂计算机"。我现在的状态几乎一模一样——这些课我都上过，考试也过了，但你让我说清楚"一个程序从源代码到运行到底经历了什么"，我可能讲不到三句话就卡住了。

作者反思自己本科时的学习方式：只学上课讲的那点知识，作业按老师给的模式套，从不主动思考。 这太真实了。我自己很多时候也是这样——作业能交就行，考试能过就行，很少去想"为什么要这么做""还有没有更好的方法"。

他提到在清华旁听朱仲涛老师的数据结构课时受到震撼："朱老师用 1/5 的时间简述内容，剩下 4/5 的时间当场写程序，从 0 开始实现算法，写完一个编译错误都没有，全班鼓掌两分钟。" 读到这里我既羡慕又惭愧——我的数据结构老师上课是照着 PPT 念概念和伪代码，我从来没有见过一个算法是如何从零写出来并跑通的。

这篇文章给我的启发是：不要等老师来教你"怎么学"，老师不教就自己去找资源，网上有太多优秀的公开课和教程了。 另外，作者提到"出来混，总是要还的，你不会的知识，总会在一个必要的时候提醒你、惩罚你"，这句话我要记下来。

文章二：《一直在路上——记我从初中到本科近十年的学习成长历程》

原文链接https://www.cnblogs.com/xiaozhi_5638/p/4485805.html

这篇文章的作者从农村走出来，本科读的是二本院校的软件工程专业，但通过自己的努力一步步成长，后来还创业了。读完之后有几个点让我印象很深。

第一，他在大一下学期就意识到"注重实践"的重要性。 当别人还在图书馆背概念的时候，他已经开始把课本上的例子一个个敲到电脑里运行了。反观我自己，很多时候还是"眼高手低"——觉得看懂了，一动手就卡住。

第二，他讲到"基本功的重要性"。 他说很多同学理解不了链表，根本原因是大一的指针没学好，基础不扎实。这让我反思：我是不是也经常在基础没打牢的情况下就去追"高级"的东西？比如 React 还没搞懂生命周期就开始学 Redux，结果两头都不扎实。

第三，他讲到英语和眼界的重要性。 他说很多问题用中文搜不到答案，换成英文关键词在 Google 上搜就能找到。我自己的经历也验证了这一点——很多报错信息直接复制到百度搜不出东西，换成英文搜 Stack Overflow 就有答案了。

不过我和作者不同的是，他说他"对编程有浓厚的兴趣"，而我其实说不上有多热爱编程——不讨厌，但也没到废寝忘食的程度。这让我有点担心：是不是只有真正热爱的人才能走远？ 但转念一想，能把自己的事情认真做好，或许比"热爱"本身更重要。

---

GitHub 仓库

我的 GitHub 仓库地址：LiuBoo0785/LiuBoo0785

README 中已包含个人介绍，截图如下：

博客园后台编辑器设置截图