第一周作业

这个作业属于哪个课程	计科24级6班
这个作业要求在哪里	第一周作业
这个作业的目标	熟悉博客园与 GitHub 的基础使用；审视自身技术水平，制定本学期清晰的学习规划；阅读《构建之法》并提出独立思考的问题。

一、介绍自己，建立博客

我是一名计算机相关专业的在校生。出于对个人隐私的保护，我不在网络上公开真实姓名，希望把这个博客纯粹作为一个记录技术成长、沉淀工程思考的专属空间。目前我的学习重心主要放在算法基础上。

建立这个博客的初衷，是为了逼迫自己跳出“只会写代码，不会做总结”的舒适区。以往写代码遇到报错，我习惯于去网上搜索现成的解决方案，跑通了就万事大吉，很少去深究背后的原理。这种“快餐式”的解决方式导致很多知识如同过眼云烟。我希望借由这门课，养成在博客上复盘技术细节、规范文字表达的习惯。

在个人特质方面，我自认不是天赋型选手，但我拥有较强的韧性和系统性思维。面对一个复杂的开发任务，我不怯于把它拆解成一个个基础模块，哪怕一开始的代码很笨拙，我也愿意通过一次次的重构去优化它。我相信在软件工程领域，“稳扎稳打、持续迭代”比短暂的聪明更加重要。

在接下来的课程中，我对自己设定的底线是：

• 按时交付：将作业视为工程任务，严格遵守 Deadline。
• 敬畏原创：代码和文档绝不抄袭，借鉴他人思路或代码片段时，必定附上清晰的引用来源。
• 先思后问：遇到技术阻碍，先查阅官方文档和检索有效信息，思考无果后再向他人求助。

我的 GitHub 仓库地址是：[https://github.com/treec34/treec34]。未来的一学期，这里将见证我代码量的真实积累。

---

二、现状、经验和计划

1. 为什么选择计算机专业

选择计算机，是因为我被这门学科“所见即所得”的创造力所吸引。只需要一台电脑和网络，就能将脑海中的逻辑转化为切实运行的工具，这种反馈机制让人着迷。但随着学习的深入，我也清醒地认识到，写几行能跑的脚本和构建一个高可用的软件工程，两者之间有着天壤之别。

对标一名合格的 IT 毕业生，我目前的差距主要集中在：

• 系统观缺失：对操作系统、计算机网络等底层知识的掌握仍然停留在应付考试的层面，未能与实际编程融会贯通。
• 工程化经验几乎为零：没有完整参与过具备需求分析、版本控制、自动化测试和代码审查环节的协同开发项目。
• 代码规范性差：缺乏面向对象设计的深刻理解，代码可读性与可维护性较低。

2. 核心技能评估与目标

结合课程要求，我对自己的核心技能做了如下评估与规划：

技能名称	目前水平(0-9)	课程结束目标(0-9)
【语言名称，如：Java/C/Python】 基础与进阶	4	7
常见数据结构与算法应用	3	6
Git 协作与版本控制	1	6
软件测试（单元测试、调试）	2	5
技术文档编写与系统设计	3	6

为达成上述目标，我的行动计划：

1. 刻意练习：每周至少在 LeetCode 或类似平台上独立解决 3 道算法题，保持手感。
2. 工具熟练：全面弃用图形化 Git 工具，强制自己使用命令行提交代码，规范 Commit 信息。
3. 阅读源码：在课设或项目中，尽量少看经过他人咀嚼的博客教程，强迫自己去啃官方英文文档。
4. 复盘沉淀：每两周在博客园输出一篇有质量的技术踩坑记录或知识点总结。
5. 代码重构：写完功能代码后，必须花额外的时间优化命名、提取公共方法，降低代码耦合度。

3. 课程态度与职业规划

课程参与态度：
我期望这门课能提供一个足够真实、甚至略带压力的“软件作坊”环境。如果老师布置的作业难度超纲，我会选择 C: 向老师和同学请教，花更多时间，把作业全部完成。 因为在未来的职场上，产品经理不会因为“这个需求太难”就放弃发布，突破瓶颈的过程才是能力跃升的最佳时机。

职业规划：
未来，我倾向于进入一线科技公司担任后端/底层研发工程师。
相比于同龄人，我的劣势是起步较晚，项目经验匮乏；优势则是心态踏实，抗压能力强。本学期的核心规划就是：把《构建之法》中的理论落地到实际项目中，力求在简历上能留下一个真正经历了“生老病死”迭代过程的软件项目。

4. 课程计划与 WOOP 法

• 当前代码量：约 【3000】 行。
• 行业门槛认知：我认为要胜任一线研发岗位，至少需要累积 【4万】 行以上的有效工程代码。
• 时间投入：我选择 C: 比以前的课稍多一些，计划每周投入 【15】 个小时用于本门课程（含上课与课后实践）。
• 期末目标：预计本学期新增代码量 【10000】 行左右，平均每周产出 【500】 行高质量代码。

我的 WOOP 风险防范计划：

• Wish（愿望）：在期末团队项目中，独立且高质量地完成核心功能模块，不拖团队后腿。
• Outcome（结果）：看着自己的代码在系统中稳定运行，极大提升技术自信，不再对复杂的工程项目感到恐惧。
• Obstacles（障碍）：前期配置环境或遇到诡异 Bug 时极易产生烦躁感；任务繁重时容易选择性逃避，去刷手机。
• Plan（计划）：如果（If）我在某个报错上卡住超过 45 分钟感到焦虑，那么（Then）我就立刻起身离开屏幕，去喝水或散步 10 分钟，回来后尝试把问题抽象成文字描述发到技术论坛或向助教求助，绝不无效死磕。

---

三、提有质量的问题

在快速阅读《构建之法》后，结合我目前的认知水平，我提出以下 5 个疑问：

问题 1：关于结对编程的实际效益（第 4 章 4.5）

书中极力推崇结对编程（Pair Programming），认为领航员和驾驶员的角色互换能极大提升代码质量。
我的困惑是：在技术水平差异巨大，或是两者性格都很内向的组合中，结对编程会不会演变成“一个人写，另一个人发呆”的无效形式？对于新手团队，是否存在一个“启动结对编程”的最低能力门槛？

问题 2：需求分析中的伪需求过滤（第 8 章 8.2）

书中提到通过调研获取用户需求。
我的困惑是：用户有时并不知道自己真正想要什么（福特经典的名言：用户想要更快的马）。作为经验不足的学生团队，我们在做项目前期调研时，如何去伪存真，甄别出哪些是核心需求，哪些是用户的“伪需求”或低优先级需求，从而避免把时间浪费在不重要的地方？

问题 3：项目经理（PM）的技术边界（第 9 章 9.3）

书中阐述了 PM 负责沟通、推进进度和做决定。
我的困惑是：在一个纯软件开发团队中，PM 需要懂多深的代码？如果 PM 完全不懂技术细节，开发人员以“技术上实现不了”或“需要一个月”为由推脱，PM 该如何做出客观判断并推进项目？

问题 4：敏捷开发与文档维护的平衡（第 6 章 6.1）

敏捷开发的价值观之一是“工作的软件高于详尽的文档”。
我的困惑是：在人员流动性极强的学生团队或是开源社区中，如果文档过于精简，后来接手的维护者将面临极大的阅读阻碍。在敏捷迭代的过程中，到底应该在哪个节点、以多深的颗粒度来补充文档，才能兼顾开发效率与项目的可传承性？

问题 5：创新的时机与试错成本（第 16 章 16.1）

书中在探讨创新时提到，先驱者常常容易成为先烈。
我的困惑是：对于我们这种初创的学生项目，到底是应该去红海市场“像素级模仿”一个成熟的产品来锻炼工程能力更稳妥，还是应该冒着做出来的东西没人用的风险，去追求绝对的“蓝海”创新？哪种方式对提升专业能力的帮助更大？

反馈态度：
在课程反馈方面，我选择 D: 经常提问题，平时就经常给老师和助教提反馈。 有质量的沟通是消除信息差的唯一途径。

---

四、前车之鉴

阅读了往届前辈的经验博客，我有两点深刻的体会：

感想 1：拒绝“虚假的热爱”，正视枯燥的过程

参考阅读：不要轻易在简历上写我热爱编程
我的体会：这篇探讨让我警醒。很多人把“喜欢打游戏、喜欢体验新 App”错当成“热爱计算机”。真正的工程开发往往伴随着配置环境的折磨、看英文文档的枯燥以及无休止的 Debug。这篇文章让我明白，不要轻言热爱，要先看自己能否忍受这份枯燥。我希望通过这学期的真刀真枪，去检验并培养自己对技术最真实的敬畏。

感想 2：大学教育的“无用之用”

参考阅读：速成的培训班和打基础的大学教育有区别么
我的体会：在追求快节奏的今天，我们很容易陷入“学这个能马上找到工作吗”的功利陷阱，从而忽视数据结构、操作系统的学习。这篇文章论证了基础学科的价值。那些看似难以直接变现的底层原理，其实是决定一个程序员未来天花板的内功。技术框架几年一换，但底层逻辑永存，不能用短视的眼光去衡量大学教育。