第一周作业

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

一、准备工作

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

二、正文

1. 介绍自己，建博客

你好，我是dl12，计算机科学与技术专业的一名大三学生。

为什么开这个博客。 过去两年，我先后学习了 C 语言和 Java：C 让我第一次理解"指针、内存、程序到底是怎么真正跑起来的"，Java 让我第一次体会到"封装、继承、多态"如何把一个复杂问题拆成可维护的模块。但我也逐渐发现自己的一个毛病——很多东西"学过就忘"，问起来"好像会"，一动手就露馅。开这个博客，就是想逼自己把学过的东西讲出来：能讲清楚，才算真的懂。

关于写博客，我是认真支持派。 写博客确实花时间，一篇文章从构思到排版可能两三个小时，但它是一种"复利"——写完一次，下次再用就是一秒钟的事；而且写出来的东西会被别人看到、被搜索到、收到反馈，这种"被看见"的压力会倒逼自己把细节抠清楚。我打算先坚持一个学期看效果。我也理解反对的同学会说"写博客是自我感动、性价比低"——我的反驳是：博客首先写给三个月后的自己，其次才是别人；哪怕没有一个读者，它也是一份诚实的成长记录。

关于格式和上传代码。 本随笔全部用 Markdown 编写，代码统一放进代码块并标注语言；完整的代码上传到 GitHub 仓库，随笔里只贴核心片段和仓库链接。这样既保证可读性，也方便别人复现。

说说我的闪光点。 很多人觉得自己没本事，其实只是没把它当回事。我挑两个讲：

  1. 编程上的积累（C 和 Java）：这是我在课内花时间最多、也最有底气的地方。学 C 那会儿，为了搞懂指针和内存，我把课后题一道一道敲下来，遇到段错误（segmentation fault）就打印变量、画内存图，前前后后花了一个学期；学 Java 时，为了理解面向对象，我把课程设计从"一个 main 函数写完"硬改成"分层 + 多态"，改的过程很痛苦，但改完才真正懂了封装的意义。这些练习让我从"只会写 Hello World"走到能独立完成一个小项目。
  2. 课本之外的坚持（台球和篮球）：篮球我从初中开始打；台球随便打打。这些爱好看似和编程无关，但它们教会我同一件事：所谓天赋，大多只是愿意在上面花时间。我想把这种耐心，原样迁移到软件工程的学习上。

2. 现状、经验和计划

一、专业选择、差距与技能现状

1.1 为什么选择计算机科学与技术专业

我是因为学校课程才选了计算机。学 C 之前，程序对我是一堆黑盒；第一次用指针、画内存图、亲手触发又亲手修掉一个 segment fault 之后，我才体会到"从抽象到可验证"的乐趣。后来学 Java 的封装/继承/多态，又让我看到复杂问题可以被拆成可维护的模块。这种"能亲手造、能亲手验证"的特质，让我认定了这个专业。

1.2 离合格 IT 毕业生的差距
  • 后端技术栈：Java/Go/Python + Spring Boot/MySQL/Redis/HTTP/RPC，能独立完成小项目；
  • 工程习惯：研发流程规范；
  • 学习迁移能力：从 C（内存/指针）到 Java（OOP 分层多态）的完整路径走通过。
1.3 技能调查表（5–7 项）

**③ 提升手段

  1. 跟着课程每周完成全部编码作业，并把课程设计做成"分层 + 多态 + 带测试"的完整项目；

二、博客心得

2.1 为什么来上课并认真参与

认真参与，本质是因为课堂是"最低成本获得即时反馈"的地方。我自己认一个道理——能讲清楚才算真懂；而课堂的提问、讨论、被老师追问，就是对我"到底懂没懂"的即时检验。其次，课程内容是复利：现在课堂上抠清楚的一个点，后面做项目、面试时就是一次即取即用的积累。最后，认真参与等于"主动暴露自己不懂的地方"，这比闷头自学、用"好像会"骗自己要划算得多。

2.2 师生关系 + 作业难怎么办

我经历过的师生关系：多是"讲授型"——老师讲、学生听，课后交流少，遇到问题主要靠自己扛。

我希望这门课的关系：老师给方向、给方法、给及时反馈，学生主动提问、主动暴露问题.

作业难怎么办 → 我选 C（向老师和同学请教，花更多时间，把作业全部完成），具体做法：

  1. 先自己排查：读报错、打印变量、查文档，卡 30 分钟以上再求助；
  2. 带着具体问题和已经试过的方案去问同学，而不是空手问"这题怎么做"；
  3. 同学解决不了，再整理好问题去请教老师；
  4. 做完后把卡点记进博客，避免下次再卡。
2.3 引用/参考 vs 抄袭/剽窃
维度 引用 / 参考 抄袭 / 剽窃
是否标注来源 明确标注出处（文内引用 + 参考文献） 不标注，或故意隐藏来源
自己的贡献 在他人的工作基础上做出自己的理解、实现或增量 原样/近似原样照搬，没有自己的东西
可追溯性 别人能顺着出处找到原始工作 无法追溯、冒充自己的成果
常见越界 复制代码不标注、让 AI/他人代做交作业 —

三、未来规划我的选择：做软件项目 → 能就业**。

今天怎么准备：好好学习，天天上上。

本学期规划（动作 + 对象 + 结果）：

  1. 完成本课程项目；
  2. 每周 1 篇技术博客 → 形成个人成长记录。

四、课程计划

我对这门课的期待：重工程实践、有及时反馈、能产出一个完整项目，而不是纯理论考试。

高校教学科研：不重代码量，重深度与产出（一个能复现的系统、一篇论文）；代码的可复现性、正确性、可维护性比行数重要得多。

关于"前两年浪费时间、现在发奋赶上"→ 我选 D（比以前课要多很多，直到达到目标为止）。

课程结束代码量目标：本学期新增 约 800–1000 行有效代码 。

4.1 WOOP 计划

W（愿望）：本课程结束时，独立完成一个带测试、带文档、能上 GitHub 的后端项目。

O（最好结果）：项目能跑、有测试覆盖、有清晰文档。

O（障碍，具体化）：

  • 内部："学过就忘"的老毛病——学完不复述不复习，两周就忘，动手就露馅；
  • 内部：实习占用时间，晚上/周末精力不足，容易"今天太累明天再学"；
  • 内部：静不下心——写代码时想刷手机、开小差，坐不住；
  • 外部：课程任务和实习、其他课、篮球台球的时间冲突。

最可能导致失败的因素：不能长期自律（学完不复述、进度断档）。这和我在博客里自己承认的"学过就忘"是同一个根子。克服办法：用"输出倒逼"（每章必写博客/讲给自己听）+ 下面的 if-then 计划 + 每周复盘，用流程代替意志力。

P（if-then 计划）：

  1. 如果写代码时想刷手机 → 就立刻站起来离开电脑和手机，出去走一圈再回来；
  2. 如果某章学完怕忘 → 就当天写一段博客或复述给自己听，讲不清的地方标出来重学；
  3. 如果遇到 bug 卡住想放弃 → 就先打印变量/画内存图/查文档 30 分钟，还不行再问同学老师；
  4. 如果一周没达标 → 就周末复盘，调整下周计划，而不是自责后摆烂。
  1. 提有质量的问题

我快速阅读了《构建之法》（邹欣著）一书，下面是 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：有问题就问，至少一学期提三个问题，认真按时填写反馈。理由：老师改进教学需要真实信号，敷衍的反馈既浪费自己时间，也误导老师。

3. 提有质量的问题, 给认真的反馈

问题一：一个个人项目，到底什么时候从"程序"变成"软件"？

引用（第1章 1.1 软件 = 程序 + 软件工程）：作者说，程序 = 数据结构 + 算法，而软件 = 程序 + 软件工程。一个人写个能跑的计算器是"程序"，但要让上百万人安装、不崩溃、能升级，就需要源代码管理、配置管理、质量保障、测试、需求分析这些"软件工程"的东西。

我的问题：这条界线对个人项目/课程设计也成立吗？一个只有我一个用户、不会上线、写完就存档的课程作业，真的需要去套"软件工程"这一整套吗？

我的经验：我学 Java 的时候做过课程设计，最开始是"一个 main 函数写完"能跑就行；后来我硬改成"分层 + 多态"，改的过程很痛苦，但改完才真正懂了封装的意义。可是反过来，我也写过一些一次性脚本，如果非要给它写单元测试、搞配置管理，只会觉得是在自我感动。

我的困惑：我不反对"软件 = 程序 + 软件工程"，我反对的是把这条公式无条件套到任何规模的项目上。书里第1章也提了"玩具阶段→成熟产业阶段"的演进，说软件工程是"复杂度到了才必须有"。那判断"复杂度到没到"的标准到底是什么？是代码行数、用户数、还是维护时间？对于一个想成长的个人开发者，什么时候该主动上工程手段、什么时候是 over-engineering？这一点书里没给我一个可操作的判断标准。

问题二："测试只能证明有 bug，不能证明没有 bug"，那质量保障的价值到底怎么兑现？

引用（第13章 软件测试 / 第14章 质量保障）：书中反复强调，测试只能证明程序有 bug，无法证明程序没有 bug；"好软件 == 没有 bug"，而 bug 是"软件的行为和用户期望值不一样"。

我的困惑：既然目标不是"零 bug"，那一个项目到底测到什么程度算"够"？

问题三：创新到底是"颠覆"，还是"把一件小事做到更好"？

引用（第16章 IT 行业的创新，16.1 创新的迷思）：作者谈了很多关于"创新"的迷思，核心观点之一是：创新往往不是凭空冒出来的惊天动地，而是有迹可循、渐进发生的。

我的观点：我部分同意，但想补充一个程序员视角的反例。我把课程设计从"一个 main 函数"改成"分层 + 多态"，这个动作对外人看毫无"创新"可言——它甚至只是把别人早就发明的设计模式用了一遍。但对我自己，它是一次货真价实的认知升级：我第一次真正"懂"了封装的意义。这种"对个人而言是创新、对行业而言是重复"的东西，到底算不算创新？

我的反对：如果书里把"创新"主要定义为"对行业有增量"的大创新，那会不会无意间贬低了"个人成长式的、重复造轮子式的创新"？对一个还在读书的学生，恰恰是这些"重复"在塑造能力。创新这个词，对个人和对行业，是不是该用两套标准？

问题四：敏捷流程，到底是理想还是常态？

引用（第6章 敏捷流程）：书中介绍了敏捷、Scrum、每日站会、冲刺（sprint）等流程，以及"敏捷流程的问题和解法"。

我的问题：书里把敏捷讲得很"顺"，敏捷在真实的大厂 ToB 场景下，是被改造过的吗？

我的实践：这让我怀疑：敏捷是不是更适合 to C、快速试错的场景，而不是 to B 这种"稳定压倒一切"的场景？

我的困惑：书里讲了敏捷的"问题和解法"，但更多是团队内部协作层面的问题。我想知道的是，敏捷有没有它不适用的场景？ 当一个团队选择不用敏捷、用更重流程（比如类 CMMI 或类 MSF 的模型）时，是基于什么判断？还是说，敏捷和重流程根本不是二选一，而是可以混用的？

问题五：团队里的"搭便车"，软件工程真的管得了吗？

引用（第5章 团队和流程，5.2 软件团队的模式）：书里把软件团队分成主治医师模式、明星模式、社区模式、功能团队模式等很多种，并且提到，大学里很多团队是"主治医师模式"或"业余剧团模式"，还常常演变成"一个人干活，其他人打酱油"。

我的问题：书里的团队模式分类，解决的是"怎么组织人"，但似乎绕不开一个更根本的问题——"人"的问题，靠流程真的能解决吗？ 搭便车（free rider）、责任心缺失、有人中途不辞而别，这些是流程问题还是人性问题？

我的经验：我在课程设计小组里亲身经历过"一个人扛起全部"和"有人只挂名不干活"两种情况。书里第17章还专门讲了"猪、鸡和鹦鹉的故事"——猪是全身投入（committed），鸡是参与（involved）。这个比喻很扎心，但它更多是描述了现象，而没有给出可操作的解法。

我的困惑：在没有任何"管理权力"的大学生团队里（大家是平级同学，没有人能开除谁、扣谁工资），当遇到搭便车的成员时，除了"自己多干点"和"汇报给老师"之外，软件工程还能提供什么手段？绩效管理那一套（第17章）依赖的是上级对下级的考核权，但在平级协作里，这套权力根本不存在。

认真反馈：我会怎么做

这个"健身/教练"的比喻我挺认同的。健身学员不问"为什么练这个动作"，教练就不知道学员哪里没懂；学生不反馈，老师就不知道教学哪里该改。所以我选 C：有问题就问，至少一学期提三个问题，认真按时填写反馈。

具体到我的做法：

  1. 把"至少三个问题"落到实处：这学期我打算问的三个问题分别落在——课程项目怎么设计架构、测试与质量保障怎么落地、团队协作怎么避免搭便车。这三个正好是我实习和课程最关心的三块。
  2. 提问前先自查：带着"我已经试过什么、卡在哪一步"去问，而不是空手问"这题怎么做"。
  3. 认真按时填写反馈：反馈是双向的——老师靠它改进教学，就像我们靠 code review 改进代码。我不敷衍，每次都写具体的、能落到行动上的意见（比如"第 X 部分讲快了，希望多给一个例子"），而不是"很好、没意见"这种空话。

4. 前车之鉴

感想一：原来"科班却没学懂计算机"的不止我一个

文章：刘帅《在失望中寻找希望》
链接：https://book.douban.com/subject/4006425/discussion/22803961/

这篇里有一句话，像照镜子一样戳中了我：

"我是传统意义上的计算机科班出身，学过数据结构、编译原理、操作系统……然而，我却并没有学懂计算机。"

刘帅本科四年成绩一直排前、几乎每学期拿奖学金，但他自己承认：那些高分是用"机械记忆 + 沿老师讲过的固定模式做题"换来的，不是真懂。他举的例子特别扎心——数据结构这门本该"动手写程序"的课，被老师讲成了一门"只听不写"的数学课，于是他就这样迷迷糊糊混过了本科。

这跟我写博客的动机几乎是同一件事。 我开这个博客的初衷就是：很多东西"学过就忘"、问起来"好像会"、一动手就露馅。刘帅把这个毛病命名为"机械记忆"——不是没学，是只记住了结论、没形成自己的思考。区别只在于：他是毕业多年后才痛悟的，而我至少现在就已经开始警惕了。

让我印象最深的是他旁听清华朱仲涛老师"数据结构"课的那段：朱老师只用 1/5 的时间讲概念，剩下时间全部当场从零写程序，讲一个 Convex Hull 算法时，1.5 小时边写边讲、一个编译错误都没有，全班鼓掌两分钟。刘帅总结道：

"凡是自己不理解的东西、自己说不清道不明的东西，其实有很多人是理解的。"

这句话我读了三遍。它恰好印证了我对写博客的一个执念——"能讲清楚，才算真的懂"。朱老师那种"讲透"的能力，就是我想用输出倒逼自己去达到的状态；而刘帅本科那个"照本宣科"的老师，就是我时刻提醒自己不要变成的样子。

我带走的一句话：机械记忆贻害无穷，它会让人"胆子变小、创新力丧失"。我的对策很简单——以后每学一个东西，不满足于"会做作业"，而是试着用一句话讲给三个月后的自己听；讲不清，就是没懂。

感想二：实习经验重要吗？这位学长用亲身踩坑说"别高估它"

文章：周见智《一直在路上——记我从初中到本科近十年的学习成长历程》
链接：https://www.cnblogs.com/xiaozhi_5638/p/4485805.html

这篇是典型的"偏科生自学逆袭"故事：作者来自湖北农村、高考上二本，靠着"多实践、多上网查资料"的自学，一路从谭浩强的 C++ 敲到 MFC、Win32，大三拿软考证书、大四跷课去北京实习、毕业后创业。但真正让我停下来想的，是他对"实习"那段的反省：

"多年以后，我才发现企业要的应届毕业生就是一张白纸，这些白纸吸墨能力的高低决定你能否找到好的工作，而吸墨能力高则主要是基本功扎实、自学能力强的体现，并非我一直以为的丰富的'实习经验'。"

**这话对我有点"反常识"，甚至有点刺耳。周见智是用亲身教训在说：他当年为了"实习经验"跷课去北京、还惹毛了老师，回头才发现，面试官看应届生，看的是你"吸墨能力"——也就是基本功和自学能力，而不是简历上那行公司名。他后来面试"完美时空"被一连串"底层问题"问崩的经历。

他文末给了四条建议：自学、英语、重视基础、眼界。我对照自己的情况，最需要补的是"重视基础"这一条：实习和课程并行时，最容易被牺牲的就是那些"短期看不出效果、但决定天花板"的基础课。

posted @ 2026-09-05 11:55  dl12  阅读(24)  评论(0)    收藏  举报