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

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

一、正文

1. 介绍自己，建博客

你好，我是艾力夏提·艾海买提，广东工业大学计算机科学与技术专业的一名大三学生。到目前为止，我学得最多、用得最熟的是 Java，大概写过 2000 行左右的代码，主要是课程作业和小练习。说实话，这个代码量离"合格的程序员"还有不小的距离，很多代码写完也只是"能跑就行"，测试、文档、可维护性这些工程上的东西基本没碰过。开这个博客，就是想给自己一个记录和输出的地方，把学到的东西用自己的话写下来——能讲清楚，才算真的会了。

关于为什么写博客，我的想法很朴素：一是输出倒逼输入，为了把一篇文章写明白，我不得不把细节搞清楚，这比闷头写代码更能暴露自己的知识盲区；二是积累，博客会留下一条看得见的学习轨迹，将来回头翻，能清楚地看到自己是怎么一步步走过来的。

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 项中挑选了对现阶段最关键的 5 项，列出当前水平、本课程结束后的期望水平，以及至少 5 项提升手段：

维度	技能项	目前水平（L/数字）	课程结束后期望	提高手段（≥5 项）
维度一·规格实现	1. 需求对齐与代码健康度	L1（2/9）：代码能跑通 Happy Path，但没有代码规范意识，提交信息随意，没有 Code Review	L2（4/9）：代码结构清晰、命名规范、提交信息有意义，能看懂并维护别人的代码	① 学习并遵守 Java 编码规范（阿里巴巴 Java 开发手册）；② 用 Conventional Commits 规范写提交信息；③ 每写完一个功能自查并删除死代码、无用 import；④ 用 SonarLint 等静态检查插件扫描代码；⑤ 主动请同学 Code Review 我的代码，也主动 Review 别人的代码
维度一·规格实现	2. 验证深度与测试覆盖	L1（1/9）：几乎不写测试，靠手动点击和打印输出验证，tests 目录缺失	L2（3/9）：能用 JUnit 给核心逻辑写单元测试，覆盖主要分支和边界条件	① 系统学习 JUnit 5 的基本用法；② 给本课程项目写单元测试，从最核心的函数开始；③ 学习 Mockito 模拟外部依赖；④ 养成"改完代码先跑测试再提交"的习惯；⑤ 用 JaCoCo 查看覆盖率，逐步提高
维度一·规格实现	3. 工程复现性与构建完整度	L1（1/9）：依赖本机环境，换个机器可能跑不起来，没有 README	L2（3/9）：用 Maven 统一管理依赖并锁定版本，提供 README，按文档能成功启动	① 用 Maven 统一管理依赖并锁定版本；② 每个项目写 README（环境要求、启动步骤）；③ 提交前在干净目录重新 clone 并跑一遍，验证可复现；④ 学习 Git 分支管理，规范开发流程；⑤ 把踩坑过程记录到博客，方便自己和他人复现
维度三·AI 工程	6. 智能体编排与工具使用	L1（2/9）：只会把问题丢给 AI 复制粘贴，不会写结构化提示，也不审查生成代码	L2（4/9）：能用 AI 编程助手提升效率，会写结构化 Prompt，AI 生成的代码必审查、必理解	① 学习使用 AI 编程助手（如 Claude Code、GitHub Copilot）提升开发效率；② 学会写结构化 Prompt（明确角色、输入输出格式、约束）；③ 用 AI 辅助读代码、解释报错，但坚持自己消化理解；④ 尝试用 LLM API 给课程项目加一个小功能；⑤ 养成"AI 生成代码必须逐行 Review"的习惯
维度四·工程底座	9. 手动掌控力与底层原理	L1（2/9）：脱离 AI 只能写简单业务代码，看不懂复杂报错和堆栈信息	L2（4/9）：理解 JVM 内存模型、常用集合的底层实现，能独立排查常见问题	① 每周固定刷算法题，刻意禁用 AI 提示；② 重读《数据结构》，自己动手实现常用结构（链表、哈希表、堆）；③ 深入学习 JVM 内存模型与 GC 机制；④ 系统学习操作系统、计算机网络的核心概念（进程线程、TCP/HTTP）；⑤ 遇到报错先自己排查定位，再求助

未列入的 4 项说明：云原生部署与资源优化（4）、遗留系统现代化（5）、自动化进化闭环与数据飞轮（7）、开源杠杆与社区贡献（8）——这几项对我现阶段来说距离较远（没碰过 K8s、没维护过遗留系统、开源贡献能力也还不够）。当前阶段，我想先把"规格实现"和"底层原理"这两块基础打扎实。

（2）阅读心得

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

大学课堂和中学不一样，没人盯着你学，但课堂有它不可替代的价值：老师会讲到 PPT 上没有的"隐性知识"——比如某个坑是怎么踩的、某个方案的取舍过程；同学在课上提的问题，常常是我也没想明白的问题。视频可以暂停回放，但视频不会回答你的追问。所以只要没有特殊情况，我都会来上课，并且尽量带着问题听。

b) 师生关系与作业态度

我大学里体验到的师生关系更接近"上完课就散"，但我希望这门课能像教练与学员的关系：老师能指出我的问题在哪里，我也愿意主动暴露自己的不足。如果老师布置的作业对我来说有些困难，我会选择 C：向老师和同学请教，花更多时间，把作业全部完成。

c) 引用与抄袭的区别

在工作中，引用文献、参考开源代码、在别人基础上继续开发是常态；而抄袭、剽窃是把别人的东西"伪装成自己的"。两者的核心区别有三点：是否声明来源——引用会明确标注出处，抄袭会刻意隐瞒；是否理解并消化——引用是在理解基础上的二次创造，抄袭是复制粘贴；是否获得了"不该获得的利益"——通过抄袭拿到学分、学位、offer，是对其他诚实付出者的不公平。在本课程中，我会遵守学校对抄袭的处理规定，参考任何资料都注明出处，代码写明哪些部分借鉴了何处。

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

几年后，我倾向于直接工作，方向是软件开发（目前偏向 Java 后端）。选择这条路，是因为我对动手做东西更有兴趣，也想尽早进入真实的工作环境积累工程经验。对照前人的经历，我的优势是目标明确、愿意动手；劣势是代码量少、项目经验几乎没有，理论和工程基础都需要补。

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

认真完成软件工程课程的所有作业，包括个人项目与团队项目；
把团队项目当作"一次小实习"来对待，走完需求、设计、编码、测试、发布全流程；
每周固定时间刷算法题，为实习和校招面试做准备；
读《构建之法》，把工程思维补起来。

（4）本课程的具体计划

我对这门课的期待是：走出"写完能跑就行"的阶段，学会用工程化的方式做软件。我希望课程结束时，我能熟练使用 Git 进行团队协作，写出带单元测试、有文档的项目，并完整体验一次软件工程的流程。

当前代码量估算：

语言	代码量（行）
Java	约 2000
合计	约 2000

目标代码量：本课程结束时计划新增约 2000-3000 行有效代码（个人 + 团队项目合计）。按 16 周计算，平均每周约 150-200 行。

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

关于助教：目前不考虑申请助教，想先把精力放在自己的课程项目上。

（5）WOOP 计划

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

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

第一次在 GitHub 上有一个有 README、有测试、有提交历史规范的项目；
第一次能用 Git 和同学顺畅地协作，而不是各写各的最后拼在一起；
第一次能向一个不懂技术的朋友讲清楚"我做了个什么东西"。

Obstacles / 障碍：

内部障碍：拖延，计划列得满满当当却迟迟不动手；遇到 bug 排不出来时容易烦躁、想放弃；容易被手机和视频分心。
外部障碍：其他课程作业挤压时间；考试周前后软件工程容易被牺牲；团队项目里有人进度跟不上。

最可能的失败因素："完美主义 + 拖延"的组合——总想准备充分再开始，结果迟迟不动手，最后临近期限仓促交差。

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

如果我打开电脑 10 分钟内还没开始写代码，那么我就把手机放到远处，关掉无关网页，只留编辑器和终端。
如果我遇到一个 bug 卡了 40 分钟还没头绪，那么我就先站起来活动一下，换个思路；实在不行再搜索或向同学、老师请教。
如果某周计划没完成，那么我不把任务堆到下周，而是当周周末补完，避免"滚雪球"。
如果团队项目里有人长期不响应，那么我先私下沟通一次；若仍无改善，就主动找老师/助教反馈，而不是自己闷头代劳。

3. 提有质量的问题

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

问题一

阅读位置：第 3 章软件工程师的成长
我的问题：书中说软件工程师的成长不只是技术水平，还包括沟通、抗压、分析问题等能力。但作为一个还没走出校门的学生，我怎么判断自己是否真的在"成长"，而不是在原地打转？有没有一些可以操作的自检方法？
阅读后的思考：我以前对"成长"的理解很单一：会的新东西多不多。但书中把成长拆成了多个维度，这让我意识到自己可能一直在用"学了什么"替代"成长了什么"。大一大二我上过很多课，但如果不回头整理，很难说清楚自己到底长进了多少。
我的观点：我认为成长需要一个看得见的度量，比如定期回看自己写的代码、统计有效代码量、记录解决问题的过程。光靠感觉会骗人，光靠课程成绩也不够。

问题二

阅读位置：第 6 章敏捷流程
我的问题：敏捷强调小步快跑、频繁交付和迭代改进，但学生团队一周只有几个晚上能凑在一起，迭代怎么切才不至于流于形式？
阅读后的思考：书里的敏捷实践（如每日站会、迭代评审）在公司的全职团队里是自然的节奏，但学生团队的时间是碎片化的，强行照搬很可能变成"每周开个会汇报一下"的形式主义。我在之前的小组作业里就遇到过：定了计划，但没人真正按迭代走，最后又回到"最后一周赶工"。
我的观点：我认为学生团队应该把敏捷的"精神"（小步交付、及时反馈）留下，把"形式"（站会、看板）按实际情况裁剪，比如把迭代周期定为一周，每周末必须有一个能演示的东西，哪怕很小。

问题三

阅读位置：第 8 章需求分析
我的问题：需求分析强调挖掘用户的真实需求，但当"用户"是老师或者不懂技术的甲方时，需求本身就很模糊（比如"做一个管理系统"），怎么把这种模糊描述变成可以验收的规格？
阅读后的思考：书里的需求分析方法假设用户能表达需求，但实际上很多需求方自己也不清楚要什么。课程设计里老师给的需求往往只有一句话，剩下的全靠自己脑补，最后验收时才发现理解偏了。这让我意识到"澄清需求"本身是一项需要练习的能力。
我的观点：我认为面对模糊需求，应该主动用提问、原型、示例把需求钉死：做出一个最小原型给需求方看，比口头确认一百遍都有效。"先做出来给用户看"本身就是一种需求分析手段。

问题四

阅读位置：第 13 章软件测试
我的问题：测试金字塔主张大量写单元测试，但现在很多学生项目（包括我的）大量代码是由 AI 辅助生成的，这种情况下测试的重点应该放在哪里？是继续追求单元测试覆盖率，还是把精力放在集成测试和手工验证上？
阅读后的思考：AI 生成的代码往往"看起来都对"，但边界条件和异常路径容易出错。如果自己一行一行去测试 AI 写的代码，工作量可能比自己写还大。但完全不测，就是把质量交给运气。我感觉传统测试策略在"AI 辅助开发"的场景下需要重新权衡。
我的观点：我认为 AI 生成代码的场景下，测试的重点应该是核心业务逻辑和边界条件，而不是机械地追求覆盖率。至少要做到：核心函数有测试、关键路径能跑通、异常输入有处理。覆盖率是手段，不是目的。

问题五

阅读位置：第 17 章人、绩效和职业道德
我的问题：书中强调工程师的职业道德，但团队项目里"搭便车"的成员（不做或少做，最后照样拿成绩）很常见，除了道德谴责，工程流程上有什么办法可以预防或缓解？
阅读后的思考：我经历过小组作业里有人全程不参与、最后署名的情况。只靠"自觉"显然不可靠，但作为学生又没法像公司那样用绩效和工资来约束。书里讲了绩效管理，但学生团队的场景很不一样，没有强约束手段。
我的观点：我认为可以从流程上做文章：任务拆分到人并公开记录（谁认领了什么、完成度如何）、用 Git 提交记录和 Code Review 留痕、定期同步进展让"没干活"无所遁形。流程透明比事后追责更有效。

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

4. 前车之鉴

我从前面的参考列表（豆瓣《构建之法》书评区讨论）中选取了以下 2 篇进行阅读和反思。

阅读 1：刘帅《在失望中寻找希望》（ https://book.douban.com/subject/4006425/discussion/22803961/ ）

这篇文章的作者回顾了自己"本科迷迷糊糊、工作三年、考研进清华、IBM 实习、面试 17 家公司最终签下 Amazon"的经历。让我印象最深的是他在"完美时空"面试的复盘：面试官问 Java 的 const 怎么实现、lucene 的索引原理、自动化测试框架怎么设计，他几乎每个问题都答不上来——用他自己的话说，"知其然不知其所以然，这是我的一贯问题"。

我的感想：这篇文章像一面镜子。我在课程作业里也是"能跑就行"：HashMap 天天用，却说不清它为什么线程不安全；报错信息扫一眼就上搜索引擎，很少自己去想根本原因。作者强调的"主动思考"和"基本功"我此前都不太当回事，总觉得以后工作再补。读完我才意识到，面试考察的恰恰是这些"以为不考"的底层问题，而思考习惯是要长期养成的。我决定从现在开始，每学完一个知识点，逼自己问三个"为什么"，而不是停在"会用了"。

阅读 2：徐宥《掉进读书的兔子洞》（ https://book.douban.com/subject/4006425/discussion/22802960/ ）

这篇文章的作者从小学时父亲教他平面几何讲起，一路写到大学里"一个字母一个字母"敲完《Thinking in Java》全书例子，总结出三个理念：什么都可以自学、"慢即是快"、知识理想主义。他大三时广泛读书做笔记，说自己像在"建索引"，后来找工作、写论文时按图索骥，收益巨大。

我的感想：这篇文章戳中了我学 Java 的方式。我学新东西时经常"看懂了"就翻页，结果自己动手写时还是卡壳——原来"看懂"和"会写"之间隔着一段必须亲手敲的路。作者"慢即是快"的说法我很认同：看起来笨的笨功夫（逐个敲例子、做笔记、整理知识索引），长期看反而是最快的。我打算把 Java 核心技术重新动手过一遍，不再满足于"看过"，同时开始用博客做自己的"知识索引"，把学过的东西沉淀下来。