第一周作业

第一周作业 —— 我与软件工程的初次见面

这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/
这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标 建立博客与 GitHub 仓库，练习 Markdown 排版；通过自我介绍、技能盘点与计划制定认清现状；通过阅读《构建之法》提出有质量的问题；通过阅读前人博客吸取经验，为后续软件工程学习奠定基础。

一、准备工作

  • GitHub 账号：已注册，ID 为 Jiyue0321，仓库地址：https://github.com/Jiyue0321/Jiyue0321
  • 博客园账号：已开通个人技术博客，博客名 Jiyue2222，默认编辑器已切换为 Markdown
  • 加入班级博客：已加入 "[计科24级56班（广东工业大学-计算机学院）]" 班级博客。

以下是 GitHub 仓库 README 的自我介绍截图：

b522ec6fcc36b291d6ce991476c4329e

以下是博客园后台编辑界面截图（Markdown 模式）：

image

二、正文

1. 介绍自己，建博客

你好，我是苏炜康，一名刚刚步入大三的计算机科学与技术专业的学生。在过去的两年里，我修读了 C语言程序设计、Java程序设计、数据结构、操作系统、计算机网络、数据库等专业基础课，也做过一些课程小项目，但代码量还远远不够，工程化经验也几近于零。开这篇博客，主要是想逼自己把"学过"的东西"写出来"——能把一件事讲清楚，才算真的懂了。

关于为什么要写博客，我是这样想的：写博客是一种"复利"式的学习方式。第一次写一个知识点可能要花两三个小时，但写完之后，下次再用就是一秒钟的事；而且写出来的东西会被别人看到，会被搜索到，会有反馈，这种"被看见"的压力会逼着自己把细节抠清楚。

至于闪光点，我想说一点不算本事但对我帮助很大的事——我喜欢研究游戏《我的世界》里的命令和电路体系，通过游戏里虚构的“命令方块”和“红石”电路，激发了我那"想知道里面到底是怎么运作"的好奇心，一路把我带到了计算机专业。此外，小学时，为了参加一个比赛，我还曾在英语的阅读、单词记忆这些东西上面下了点功夫，最后花了几个月时间拿到了一个省级奖项。这些经历让我明白一个道理：所谓天赋，大多只是愿意在上面花时间而已。我希望把这种耐心迁移到软件工程的学习上来。

2. 现状、经验和计划

（1）专业技能盘点

我大致阅读了《2026 AI-Native 工程师实战能力评估标准》的 4 大维度、9 项子能力框架。这套标准把工程师能力分为 L1（理论认知）→ L2（独立实践）→ L3（一人全栈）→ L4（团队基石）→ L5（领导者） 五个等级，每一级都附有"开源取证"的具体判断依据（如 Commit 粒度、测试覆盖率、PR 内容等），比单纯的 0-9 分更具体、也更难自我欺骗。

为满足作业的 0-9 分要求，我把 L1-L5 映射为：L1≈2、L2≈4、L3≈5-6（"能通过面试"的门槛）、L4≈7-8、L5≈9。

作为一个刚进入大三、还没有真正实习经验的学生，我从 9 项中挑选了对现阶段最关键的 6 项，列出当前水平、本课程结束后的期望水平，以及至少 5 项提升手段：

维度 技能项 目前水平（L/数字） 课程结束后期望 提高手段（≥5 项）
维度一·规格实现 1. 需求对齐与代码健康度 L1（2/9）：代码能跑通 Happy Path，但单个文件常超 500 行、死代码堆积、Commit 消息模糊、PR 无 Diff 审查 L3（5/9）：主动重构 AI 生成代码，使用强类型，模块化拆分 ① 给每个新项目配 ESLint/Pylint 并保持零警告；② 学习并实践《代码整洁之道》的函数拆分原则；③ 强制写规范的 Commit Message（Conventional Commits）；④ 每次提交前自查未使用的 Import 和死代码；⑤ 在 Code Review 中给同学挑结构问题，也请别人 Review 我的代码）
维度一·规格实现 2. 验证深度与测试覆盖 L1（1/9）：几乎不写测试，依赖手动点击验证，tests/ 目录缺失 L2（4/9）：建立标准单元测试，覆盖率 > 60%，断言能验证返回数据结构 ① 系统学习 JUnit/PyTest 基本用法；② 给现有课程项目补测试，从最核心的函数开始
维度一·规格实现 3. 工程复现性与构建完整度 L1（2/9）：依赖本地绝对路径、依赖版本未锁定，换台机器就跑不起来 L2（4/9）：提供 README + 依赖锁定 + .env.example，按文档命令能成功启动 ① 给所有已有项目补齐 README 模板（Install/Usage 章节）；② 锁定依赖版本（package-lock.json / requirements.txt 带版本号）；③ 学习 Docker 基础，给项目写 Dockerfile；④ 实践 docker-compose 一键拉起开发环境；⑤ 在另一台机器（或同学电脑）上测试项目可复现性；⑥ 学习 .env.example 的规范写法
维度四·工程底座 9. 手动掌控力与底层原理 L2（3/9）：脱离 AI 能写简单业务逻辑，但跨栈排查能力弱，看不懂复杂堆栈 L3（5/9）：独立排查跨前端/后端/DB 的问题，能手动修正 AI 生成代码中的逻辑漏洞 ① 重做数据结构与算法经典题，刻意禁用 AI；② 系统学习操作系统、计算机网络核心原理，不止于"会用"
维度三·AI 工程 6. 智能体编排与工具使用 L1（2/9）：只会拼接 Prompt 字符串，无结构化控制流，无错误处理 L2（4/9）：正确集成 LLM SDK，处理基本交互与重试，结构化日志 ① 系统学习 LangChain/LangGraph 框架；② 给一个课程项目加 AI 助手模块；③ 学习结构化日志记录 Prompt/Response；④ 实现简单的 Retry 逻辑和 JSON 解析容错；⑤ 阅读 Anthropic / OpenAI 官方文档的最佳实践；⑥ 学习 Tool Use / Function Calling 的设计模式
维度四·工程底座 8. 开源杠杆与社区贡献 L1（1/9）：只有课程作业仓库，依赖版本不锁，README 缺失 L2（3/9）：规范引入开源库，README 基本合格，引用代码注明出处 ① 把个人 GitHub 仓库整理一遍，补齐 README；② 锁定所有依赖版本；③ 给一个喜欢的开源项目提一次 PR（哪怕只是修文档错别字）；④ 学习 Git 进阶操作（rebase、cherry-pick、子模块）；⑤ 在博客上记录踩坑过程；⑥ 维护本课程作业仓库，保持绿色格子墙

未列入的 3 项说明：云原生部署与资源优化（4）、遗留系统现代化（5）、自动化进化闭环与数据飞轮（7）——这三项对一个刚进入大三、还没真正实习过的学生而言，目前接触机会较少（没碰过 K8s、没维护过遗留系统、没做过 AI 数据飞轮）。当前阶段，我想先把"维度一·规格实现"和"维度四·手动掌控力"打扎实。

（2）阅读心得

a) 为什么来上课并认真参与？

大学课堂和中学不一样，老师不会盯着你做作业，但这也意味着每一节课都是"自愿的"。我之所以还愿意来上课，不是因为点名，而是因为：

  1. 课堂上有老师"当场讲清楚"的机会，这是看视频无法替代的——视频可以暂停，但视频不会回答你的追问，而仅仅通过类似b站视频的弹幕和评论区也不一定能解答自己的问题。
  2. 同学在课堂上提出的问题，常常是我没想到但同样不懂的问题。
  3. 一些"隐性知识"（比如老师讲到某个坑时顺嘴提一句"我当时踩了这个坑"），并不会写进 PPT，而是只会出现在课堂里。

b) 师生关系与作业态度

我在大学里体验到的师生关系更接近"井水不犯河水"——老师讲完就走，学生下课就散，彼此不深交。但我希望这门课能是另一种关系：教练与学员的关系——老师像健身教练一样指出我动作哪里不对，我像学员一样愿意被指出问题。

如果老师布置的作业对我来说有些困难，我会选择 C：向老师和同学请教，花更多时间，把作业全部完成。

c) 引用与抄袭的区别

在工作中，引用文献、参考开源代码、在别人基础上继续开发是常态；而抄袭、剽窃是把别人的东西"伪装成自己的"。两者的核心区别有三点：

  1. 是否声明来源：引用会明确标注出处，抄袭会刻意隐瞒。
  2. 是否理解并消化：引用是在理解原作基础上的二次创造，抄袭是复制粘贴。
  3. 是否获得了"不该获得的利益"： 如果通过抄袭拿到了学分、学位、工作 offer，那就是对其他诚实付出者的不公平。

在本课程中，我会遵守学校对抄袭的处理规定，参考任何资料都会注明出处，代码会写明哪些部分借鉴了何处。至于"看了别人的代码之后自己重写"算不算抄袭——我认为如果能脱离原代码独立写出，并且理解每一行在做什么，那就是学习；如果不能，那就是抄。

（3）未来的选择与本学期规划

几年后，我倾向于 从事软件研发工作，不排除读研深造的可能。

对照前人的经历，我选择的是一条"工程实践 + 持续学习"的路。相比走学术路线的同学，我的优势是动手意愿强、不怕从零搭环境；劣势是理论功底不够厚，遇到数学密集型的问题容易绕着走。

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

  • 认真完成软件工程课程的所有作业，包括个人项目与团队项目；
  • 把团队项目当作"一次小实习"来对待，走完需求、设计、编码、测试、发布全流程；
  • 每周固定时间刷算法题，保持手感；
  • 读一下《构建之法》这本书。

（4）本课程的具体计划

我对这门课的期待是：走出"写完能跑就行"的阶段，进入"写得好、测得住、改得动"的阶段。我希望课程结束时，我能：

  • 熟练使用 Git 进行团队协作；
  • 写出带单元测试、有合理抽象的项目；
  • 体验一次完整的软件工程流程，理解每一阶段的意义。

当前代码量估算：

语言 代码量（行）
C/C++ 约 4000
Java 约 2000
Python 约 1500
合计 约 7500

目标代码量：

  • 入职一流软件/互联网/AI 公司：通常需要 5 万行以上的有效代码积累（不含自动生成、不含复制粘贴）。
  • 从事高校教学科研工作：代码量不是核心指标，但至少要有 1-2 个完整的研究型项目，理解从问题定义到论文产出的全过程。

本课程结束时计划完成的代码量： 约 3000-5000 行有效代码（个人 + 团队项目合计）。按 16 周计算，平均每周约 200-300 行。

每周投入时间： 我选择 C：比以前的课稍多一些。预计每周投入 10-12 小时（含上课时间）。

（5）WOOP 计划

Wish / 愿望：在软件工程课程结束时，我希望能独立完成一个有完整工程实践的小项目，代码质量"拿得出手"，能在简历上写一笔。

Outcome / 结果：如果这个愿望实现，我会感受到——

  • 第一次看到自己写的项目有完整的 CI、测试、文档；
  • 第一次在 GitHub 上有一个像样的绿色格子墙；
  • 第一次能在一个不懂技术的亲戚面前，把"我做了个什么东西"讲清楚；

Obstacles / 障碍：

  • 内部障碍：注意力容易被分散，打开电脑准备写代码，结果半小时后发现自己在刷视频；遇到 bug 排不出来时会焦虑、想放弃；计划做得太满，做不到就全盘放弃。
  • 外部障碍：其他课程作业挤压时间；遇到期末考试周，软件工程会被牺牲掉。

最可能的失败因素："完美主义 + 拖延"的组合拳——想做得很完美，结果迟迟不动手，最后期限临近时仓促交差，质量反而很差。

Plan / 风险防范（if-then）：

  1. 如果我打开电脑 10 分钟内还没开始写代码，那么我就把手机放进抽屉，关掉浏览器，只留编辑器和终端。
  2. 如果我遇到一个 bug 卡了 40 分钟还没头绪，那么我就站起来先去做点别的事情，有时候稍微放松一下说不定会想到别的方向。实在想不到就去搜索相关内容或者向其他人询问。
  3. 如果某周计划没完成，那么我不把剩下的任务堆到下周，而是当周周末补完，避免"滚雪球"。
  4. 如果团队项目里有人长期不响应，那么我先私下沟通一次；若仍无改善，就主动找老师/助教反馈，而不是自己闷头代劳。

3. 提有质量的问题

我快速阅读了《构建之法》（邹欣著）一书，下面是 5 个我读完之后仍未完全理解、或有所保留的问题。

问题 1：PSP 的数据收集，会不会反而让开发者"为指标而工作"？

我看了这一段文字（《构建之法》第 1 章 1.3 节"工程师的必备技能"与第 2 章关于 PSP 的内容）：

"PSP（Personal Software Process）要求工程师记录自己每一项活动的时间、缺陷数、规模估计等数据，以此为基础进行自我改进。"

我有这个问题：当工程师知道自己的数据会被记录甚至被上级查看时，是否会不自觉地优化数据本身，而不是优化工程效果？ 比如为了降低"缺陷率"而少写复杂代码、为了提高"代码行数"而写冗余实现。

问题 2：单元测试的"成本/收益"边界到底在哪里？

我看了这一段文字（第 2 章 2.1 节"单元测试"、2.2 节"回归测试"）：

"一个好的单元测试应该覆盖核心功能、边界条件、错误处理路径。"

我有这个问题：对一个"原型阶段、需求还在剧烈变化"的项目，写完整的单元测试是否反而会成为负担？ 因为需求一变，测试也得跟着重写。

根据我的实践，我之前写过一个课程项目，前期写了大量单元测试，后来老师改了需求，半个测试套件都红了，最后我把测试全删了重写，反而比直接改代码还慢。

我反对"任何代码都要有 100% 单元测试覆盖"这种绝对观点。我的理由是：对于一次性脚本、对于极可能被丢弃的原型、对于一些单纯用于展示的 UI 代码，单元测试的边际收益低于其维护成本。 但我不确定这条线该画在哪里，希望老师在课上能讲讲。

问题 3：结对编程在"水平差距大"的两人组里是否仍然有效？

我看了这一段文字（第 4 章 4.5 节"两人合作：结对编程"）：

"结对编程中，驾驶员负责具体编码，领航员负责审查和思考下一步，两人定期互换角色。"

我有这个问题：如果两人的水平差距较大（例如一个有 3 年经验，一个刚开始学），结对编程会不会退化为'高手在讲，新手在抄'？ 这种情况下，是结对编程更有价值，还是各自分工更有效率？

问题 4：敏捷开发中"用户故事"的颗粒度如何把控？

我看了这一段文字（第 5 章 5.2 节"敏捷开发"、第 6 章"用户场景"）：

"用户故事应该是可估算、可测试、能在一次迭代内完成的小块需求。"

我有这个问题："一次迭代内可完成"这个标准在学生团队里非常模糊——学生团队迭代周期可能是 1 周，也可能是 2 周；学生水平也参差。怎么判断一个用户故事是不是"切得太碎"或"太大"？

根据我的实践，我做课程项目时，倾向于把用户故事写得很"产品经理化"——一句话描述用户能做什么，但背后藏着 3 天的工作量，导致估算严重失误。

我的困惑是：有没有一些"经验法则"可以让新手快速判断一个用户故事的颗粒度是否合适？例如"如果一个用户故事里出现'并且'，就拆开"，这种？

问题 5：软件工程师的"创新"，和科研的"创新"，是不是两码事？

我看了这一段文字（第 16 章"创新"）：

"创新不是凭空产生，而是建立在深刻理解现有问题的基础上；同时，创新需要考虑市场需求、工程实现、用户体验等多方面因素。"

我有这个问题：软件工程语境下的"创新"似乎偏向"工程创新 / 产品创新"，而科研中的"创新"更强调"知识创新 / 理论创新"。这两种创新对工程师的能力要求是否相同？

认真反馈的选择：我选择 C：有问题就问，至少一学期提三个问题，认真按时填写反馈。理由：老师改进教学需要真实信号，敷衍的反馈既浪费自己时间，也误导老师。

4. 前车之鉴

我从前面的参考博客列表中选取了以下 2 篇进行阅读和反思。

阅读 1：《偏科生自学摸索的道路》

这篇博客的作者作为一个"偏科生"，靠自学走出了一条路。让我印象最深的是他对"实习经验"的看重——他说实习是应届生求职时最重要的差异化优势之一。

我的感想：
我之前一直有一个误区：以为"先把专业课学完、绩点拉高，再去实习"是顺理成章的路径。但看完这篇我意识到，实习和课堂学习是两条平行的赛道，不是先后关系。课堂教的是"体系"，实习教的是"工程现实中如何取舍"。一个 G 代码不会写的学生，到了实习岗位可能一周就学会了，但这种"被真实业务推着跑"的体验，是课堂永远给不了的。

针对我自己的情况：大三下或大四上，我应该至少安排一段 3 个月以上的实习，哪怕牺牲一些课程时间。课堂的损失可以补，但实习窗口错过了就真的错过了。

阅读 2：《速成的培训班和打基础的大学教育》

这篇博客讨论了"速成培训班"与"大学基础教育"的差异。作者认为大学教育虽然慢，但打下的基础是长期的竞争力。

我的感想：
这篇文章戳到了我一个长期的纠结："我学的这些课，到底有没有用？" 大一大二我上过操作系统、计算机组成原理，当时觉得枯燥且远离"实际工作"，一度怀疑是不是在浪费时间。

读完这篇文章，我改变了看法。作者举的例子让我意识到：培训班能教"用 Spring Boot 写一个 CRUD"，但教不了"为什么 JVM 会 OOM""为什么这段代码会发生指令重排"。而这些"为什么"，恰恰是在面试高难度岗位、排查复杂线上问题时真正区分人的东西。

所以我接下来的策略是：专业课不满足于"会用"，而要追问"为什么这样设计"。

三、小结

写完这篇随笔，我对自己的现状、目标和路径都有了更清楚的认识。总结成三句话：

  1. 现状：代码量约 7500 行，工程经验薄弱，理论功底不扎实，但还有时间。
  2. 目标：本学期结束前，新增 3000-5000 行有效代码，完成一次完整的软件工程流程，把简历上的"形容词"换成"链接"。
  3. 路径：每周稳定投入 10-12 小时；WOOP 计划已制定，if-then 防范已列出.

GitHub 仓库地址：https://github.com/Jiyue0321/Jiyue0321

博客园博客地址：https://www.cnblogs.com/swk-blog

posted @ 2026-09-05 10:07  Jiyue2222  阅读(12)  评论(0)    收藏  举报