第一周作业

这个作业属于哪个课程	计科24级56班 (广东工业大学 - 计算机学院)
这个作业要求在哪	第一周作业
这个作业的目标	完成第一篇软件工程随笔：介绍自己并建立博客与 GitHub 同名仓库； 通过技能调查、指定博客阅读和前车之鉴，明确自身现状、差距与学期规划； 练习 Markdown 排版、规范引用与按时提交作业，为后续课程项目做准备。

软件工程第一周随笔作业

1. 个人介绍以及建博客原因

我是广东工业大学计算机科学与技术专业的大三学生，目前的技术方向是前端，未来方向为AI全栈。性格上，我是一个偏内向的人，但是在熟人面前我又比较聊得开，做事方面，我会尽可能做好我想做的事，但我想认真说说自己有哪些本事。

我曾经一直觉得自己“没什么闪光点”：成绩不是年级前几，代码不如比赛大佬写得快。后来我想了想，发现自己的优势其实是一种被低估的能力：写文档记录

我最早接触web网页开发是在大一，当时只会一点一点的写 html 和 css，在控制台一遍一遍的调试，再到后面的 js ，我把这个过程的大部分技术， bug 等等都记录在案。然后在到黑马程序员和尚硅谷的视频里的 Vue ， Nodejs 等等，到最后的项目开发的开发文档， Bug 文档，可以说语雀，飞书文档见证了我一路的成长，认真算下来，我从只会复制代码到能独立完成一个个小项目，这两年里，中间最大的进步不是记住更多 API ，学会了更多技术，而是学会把“我不知道”写下来，然后有耐心地去查。

在这门课里，我也会这样要求自己：写博客不追求写的多完美，但要留下有用的东西，不至于最后这几篇博客写的一无是处。

2. 现状、经验和计划

2.1 选择计算机专业的原因及技能调查表

当初高考填报志愿时，首先分数在省内也就广工比较合适，可以去211的不太好的专业，但是还是选择了广工，想读工科，就把广工的好专业从高到低填进去了，自动化差一分，然后当初不知为何把机电填在了计算机后面，其实是可以读当时机电最好的那一个班的，但是既来之则安之。

既然选择了计算机，后面在大一的时候金工作室选择了软件开发方向，现在回头看了一下自己离 “合格的 IT 专业毕业生” 还是有明显差距

• 前端知识停留在“会用框架搭页面”，对浏览器渲染、网络、性能优化等的底层原理掌握并不是很深；
• 数据结构和算法不强，遇到面试题容易凭印象写，可能会卡壳；
• 对于全栈和 AI 全栈还有比较长的东西要学，比如 Java ，Nuxtjs 等等
• 语言表达能力偏弱

下面是技能调查表中挑出的 5 项技能。调查表里的 L1-L5 是行为画像，当前水平 0-9（5 表示能通过面试）课程结束时我会再回来对照这张表，看自己有没有真的提高。

技能	当前水平 (0-9)	课程结束目标 (0-9)	提高手段
需求对齐与代码健康度	5	7	1. 开发前先用一段话写清楚“功能是什么、验收标准是什么”，让代码和需求能够一一对应。 2. 给课程项目配置 ESLint，新增警告清零后再提交，不允许带着明显问题提交代码。 3. 对 AI 生成的每一段代码先逐行检查再提交，删除死代码、冗余分支和未使用的 import。 4. 把功能拆成 UI、状态、数据请求等小模块，单个文件过长时立即做一次重构。 5. 每周用 git diff 做一次代码体检，把发现的问题写成带明确说明的重构 Commit。
工程复现性与构建完整度	4	6	1. README 写清项目介绍、环境要求、安装步骤和启动命令。 2. 提交 package-lock.json 等锁文件，不让依赖版本处于不可复现状态。 3. 提供 .env.example，真实密钥只放本地环境变量，不硬编码进代码。 4. 删掉依赖目录后按 README 从零跑通一次，验证项目在另一台电脑上能启动。 5. 统一提供 npm run dev、build、test 等脚本，并完成一次线上预览部署。
手动掌控力与底层原理	4	6	1. 每周安排一小时“禁用 AI”编码练习，只靠文档和日志完成任务。 2. 遇到报错先看报错堆栈、官方文档和相关日志，至少独立排查 15 分钟再求助。 3. 对 AI 生成的复杂代码，挑出核心部分自己重写一遍，确保不是只改参数就提交。 4. 每个新知识点写 200 字原理说明，要求自己能讲清“为什么这样设计”。 5. 定期脱离 AI 手写基础 JavaScript、SQL 和正则表达式，再对照资料检查错误。
验证深度与测试覆盖	3	5	1. 每个核心业务逻辑至少写一组“正常路径 + 边界条件 + 异常输入”测试用例。 2. 学习并安装前端单元测试框架，先覆盖最容易出错的输入转换和状态变化逻辑。 3. 对 API 和网络请求使用 Mock 或 Stub 隔离，保证测试不依赖真实网络环境。 4. 本地生成覆盖率报告并查看未覆盖分支，逐步把行覆盖率提高到 60% 以上。 5. 把测试命令加入 CI，出现不稳定测试时先修复，而不是直接跳过。
开源杠杆与社区贡献	3	5	1. 每次复用开源代码，都在文件或 README 中注明项目名、代码出处和许可证。 2. 使用开源库前先读 README、LICENSE 和 CONTRIBUTING，明确允许的使用范围。 3. 从 good first issue 或文档类任务入手，动手前先留言认领，避免重复工作。 4. 让 PR 保持小范围，附上修改说明、测试结果或截图，并与 Issue 建立关联。 5. 认真回复维护者的 Code Review 意见，把收到反馈当作目标，不以必须被合并作为硬指标。

2.2 阅读博客及心得

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

我读了Scalers 的原文和一位同学对它的思考，也看了下面的评论。Scalers 认为认真听讲是像练肌肉一样需要长期训练的能力，不能因为老师讲得不好就放弃课堂；北航同学则结合自己的经历反驳，认为不是所有课堂都值得无条件听讲，学生也有评价和反馈的权利。

我的看法介于两者之间：专注确实需要训练，但认真参与不等于无脑服从。我仍然选择认真上这门课，是因为软件工程的很多能力——需求、评审、团队协作、按截止日期交付——只有在有老师、有同学的真实环境里才能得到反馈，一个人看视频很容易误以为“学会了”。

具体做法是：课前预习时写下两个不懂的问题，课堂上先跟上思路、记录具体疑问；如果觉得老师讲得不好，我会查资料后提出建设性反馈，而不是用“课太水”作为玩手机的借口。

b 我体验过的师生关系，和我希望这门课的关系

这篇文章列举了我熟悉的几种大学师生关系：学生把自己当顾客的“餐馆/食客”，导师把学生当劳动力的“老板/雇员”，老师把知识嚼碎了喂给学生的“保姆/幼儿”，以及大家一起放水的“哥们/哥们”。我亲身体验最多的是“讲授者 + 接收者”：老师讲，我记，期末考，很少得到及时反馈。

文中提出的“健身教练 / 健身学员”正是我期待的关系：想变强的必须是学员，流汗写代码、改 Bug 的也必须是学员；教练提供训练计划、及时反馈和严格要求，但不替学员完成动作。如果老师布置的作业对我有些困难，我选：C：向老师和同学请教，花更多时间，把作业全部完成。 我会先自己查资料并定位问题，把“我做了什么、在哪里卡住”写清楚后再提问；如果作业确实超出当前能力，我会分阶段提交已完成的部分，并在课堂或作业反馈中说明卡点，而不是直接放弃或找人代做。

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

我阅读了课程给出的文章。文中说，写文档时引用别人的文献（间接经验）本身没有问题，前提是明确标出出处；学术论文建立在别人的研究上，软件开发也建立在别人的框架和模块上，如实说明引用是做学问、做项目的基础。真正算抄袭的，是不注明来源的照搬，比如把多年前的整段文字、甚至早已过时的软硬件配置原样写进自己的文档。

所以参考与抄袭的区别不在于“有没有用过别人的东西”，而在于三点：是否理解了它并转化为自己的贡献；是否诚实标出来源；是否遵守开源许可证或学校规定。站在前人代码上继续开发是日常工作，把别人的整份作业或整段文字当作自己的原创才是抄袭。

在这门课里，我会把博客中引用的文章、图片、代码都放上来源链接；课程开始后我会主动向老师确认“可以引用到什么程度”，并查阅学校对学生抄袭的处理规定。宁可多写一句“参考自……”，也不冒险把模糊地带当成默认允许。

2.3 几年后我想做什么，现在怎样为将来准备

几年后我不会一条路走到黑，但目前最想做的选择是：先进入软件行业做前端方向的工作，并在工作中逐步加深对工程的理解，未来转全栈或 AI 应用工程师以及架构师之类。

选择这个方向的原因是，我能从用户实际看到、用到的界面和交互中获得成就感，也愿意为“把复杂产品做得简单”付出长期练习。相比班里其他同学，我的优势是：

• 有比较强的视觉和产品直觉，能把需求转成可演示的界面；
• 能独立完成“页面 → 接口 → 部署”的最小闭环，动手产出的速度较快；
• 习惯写复盘，能描述自己的思考和选择，而不是只会交代码。

我的劣势也同样清楚：

• 计算机理论基础不够扎实，遇到需要算法、操作系统、网络原理的问题容易露怯；
• 没有真实企业实习经历，不知道正规团队中需求评审、排期、Code Review 到底怎么做；
• 面对“什么都要学”的信息过载时，容易收集教程而不是深入一个方向。
• 近年来， AI 对软件开发的影响十分巨大，有点像是软件开发的寒冬

所以本学期的规划是：完善我的一个项目，并接入 AI 大模型；把前端手撕算法和力扣 hot100 再复盘一下；持续刷牛客和小红书上的面经以及关注最新前沿科技；从十月开始持续投递并复盘面试。等到了秋招，我希望自己能带着“完整参与过一个多人项目”和“几次真实面试复盘”去投递，而不是只带着课程分数。

2.4 课程计划、代码量与时间安排

我对这门课的期待是：它不该是一堂只讲名词的课，而该是一次“带着真实压力做项目”的训练。我希望课程里有明确分工的团队开发、代码评审、用户反馈和发布节点，而不是每个人期末交一个互不相干的个人作业。

目前我的代码量估算如下（只统计我自己写/维护过的代码）：

• C 语言：约1000行
• HTML / CSS：约 2000 行；
• JavaScript / TypeScript（含 Node.js 脚本与服务端代码）：约 3000 行；

合计约 6000 行。这些行数里真正会被别人长期阅读和维护的代码并不多，所以我不会把“行数多”当作能力强的证据。

关于“多少代码量才有资格”，我没有找到统一答案，也不认为行数是唯一指标。我更认同的说法是：一线软件/互联网/AI 公司的实习或校招，看的是算法能力、项目深度、表达能力和工程素养；但代码量至少能反映“熟练度”。如果给自己定参考线，我认为想通过一流公司前端岗的实习面试，至少要积累 1 万到 2 万行“能被别人 review 的真实项目代码”，并且能讲清楚其中 3 到 5 个关键设计；正式研发岗、需要长期维护系统的岗位，这个熟练度要更高，可能要到 3 万行以上才有“工程手感”。从事高校教学科研工作，代码量本身不是唯一门槛，更需要能复现实验、维护教学代码、读懂别人代码的能力，我猜 1 万到 2 万行可读、可复现的代码会是比较实际的起点。

我打算平均每周在这门课上投入 5 个小时，其中约 3 小时上课，其余时间用于阅读、小组协作、写博客和课程项目。前两年我的时间不算完全浪费，但大多用在了“被动接收”上；对这门课我选：
C：比以前的课稍多一些。

“稍多一些”不等于只在截止日前加班，而是每周固定留出时间，并把课程目标拆到周粒度执行，让投入可积累、可持续。

我计划到课程结束时再完成约 8000 行代码，其中一半以上是与团队项目相关的真实功能、测试和重构代码；这样每周需要完成约 500 行代码。看起来不多，但我会要求自己每周都让仓库处于可运行状态，而不是只在最后一周补上万行。

下面用 WOOP 方法把计划写具体：

• Wish（愿望）：学期结束时，我能完成一个持续迭代的全栈项目，拿到一份软件开发日常实习 offer。
• Outcome（结果）：如果愿望实现，我可以把课程项目作为简历上的真实作品，在面试中讲清楚自己做的需求、遇到的技术难点和如何与同学协作；写博客也不再是“为交作业而挤出来”，而是真的能在写的过程中发现自己理解错了什么。
• Obstacles（障碍）：我的最大内部障碍是“避难趋易”：遇到界面细节会很投入，遇到需求梳理、测试和文档这些不立即产生成就感的工作就拖延；同时我容易在晚上刷手机，一刷就把整块时间切碎。外部障碍是其他课程、实习投递带来的焦虑，以及小组协作中大家时间不一致导致的等待。
• Plan（计划）：
  • 如果用 AI 辅助写代码时遇到不太能理解的，那么我尽可能的查资料补充相应确实的知识点。
  • 如果晚上计划好的 2 小时学习被手机占据，那么我会把手机放到客厅或书包里，先完成一个 25 分钟的番茄钟再休息。
  • 如果小组任务需要别人先完成而我只能等待，那么我会把等待时间用于做自己的写技术笔记或刷算法，不让自己陷入空转。
  • 如果连续两周没有实习面试消息，那么我会把“投了没回”当作数据，每两周更新一次简历和项目描述，而不是一边焦虑一边停止练习。

我最可能失败的因素是：遇到不喜欢的任务时找借口，把它拖到截止前才做。 克服方法是：每周日晚检查一次“本周是否有被拖延的任务”，如果有，下一周第一件事就是把它拆成 30 分钟可完成的小块并先做掉。

3. 高质量提问与课程反馈

我按老师建议用快速阅读的方式通读了《构建之法》，没有逐字细读，遇到难懂的地方先跳过，读完整本后再回来。以下引用都是大意，页数以纸质版为准；我主要结合自己找前端实习的经历提问。

问题 1：软件工程的手段应该在什么规模下“入场”？

位置：《构建之法》第 1 章“概论”，软件工程不仅仅是写代码的部分。

书中说，软件不只是程序，还包括需求、设计、测试、维护等工程活动。我同意这一点，但我的疑问是：对于只有我一个人维护的个人小项目，是不是也应该完整走一遍这些流程？如果走全套，可能一周也发布不了；如果完全不走，项目过了两个月自己都看不懂。

我的经验是：大二做课程项目时，我试过写完整需求文档，但写到一半发现需求本身还不清楚，文档很快就过期了；反而是我先把功能跑通、再补测试，项目才真正可用。我的困惑是：判断“该引入测试、文档、评审”的规模阈值到底是什么？是可维护时间、团队人数，还是出错成本？书里讲清了软件工程的价值，但没有给出一个学生能操作的判断标准。

问题 2：敏捷流程会不会变成“会议敏捷”？

位置：第 6 章“敏捷流程”中关于 Scrum、冲刺与每日站会的部分。

书中介绍的敏捷流程强调小步迭代、持续反馈和响应变化，主张每日站会短而有效，而不是把时间浪费在流程仪式上。我基本认同，但我在观察一些开源项目和校园团队时发现，很多团队只是在形式上做了“每日站会 + 看板 + Sprint”，实际上每个人仍各写各的，站会变成向 PM 汇报进度，代码评审变成走过场。

我自己的困惑是：敏捷强调“个体和交互胜过流程和工具”，可一旦进入课程作业或公司考核，大家又会去数“站会开了没、看板更新了没”这些可检查的东西，最后培养出的反而是仪式感。我该怎么判断一个团队是真敏捷还是“会议敏捷”？如果在课程团队里发现站会没有产生决策，我应该提出取消站会、改成异步更新，还是继续按流程执行等待老师干预？

问题 3：先写测试在需求不明时会不会过早锁死设计？

位置：第 13 章“软件测试”中关于测试驱动开发、尽早测试的部分。

书中强调测试要尽早设计、尽早执行，测试能帮助我们在写代码前想清楚行为的预期。我也认可测试能暴露设计问题，但在做前端组件时，我经常遇到一种情况：交互方式还没确定，我如果先按想象中的接口写测试，之后需求一变，测试反而成为重构的阻力。比如一个搜索框，一开始我设计成“输入后自动请求”，后来产品希望改成“输入后等 500ms 防抖再请求”，先写的测试就全部要改。

我不认为这是反对测试，而是想弄清：在探索性开发阶段，哪些测试值得先写，哪些测试应该等接口稳定后再补？书中对“测试驱动开发”的讨论是否默认了需求已经足够明确？如果需求本身是探索性的，先做原型再补测试是不是更符合现实？

问题 4：当“付费客户”和“真正用户”不是同一群人时，用户故事该怎么写？

位置：第 10 章“典型用户和场景”，以及关于需求获取、用户故事的部分。

书中用典型用户、使用场景来帮助我们理解真实需求，避免凭空发明功能。这个方法很有用，但在很多校内项目里，付费或决策的人（比如学院老师、学校管理员）和最终每天使用系统的人（比如学生、普通员工）并不是同一群人，他们的诉求甚至可能冲突：学生希望移动端随时查看通知，管理员则希望桌面端有复杂统计和权限控制。

我在一个小项目中做过用户访谈，访谈对象是老师，结果做出来的功能对老师很方便，真正使用的学生却觉得难用。我的问题是：一个课程团队只有几周时间时，应该优先满足付费决策者的需求，还是优先满足最终用户的需求？如果两者冲突，有没有像“用户故事 + 验收标准 + 数据验证”这样能让学生操作的取舍方法？书中对“用户”的讨论，是不是把“决策者和使用者一致”当作默认前提了？

问题 5：书中讨论的“创新”，会不会把工程视角看得比市场视角更重？

位置：第 16 章“IT 行业的创新”中关于创新是什么、如何创新的部分。

书里给我的整体印象是：创新不一定是惊天动地的原创，把已有技术用在新场景、解决真实问题也是创新；同时书中也提醒不要为了创新而创新。我很认同这个观点，但我觉得它更多是从“做工程的人能控制什么”出发的。现实里，很多产品成功不是因为技术更先进，而是因为渠道、数据、品牌或者时机更好；同一套“旧技术组合”，有人做出来是产品，有人做出来只是 demo。

联想到现在的 AI 应用，大量产品只是给大模型套了一个界面，技术上都算不上新，但用户量和收入差异很大。我的困惑是：作为学生，我应该如何区分“值得写进简历的技术创新”和“只是把一个通用能力包装了一下”的应用创新？判断创新价值的最终标准，是技术复杂度、用户价值，还是市场结果？这本书希望学生练习的“创新”，具体应该落在哪一步？

给课程的认真反馈

反馈题我会选择 C：有问题就问，至少一学期提三个问题，认真按时填写反馈。

我给自己定三条可以执行的约定：

1. 课上或阅读中产生的困惑，我会先记在问题清单里，不因为怕问得笨而删掉；至少保证一学期认真提出 3 个有价值的问题。
2. 课程要求填反馈时认真按时完成，不只写“挺好的/太难了”，而是写清“哪个环节让我卡住、我希望得到什么帮助、什么方式对我有效”。
3. 给同学做反馈时对事不对人，用“我遇到了什么问题 + 我建议如何改进”的句式，不做情绪化评价。

4. 前车之鉴：从学长的经历中看到的自己

第一篇：《科班，但没学懂计算机》

《科班，但没学懂计算机》讨论

我很怕自己也变成文章里说的“上了计算机专业课，却没学懂计算机”的人。说实话，这种恐惧是真实的：我能说出很多课程名词，但被问到“输入一个 URL 后浏览器发生了什么”，我只能讲到一半，卡在 TCP、DNS 和渲染进程的细节上；被问到排序算法，我能背出复杂度，却不能现场推导一次。

文章给我的提醒是：上课听懂了不等于会用了，会写作业也不等于建立了系统理解。这学期我不再把“考试过了”当作学会了的证据，而是每个模块都给自己提一个“如果让我现场讲给别人听，我能讲清楚吗”的问题。讲不清楚的地方，就是我要补课的地方。

第二篇：《偏科生自学摸索的道路。实习经验对应届生重要吗？》

偏科生自学摸索的道路

这篇文章让我更确定现在就该找日常实习，而不是等“准备好”再投。我以前总觉得，等我把 React、算法、网络都学完再投实习，胜算才高；但文章让我意识到，实习的价值不只是证明能力，更是让我尽早进入真实的工作节奏：理解别人的代码、接受需求变更、在有限排期内交付。

我的行动是：本月就完成第一轮前端简历和项目页，每周至少投递几次日常实习岗位；每次面试后把“被问到但答不上来的问题”记下来，用两周时间集中解决，而不是用“我还没准备好”安慰自己。

第三篇：《技术栈和大佬的爆栈之旅》

技术栈和大佬的爆栈之旅

读这篇时我最受触动的不是“大佬懂得多”，而是技术栈是一步步“爆”出来的：从解决眼前问题开始，不断把一个技术用深，再顺着依赖关系扩展到下一个技术。前端最容易犯的错是收集一堆教程，今天看 Vue 明天看 React，最后每一个都只会写 demo。

所以我给自己定的规则是：同一个知识点，至少要走到“能在自己的项目里用起来，并给别人讲清楚为什么这样用”才算学过。本学期我把深度主题压缩成三个：TypeScript 类型与组件设计、浏览器网络与渲染、前端性能与可访问性。宁可少学几个新框架，也要能把这三件事讲成完整的故事。

截图附录

博客园默认 Markdown 编辑模式

个人 GitHub 地址及仓库截图
GitHub 个人主页地址： https://github.com/shiningbrightlydarkmoon
仓库地址： https://github.com/shiningbrightlydarkmoon/shiningbrightlydarkmoon
截图: