软件工程第一周作业

第一次作业：准备、现状与规划

这个作业属于哪个课程	计科24级78班
这个作业要求在哪里	第一周作业
这个作业的目标	完成个人技术博客与 GitHub 仓库建设；介绍自己；梳理专业知识、技能与能力差距；阅读《构建之法》并尝试提出高质量问题；阅读前人经验并制定本学期学习规划

---

一、介绍自己，建博客

我叫张志远，是广东工业大学24级计科8班的学生，目前正在系统学习编程、数据结构和软件工程相关课程。个人爱好也很广泛，游戏，田径，篮球，足球，长跑，历史，地理，大多数人的爱好我似乎都能聊上一两句。这里是我的个人技术博客，我希望用它记录学习过程中的代码、笔记和思考，也用它来倒逼自己把零散的知识整理成完整的表达。

我以前对“写博客”的理解比较浅，觉得会写代码就可以了。但开始实践后发现，写博客至少会强迫我做三件事：把一个概念解释清楚、把代码整理到可以复现、把学习过程中的错误和解决方案沉淀下来。这些恰好是技术学习中最容易被忽略的部分。

我的一个优势技能可能是：学习能力，我自认为还是有较强的学习和适应能力，能比较快速的学习新的知识，但还需要做到的是怎么把学到的浅显的知识变成自己真正掌握的属于自己的知识。
我达到目前这个水平，主要是因为经过了一个月的暑期实习和两个学年课外听网课。这个过程让我相信：大多数能力都不是天生差距，而是长期训练和持续反馈的结果。

我也很认同“上课交作业要有底线”的说法。作业不应当只是为了应付提交，它至少应该是自己认真完成、能解释得清楚的作品。在引用他人资料时，我会注明来源；在需要说明个人经历时，我会尽量写真实、可验证的内容。

---

二、现状、经验和计划

（1）为什么选择计算机专业，我目前的差距在哪里

我选择计算机科学与技术专业，主要是因为就业，之前只知道这个专业毕业后能赚到钱，现在发现其实自己也挺喜欢这种明确计划后设计自己的程序一步一步完成自己的计划的过程

我清楚自己离一个合格的 IT 专业毕业生还有明显差距。如果按“专业知识、专业技能、专业能力”三个层次来看：

• 专业知识：基础课程还在学习中，体系尚未完整。
• 专业技能：能完成课程作业，但项目经验不足，工程化意识较弱。
• 专业能力：自学、协作、表达和问题拆解能力仍需持续训练。

从技能调查表中，我选择下面 6 项作为本学期重点：

技能	目前水平（0–9）	课程结束后希望达到的水平（0–9）	计划通过什么手段提高
数据结构与算法	[4]	[5]	对照教材和 LeetCode 刷题；整理常见题型模板；给同学讲解；写博客记录；参加模拟笔试
java	[4]	[5]	做小项目；阅读官方文档；参加开源项目练习；定期 review 自己的代码
Git 与 GitHub	[5]	[6]	完成本作业仓库；学习分支与协作流程；给开源项目提 issue 或 PR；记录常用命令；每周同步练习
英语技术资料阅读	[5]	[6]	阅读英文教材和官方文档；积累技术词汇；尝试用英文写学习笔记；参加技术社区讨论；每周精读一篇英文文章
表达与协作	[5]	[6]	写博客并做课后讲解；参加小组讨论；录制 3 分钟学习总结；主动向老师同学提问；参加课程分享

（2）关于上课、师生关系和引用规范的思考

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

我读了《刘帅：在失望中寻找希望》。作者是计算机科班出身，成绩也不错，却说自己“是科班，但没学懂计算机”。他的经历让我意识到，上课不仅仅只是听知识点，更重要的是在老师、同学和课堂讨论中获得一种“主动思考”的状态。

我的看法是：大学课堂的密度也许不像网络课程那样可以快进，但它提供的是即时反馈、同伴比较和老师的经验。认真参与不是被动坐在那里，而是主动去学，去做。这样，课堂才能成为学习的起点，而不是终点。

b) 我体验到的师生关系，以及我希望这门课是什么样的师生关系

我更希望这门课是“教练和学员”的关系：老师提供方向、标准、反馈和资源，我作为学生负责训练、执行和提出具体问题。这样既能尊重老师的专业判断，也能让我对自己的学习结果负责。

如果老师布置的作业对我有些困难，我的做法是：

C：向老师和同学请教，花更多时间，把作业全部完成。

我会先自己尝试定位卡点，把“哪里不会、试过什么、卡在哪一步”写下来，再去查资料或向老师、同学请教，而不是直接放弃或只想拿到及格。

c) 引用、借鉴与抄袭的区别

我认为它们之间的核心区别是：是否保留来源、是否经过自己的理解与重构、是否利用他人的成果冒充自己的原创。

• 引用：明确标注出处，用引号标明原文，并在参考文献中列出。
• 借鉴：学习别人的思路或结构，然后用自己的语言重新表达，并说明参考来源。
• 抄袭：复制他人的文字、代码或观点，却标注为自己完成，或者不注明来源。

在课程中，我会遵守老师对作业引用和代码相似度的具体要求，也会主动查询学校对学术不端和抄袭的处理规定。

（3）几年后我的选择，以及今天的准备

结合前人的经历，我目前更倾向于毕业后先进入软件项目/工程开发方向，而不是一开始就做纯粹的学术研究。原因是：我更喜欢通过工程实践解决具体问题，也拥有开发的相关经历和经验。

在这个选择下：

• 我的优势：自学能力较强、有好问的心态、人际交往能力较强。
• 我的劣势：项目经验偏少、基础理论还不够扎实、对一些代码的错误分析能力较差。

本学期，我会把主要精力放在以下三件事上：

1. 每周保持稳定的代码训练。
2. 至少完成一个完整的github开源项目复现，从需求、设计、实现到测试走一遍。
3. 通过博客和 GitHub 形成“输入—输出—反馈”的学习闭环。

（4）我对这门课程的计划与期待

我参考了美国本科、中国软件工程本科以及美国大学软件专业的教学方式，发现优秀课程往往有几个共同点：强调实践、要求可运行的作业、鼓励协作、重视代码质量和复盘。因此，我对这门课的期待是：不只学习理论，而是通过项目把软件工程的方法真正用起来。

我目前不想申请当助教，因为自己还在补基础；我更愿意先把课程内容学扎实。

当前代码量

语言	当前代码量	说明
C	[2000 ]	课程作业、数据结构练习
java	[1000]	少量面向对象练习
HTML/CSS/JavaScript	[500 ]	网页入门练习
合计	[3500]	精确到 100 行

我认为，想要有资格进入一流的软件公司、互联网公司或人工智能公司，仅靠课程代码量远远不够。更重要的是“高质量代码量”：包括可运行的项目、经过测试的代码、可维护的工程结构，以及从需求到部署的完整经历。如果从事高校教学科研，则还需要更多阅读、论文写作和深入验证的工作，而不只是代码量。

每周投入时间

我计划平均每周拿出5-7小时用于这门课，包括上课时间。

如果以前两年的时间没有充分利用，现在想发奋赶上，我的选择是：

B: 和以前其他课花一样多的时间。
本课程结束时，我计划完成大约 1500 行有明确用途、能运行或能复查的代码，平均每周完成约 100 行。

WOOP 计划

Wish/愿望：
我希望在本课程结束时，能独立完成一个可运行、可展示、可维护的小型软件项目，并把 Git/GitHub、需求分析、设计、实现、测试和文档完整走一遍。

Outcome/结果：
如果这个愿望实现，最好的结果是：我不再只是“会写作业”，而是能向别人清楚地解释我的项目为什么这样设计，能用证据说明它经过了测试和改进。这种从“我学过”到“我做过”的转变，会让我对未来实习和求职更有底气。

Obstacles/障碍：
最可能阻碍我的因素不是能力，而是时间碎片化。具体来说，我会在写程序遇到困难时，不由自主地打开手机刷视频、看消息，把短暂的逃避变成几十分钟甚至一小时的拖延。

Plan/风险防范：
如果我在程序没有写完时想开小差刷手机，那么我就把手机放到盒子里，站起来接一杯水、走一圈，再回到电脑前继续写作业。

最可能的失败因素：
最可能导致我达不到目标的是“不能长期自律”。我会用具体的小目标和固定时间表来应对：把每周任务拆成可完成的小块，完成后打勾，并让 GitHub 提交记录和博客更新成为外部反馈。

---

三、提有质量的问题，给认真的反馈

我快速阅读了《构建之法》，结合自己的经验和课堂实践，提出下面 5 个问题。

问题 1：软件工程的目标是创造“足够好”的软件，那么“足够好”到底由谁定义？

出处：第 1 章“概论”，书中讨论“软件工程的目标是创造足够好的软件”。
我的困惑：如果由开发者定义，容易走向过度设计或自嗨；如果由用户定义，用户往往只能描述表面需求。那么，在需求不清晰、时间有限的情况下，应该如何用工程方法找到这个“足够好”的边界？
我的分析：我认为“足够好”不能靠感觉，而应该通过用户故事、验收标准、风险排序和迭代反馈来逐步逼近。这与敏捷开发“尽早交付可运行版本”的思想一致。

问题 2：“分析麻痹”和“敏捷迭代”之间如何平衡？

出处：第 3 章“软件工程师的成长”，书中提到软件工程师的思维误区之一“分析麻痹”。
我的困惑：如果过度强调“先想清楚再动手”，可能迟迟不开始；如果过度强调“先做出来再改”，又可能造成返工。
我的分析：我认为关键不是非此即彼，而是把分析聚焦在“高风险、不可逆、影响大的部分”，把低风险决策留给迭代。可以用一个小原型验证关键假设，而不是一开始就写完整设计文档。

问题 3：结对编程真的能提高效率吗？

第 4 章"两人合作"介绍了结对编程（驾驶者 + 领航员）这种模式，书中认为它能够提升代码质量和知识共享。

我的疑问：两个人一起写一行代码，理论上是一个人打字、一个人看，那岂不是"两个人的活变成一个人的产出"？我在网上也看到过相反的说法，有人认为结对编程浪费人力、降低效率，只适合特定的教学或培训场景。我的经验是：我习惯一个人盯在屏幕前写，一边写一边卡壳；如果有人能实时在旁边盯着我去纠正，我觉得我的出错率会下降不少，但速度确实会慢。那么结对编程的"效率损失"到底值不值得？在真实团队里它是常态，还是仅在某些关键任务上使用？ 这是我不太懂、想听听大家看法的地方。

问题 4：用户表达的需求，是否就是软件应该实现的需求？

出处：第 8 章“需求分析”，书中讨论需求调研、用户需求和产品需求之间的关系。
我的困惑：用户常说“我要一个功能”，但真正的问题可能是“我想更快完成某个工作”。如果直接照用户说的做，很容易做出功能齐全但没人真正使用的软件。
我的分析：我认为需求分析的核心是把“用户表达”转成“问题定义”，再转成“可验证的解决方案”。这个过程需要访谈、观察、原型和反馈，而不是只记录用户的原话。

问题 5：学生阶段做项目，更应该追求“持续创新”还是“颠覆式创新”？

出处：第 16 章“IT 行业的创新”，书中区分了持续创新与颠覆式创新。
我的困惑：大学生常被鼓励“做点不一样的”，但如果基础不牢，追求颠覆式创新往往只是把已有方案重新包装。
我的分析：我认为学生阶段应先追求“可靠的持续改进”，把一个小问题做深、做透；只有当积累足够多真实用户反馈后，才可能发现真正具有颠覆性的机会。否则，创新容易变成缺少依据的拍脑袋。

认真反馈

关于课堂提问和反馈，我的做法是：

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

我会尽量把问题写具体，避免只问“这个怎么做”，而是写成“我读到这里，不理解 X；我尝试了 Y；目前卡在 Z”。

---

四、前车之鉴：从别人的经验里学习

1. 辜新星：时刻调整方向，找到人生的蓝海

链接：https://book.douban.com/subject/4006425/discussion/22803733/

这篇文章让我印象最深的是他把每天的事情分成 A、B、C、D 四类：紧迫且重要、重要不紧迫、紧迫不重要、不重要不紧迫。我以前做计划时，常常把“马上要交但不重要”的事排在“重要但不紧迫”的事前面，结果整天很忙，却没有真正进步。
我的改变是：每天先花几分钟给任务分类，把长期价值高但不紧急的事（例如刷算法、写博客）放进固定时间段，而不是等它变成紧急任务后再补救。

2. 刘帅：在失望中寻找希望

链接：https://book.douban.com/subject/4006425/discussion/22803961/

作者说自己虽然是计算机科班出身，却“没学懂计算机”。原因不是不努力，而是长期采用机械记忆、只看答案、缺乏主动思考的学习方式。这让我警惕：完成作业不等于掌握知识。
我的做法是：以后学习算法和数据结构时，不能只把书上的代码抄下来，而要自己先尝试实现，再对照标准答案复盘。即使做得慢，也要保留自己思考的过程。

3. 自由飞：野生程序员优先招聘

链接：https://www.cnblogs.com/freeflying/p/4796369.html

作者以文科生转编程的经历说明，是否能成为合格开发者，最终看的是学习能力、持续练习和解决真实问题的能力，而不是单一地看专业出身。虽然他的部分观点比较尖锐，但对“大学知识也可以自学”的强调提醒了我：课堂之外，我还要主动构建自己的知识地图。
我的思考是：科班身份最多是起点优势，不能成为偷懒理由。我会把专业课程、项目实践和英文资料阅读结合起来，用作品证明能力。

五、要求

1.博客中附加后台博文编辑界面的截图：

2.Github截图：

github地址：
https://github.com/zzy685/ZZY685/blob/main