第一周作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标	熟悉博客园、GitHub 两个平台的基本使用；掌握 Markdown 写作技术随笔；系统复盘自己的学习现状并制定本课程学习计划；带着问题阅读《构建之法》并输出独立思考；阅读前辈经验教训，避开成长弯路，养成以输出倒逼输入的学习习惯。

一、介绍自己，建博客

大家好，我是计算机科学与技术专业的一名大三学生。平时折腾得比较多的是 Java 后端，偶尔也写点 Python 脚本偷懒。

关于写博客这件事，我一开始是抗拒的。觉得有那时间不如多敲两行代码，排版、截图、组织语言，一套流程下来一两个小时就没了。但后来有一次，我试图给同学讲清楚 Spring 里 Bean 的生命周期，讲着讲着自己先卡壳了——明明看过好几遍，真到要输出的时候才发现脑子里是一团浆糊。那次之后我才意识到，“看过”和“懂了”之间隔着一道鸿沟，而写博客就是逼自己跨过这道鸿沟的手段。写的过程中你会被迫面对那些含糊其辞的地方，要么查清楚，要么承认自己没懂。
当然，我也理解有些同学觉得写博客是形式主义。如果只是把教材目录抄一遍、把代码原封不动贴上去，那确实没意义。但如果是记录自己踩过的坑、想通的点、推翻的假设，那写本身就是一种高密度的复习。反对的同学不妨先试一个月，用数据说话。
至于我的闪光点……说实话，刚看到“说说自己的闪光点”这个要求时，我第一反应也是“我有什么闪光点”。但仔细想了想，我确实有一个不算本事的本事：我能在一件事情上反复失败还不放弃。 比如调一个 Bug，别人可能试两三次就放弃了，我会一直试，换思路、查源码、翻 issue，直到把它干掉。这种“轴”在生活里可能不讨喜，但在编程这件事上，它帮了我很多。这个特质不是天生的，是大二那年被一个死循环折腾了整整两天之后，慢慢磨出来的。
底线方面：作业独立完成，不抄袭，不敷衍，参考了别人的东西一定注明。 这是底线，不是高标准。

二、现状、经验和计划

（1）专业选择、现状与技能提升计划

为什么选这个专业： 说实话，当初填志愿时并没有多么宏大的理由。就是觉得计算机能让我“自己造东西”，而且反馈快——写一行代码，跑一下，对错立现。这种即时反馈让我上瘾。后来慢慢发现，这个行业更新快、天花板高、相对公平，只要肯学就有饭吃，就一路读下来了。
差距分析： 离一个合格的 IT 毕业生，我缺的主要是“工程感”。具体来说：写代码更多是“能跑就行”，很少考虑可维护性、边界条件、异常处理；没用过正经的 CI/CD；单元测试基本靠 main 方法里打印；团队协作全靠微信发文件。这些短板在课程作业里可能不明显，但到了企业环境里全是硬伤。

技能自评与提升计划（0–9 分，5 分 = 能过面试，9 分 = 世界一流）：

技能项	当前	目标	提升手段
Java 编码能力	4	6	完成课程作业；独立写一个带分层架构的小项目；读 Spring 源码并做笔记；把每个知识点写成博客；找同学互相 review；优先查官方文档而不是搜索引擎。
调试排错能力	3	6	遇到报错先读完整堆栈再动手；把典型 Bug 整理成排查清单；熟练用 IDE 断点和条件断点；主动帮同学看问题；每次修完 Bug 写三行复盘；读开源项目的 issue 和 PR。
Git/GitHub	2	7	所有作业强制用 Git 管理；专门练一次分支合并冲突；给每个项目写 README；读 Pro Git 前四章；尝试给开源项目提一个文档类 PR；和同学模拟一次完整的团队协作流程。
需求分析	2	5	小组项目主动认领需求梳理；学写用户故事和验收标准；分析两个真实产品的需求文档；练习把一句话需求拆成任务清单；看开源项目的 issue 理解用户诉求；组内互相挑刺。
单元测试	2	5	学 JUnit 5 和 Mockito；给自己已有的代码补测试；读 Spring Boot 项目的测试代码；学等价类和边界值设计用例；作业里强制自己写测试；把测试踩坑写进博客。
技术文档	3	6	每个项目写像样的 README；每周至少一篇博客；模仿优秀开源项目的文档结构；小组作业写接口文档；请同学审阅文档并改；学 Markdown 和中文排版规范。
团队协作	2	6	积极参与小组项目；学任务拆分和估时；练习 code review 并给出具体意见；用看板工具跟进进度；主动同步进度和风险；项目结束写复盘。

（2）阅读心得

a) 为什么要来上课并认真参与。 那篇学生思考和评论区我都看了。有一个观点戳中了我：大学是最后一段可以“全职学习”的日子。工作以后，你很难再有整块的时间、低廉的试错成本、以及一群可以随时讨论的同学。软件工程这门课的价值不在于它教了什么知识点，而在于它模拟了一个完整的工程流程——需求、设计、编码、测试、交付。这个流程自己摸索也能走，但大概率会走歪。有老师带着走一遍，能省很多时间。

b) 师生关系与困难作业的处理。 我经历的师生关系大多是“你讲我听、你考我背”。我期望的这门课是教练和学员的关系：教练给训练计划、纠正动作、指出瓶颈；学员自己练、自己问、自己扛。如果作业很难，我选 C：向老师和同学请教，花更多时间，把作业全部完成。 难说明有训练价值。我会先自己查资料、试错，带着具体问题去问，而不是一上来就问“这怎么做”。如果实在做不完，我会提前跟老师说明情况，而不是拖到 deadline 再摆烂。

c) 引用、抄袭、剽窃的区别。 我的理解：引用是“站在别人肩膀上，并且告诉大家你站了”——标注来源、加入自己的理解和改造；抄袭是“拿走别人的东西，不吭声”——不标注、不改造；剽窃是“把别人的东西说成自己的”——用于获取成绩、奖项等利益。前两者是学术规范问题，后者是诚信问题。我查了学校规定，抄袭作业轻则零分重则记过。这门课我的原则：代码可以查、可以学，但必须是理解之后自己写出来的；引用思路和代码片段一定注明来源。

（3）未来发展选择、优劣势与学期规划

我想走互联网后端开发这条路。原因很简单：我喜欢那种“一个请求进来，经过层层处理，最终落库返回”的完整链条感。
优势： 方向明确，不用在多个方向之间反复横跳；能坐得住，愿意花时间死磕一个问题；有写笔记的习惯，学过的东西不容易全忘。
劣势： 项目经验几乎为零，简历上能写的东西很少；对分布式、高并发这些后端核心话题只停留在八股文层面；团队协作经验欠缺，没经历过真正的多人协作开发。
本学期规划： ①所有课程作业保质保量完成；②自己写一个带数据库、带接口的小项目并部署上线；③把 Git 用熟，至少完整走一遍团队协作流程；④每周至少一篇技术博客；⑤每周日晚上复盘本周的薄弱点。

（4）课程计划、代码量与 WOOP 规划

对课程的期待： 希望这门课能让我真正体验一次“从需求到交付”的完整流程，而不是停留在画 UML 图和背概念。希望老师能多给一些真实项目的案例，少一些纯理论的灌输。

当前代码量： Java 约 3200 行，C 约 800 行，Python 约 600 行，合计约 4600 行。
行业参考： 想进一流互联网公司，学生阶段有效代码量最好在 1 万行以上，并且要有完整项目经历；高校科研方向不硬性看行数，更看代码质量和原理理解深度。
时间投入： 每周约 14 小时（含上课）。前两年确实浪费了不少时间，现在选 D：比以前课要多很多，直到达到目标为止。 本学期目标新增有效代码约 5000 行，平均每周约 400 行。

WOOP 规划：
Wish： 课程结束时，能独立完成一个前后端分离的小项目并部署上线，Git 协作用熟，博客沉淀 15 篇以上，总代码量接近 1 万行。
Outcome： 简历上有东西可写，面试时能讲清楚自己做过的项目，而不是只能背八股。想到这个画面，确实有动力。
Obstacles： 最大的障碍是拖延。具体表现是：任务一难就想先放一放，一放就放到 deadline 前一天。其次是手机依赖——写代码卡住时下意识摸手机，一刷就是半小时。
Plan（if-then）：

如果写代码时想摸手机，那么把手机放到床上，人坐在书桌前；

如果任务太难想拖延，那么先只做 10 分钟，10 分钟后如果还想拖再停；

如果调试超过 1 小时没进展，那么停下来写清楚已排查的线索，找同学或助教讨论；

如果某周被其他课挤占，那么周末补上，保证周代码量不低于 300 行；

如果连续三天没写博客，那么第四天必须补一篇，哪怕只写 300 字。

课程反馈
选 C：有问题就问，至少一学期提三个问题，认真按时填写反馈。 教学是双向的，老师需要知道学生卡在哪里。我会把真实的问题和困难反馈上去，而不是随便填个“很好”了事。

三、读《构建之法》：五个问题

问题 1：第 1 章——"足够好"到底是谁说了算？

原文： 软件工程师的目标不是创造完美的软件，而是在现有约束条件下，做出"足够好"的软件。
我的问题： "足够好"的判定权在谁手里？是开发者、项目经理、还是用户？如果三方对"足够好"的理解不一致，听谁的？
我的经验： 我做课程项目时，自己觉得"够好了"，交给同学试用，对方五分钟就找出三个崩溃场景。我认为的"足够好"和用户认为的"足够好"完全不是一回事。
困惑： 书里说要在质量、成本、时间、需求之间平衡，但没说平衡的决策机制是什么。是投票？是负责人拍板？还是看哪一方更强势？

问题 2：第 2 章——PSP 对新手是不是太重了？

原文： PSP 可以帮助开发者量化效率，精准预估工时，发现短板。
我的问题： 新手连代码都写不利索，让他花时间记录每一分钟干了什么、每个阶段花了多久，这个投入产出比合理吗？
我的经验： 我尝试记录过三天自己的编码时间，结果发现光是记录和分类就花了将近一个小时，而且数据还不准——因为经常被打断，很难界定"编码时间"的边界。
困惑： PSP 的设计初衷是好的，但它是不是更适合已经有一定经验、需要精细优化效率的开发者？新手阶段是不是应该先追求"写出来"，再追求"写得快"？

问题 3：第 4 章——结对编程在什么情况下会变成"一人干活一人看"？

原文： 结对编程能有效减少缺陷，统一思路，互相学习。
我的问题： 如果两个人水平差距过大，或者性格都偏内向、不擅长即时沟通，结对编程会不会退化成"一个人写，另一个人发呆"？
我的经验： 我和同学试过结对编程，结果是我写他看，他不好意思打断我，我也不好意思问他。两个小时后，代码是我一个人写的，他什么都没学到。
困惑： 书里把结对编程的好处讲得很充分，但对"什么情况下不该结对"讲得很少。是不是应该先评估两个人的匹配度再决定？

问题 4：第 5 章——明星团队模式是不是被低估了？

原文： 不同的团队模式适配不同场景，没有绝对最优。
我的问题： 书里对明星团队（一个技术大牛带若干普通成员）似乎持保留态度，但现实中很多创业公司早期就是这种模式，而且跑得很快。明星团队的问题到底是模式本身，还是管理方式？
我的经验： 我参与过的小组项目中，有一个"大牛包揽"的组，进度飞快但其他人参与感极低；也有一个"平均分配"的组，进度慢但每个人都练到了。两种模式各有代价，关键看项目目标是什么。
困惑： 如果课程项目的目标是"让每个人都能练到"，那是不是应该刻意避免明星团队？但如果目标是"做出最好的产品"，明星团队是不是更优？

问题 5：第 6 章——敏捷的"拥抱变化"有没有边界？

原文： 敏捷开发拥抱需求变化，通过短周期迭代快速响应。
我的问题： 如果需求变化是无限的，迭代周期再短也追不上。敏捷的"拥抱变化"是不是应该有一个前置条件——比如需求变更需要经过评估和优先级排序？
我的经验： 我们小组做项目时，每次开会都有人提新想法，大家都觉得"敏捷嘛，拥抱变化"，结果迭代计划改了又改，最后什么都没做完。
困惑： 书里强调敏捷的灵活性，但对"如何拒绝不合理的需求变更"讲得不够。是不是应该在拥抱变化之前，先建立一个变更评估机制？

四、前车之鉴：三篇前人文章感想

文章 1：
https://book.douban.com/subject/4006425/discussion/22803733/
内容： 把每天要做的事情分成 ABCD 四类——A 紧迫且重要，B 重要不紧迫，C 紧迫不重要，D 不重要不紧迫。
感想： 我以前是典型的"救火队员"，谁催得急就先做谁的，结果长期下来，那些不紧急但重要的事——比如系统学一门新技术、认真读一本书——全被挤没了。这篇文章让我意识到，B 类任务才是真正拉开差距的地方。我打算从这周开始，每天早上花五分钟把当天的任务分个类，并且强制自己每天至少做一件 B 类的事。

文章 2： https://book.douban.com/subject/4006425/discussion/22803961/
内容： 科班学生却觉得自己没学懂计算机。
感想： 这个我太有共鸣了。大三了，数据结构、操作系统、计算机网络都学过，考试成绩也不差，但让我从零实现一个简单的 HTTP 服务器，我还是会卡住。问题出在"学"和"做"是脱节的。 考试考的是"知道"，而工程能力考的是"做到"。这篇文章提醒我，不能再用"这门课我考了 90 分"来骗自己了，得用"我能做出什么东西"来衡量自己。

文章 3： https://book.douban.com/subject/4006425/discussion/22802960/
内容： 把每天胡思乱想的东西记在一个笔记本上，作为思维快照，常常翻回去自省。
感想： 我试过记日记，但坚持不下来，因为总觉得"没什么好写的"。这篇文章给了我一个不同的角度：不用写完整的日记，只记"想法碎片"就行——突然冒出的疑问、对某个问题的直觉判断、想做但还没做的事。这些碎片当时看着没用，过几个月翻回去，能清楚看到自己的思维轨迹。我准备在博客里开一个"碎片"分类，专门放这些不成熟的想法。

附录：GitHub相关说明

地址：
https://github.com/RicharTan-zlz/RicharTan-zlz/blob/main/README.md

截图：