第一周作业

软件工程课程第一次博客作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标	熟悉博客园写作与Markdown排版，建立个人GitHub仓库，通过阅读与反思明确学习目标与计划

一、关于我自己

我是谁

我是陈信儒，是一名计算机科学与技术专业的学生。选择这个专业，最初大概是因为对编程的好奇，但在学习的过程中，逐渐感受到了代码世界的魅力与挑战。

我的闪光点

我没什么特别擅长的，我认真想了一下，我相对擅长的方面是：观察与思考的习惯。在日常生活中，我比较留意身边的人和事，也习惯对观察到的东西多想一层。学习的效果，很大程度上取决于你有没有在观察自己的学习过程。来到大学后，面对计算机专业大量的新知识，我依然在用这种“边做边想”的方式——遇到不会的知识先思考“卡在哪里”，调试bug时多问几个“为什么会出现这个现象”，而不是盲目尝试直到“碰巧”跑通。如果说这算一种闪光点的话，它并不是天赋，而是一种可以培养的意识——停下来想一想，而不是一味往前赶。

为什么写博客

说实话，以前我也觉得写博客是件麻烦事——有这时间不如多敲几行代码。但读了学长们的经历后，我逐渐认同一个观点：“写下来，才是自己的”。学习过程中产生的思考如果不记录下来，很快就会遗忘；而写博客的过程本身就是在整理思路、加深理解的过程。

我希望通过这个课程，养成定期写作和总结的习惯。哪怕一开始写得不好、内容不多，坚持一段时间再看效果。

二、现状、经验和计划

（1）专业选择与技能现状

为什么选择这个专业？

说实话，当初选择计算机专业，并没有太多“改变世界”的宏大理想。和很多同学一样，中学时期接触电脑主要就是打游戏，觉得计算机挺神奇的，就报了计算机专业。真正开始学之后才发现，打游戏和写代码完全是两回事。

但随着学习的深入，我逐渐感受到编程的魅力——当你花几个小时解决了一个bug，看到程序按预期运行的那一刻，确实有一种成就感。虽然我还不敢说自己“热爱”编程，但至少不排斥，并且愿意投入时间去学好它。

离合格毕业生还差什么？

参照技能调查表，我认为以下技能对我特别重要，并评估了自己的水平与目标：

技能项	当前水平(0-9)	目标水平(0-9)	提升计划
编程语言（Java/C/Python）	4	7	每周至少完成3道编程题，参与课程项目开发
数据结构与算法	3	7	系统学习，课后刷题
软件工程方法与工具（Git/调试/测试）	3	7	在课程项目中使用Git，学习单元测试
数据库设计与SQL	3	6	完成数据库课程项目，练习复杂查询
网络基础与协议	3	6	结合课程实验，深入理解TCP/IP
需求分析与系统设计	2	6	参与团队项目，学习撰写需求文档
自主学习与信息检索	5	8	养成阅读官方文档和技术博客的习惯

（2）阅读与思考

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

上课的意义不在于“听老师讲完”，而在于“与老师产生互动”。纯粹看视频自学可能也能学会一些知识，但课堂提供的即时反馈、同学间的讨论、老师的经验分享，是视频无法替代的。尤其是软件工程这类实践性强的课程，很多经验是书本上没有的，需要在与老师的交流中获得。

b) 师生关系与遇到困难时的选择

在大学中，我体验过几种师生关系：有的老师像“导演”，把一切安排得井井有条；有的老师像“朋友”，和学生打成一片。我希望这门课是健身教练与学员的关系——老师给出训练计划和方法，指出我的问题，但真正流汗、真正练习的人是我自己。

如果作业对我来说有些困难，我会选向老师和同学请教，花更多时间，把作业全部完成。我始终相信，觉得难才说明在进步。

c) 引用与抄袭的区别

在工作中引用文献、参考别人代码是正常的，但抄袭和剽窃的区别在于：是否标明出处，是否把别人的成果当作自己的。引用是在别人工作的基础上继续开发，并明确说明参考了谁的工作；抄袭则是直接复制粘贴，不注明来源，假装是自己写的。

我会严格遵守课程关于学术诚信的要求，所有引用的代码和资料都会标注来源。

（3）未来规划与准备

几年后，我倾向于进入企业做软件开发。

为什么选这个方向？

相比理论研究，我更喜欢动手做出实际产品，所以打算毕业后进入企业从事软件开发工作。

相比其他同学的优势与劣势：

• 优势：我有较强的自学能力和复盘习惯，遇到问题愿意花时间钻研
• 劣势：我的代码量还不够，项目经验相对缺乏，对一些工程化工具不熟悉

本学期的规划：

1. 认真完成软件工程课程的所有作业和项目
2. 积极参与团队项目，锻炼协作能力
3. 每周至少额外投入5小时进行编程练习
4. 养成写技术博客的习惯

（4）课程计划

代码量现状与目标：

我目前的代码量大约1800行（包括课堂练习和课外练习）。为了有资格入职一流的软件公司，我了解到至少需要上万行的代码量积累，而且要涉及不同的项目类型。我计划在本课程结束时，新增2000-3000行代码。

每周时间投入：

我选择 比以前课要多很多，直到达到目标为止。前两年确实有一些时间被浪费了，现在需要补回来。我计划每周拿出10小时用在这门课上。

WOOP计划：

• Wish（愿望）：在课程结束时，能独立完成一个完整的软件项目，从需求分析到部署上线全流程走通。
• Outcome（结果）：如果能做到，我会对软件开发流程有完整的理解，在求职时能有拿得出手的项目经验，更重要的是建立起“我能做出来”的信心。
• Obstacles（障碍）：最大的障碍是拖延和分心——写着写着就去刷手机、看视频，一两个小时就过去了。其次是遇到困难容易产生畏难情绪，想着先放一放，结果一放就是好几天。
• Plan（计划）：如果我在写代码时忍不住想刷手机，那么我就把手机放到另一个房间，给自己设定25分钟的专注时间，完成后再休息5分钟。如果遇到卡住的问题超过30分钟还没思路，那么我就记录下来，去请教同学或老师，而不是一直死磕或干脆放弃。

三、对《构建之法》的五个提问

快速通读《构建之法》后，我提出了以下五个问题。

问题一（第2章 个人技术和流程）

原文：第2章介绍了单元测试、回归测试、效能分析等个人开发流程，强调“工程师应该用单元测试保证代码质量”。

我的问题：单元测试在实际开发中真的那么重要吗？我见过一些学长做项目时几乎不写测试，靠“手动点一点”就上线了。如果项目规模不大，写单元测试的成本是不是大于收益？

我的思考：从理论上讲，单元测试确实能保证代码质量、方便后续修改。但在实践中，尤其是课程项目或个人项目，时间有限的情况下，我往往会选择先写功能代码，测试“有空再补”——然后就没有然后了。我想知道，对于学生阶段的项目，应该以什么标准来要求自己写测试？是每个函数都要测，还是只测核心逻辑？希望能在课程实践中找到答案。

问题二（第5章 团队和流程）

原文：第5章讨论了各种软件开发流程模型（瀑布、敏捷、MSF等），指出“不同项目需要不同的流程”。

我的问题：书上讲了这么多流程模型，但实际中一个学生团队做课程项目，到底应该用哪种？敏捷开发强调“快速迭代、响应变化”，但学生团队往往是课余时间零散协作，没有每日站会，没有产品负责人，这样的条件下敏捷还能落地吗？

我的困惑：我看过一些同学的课程项目，说是用了“敏捷开发”，实际上就是建了个微信群，想起来就发个消息。这算敏捷吗？还是说学生项目根本不需要纠结流程，先把东西做出来再说？流程和“把事情做完”之间，如何找到平衡点？

问题三（第8章 需求分析）

原文：第8章提到“用户的需求往往不是他们说的那样，需要分析师深入挖掘”。

我的问题：在学生项目中，用户往往就是“我们自己”或者“老师”，需求相对明确。但在真实的商业环境中，用户可能根本说不清楚自己想要什么。作为一个刚入行的开发者，如何在缺乏经验的情况下做好需求分析？

我查的资料：我读到一些实习生的分享，说他们在公司里经常遇到需求变来变去的情况，有时候开发了一周的功能，产品经理说“这个不要了”。这让我对需求分析的重要性有了更直观的认识——不是技术难，而是“做什么”比“怎么做”更难确定。

问题四（第11章 软件设计与实现）

原文：第11章讨论了设计模式，指出“设计模式是前人总结的 reusable solutions”。

我的问题：初学者应该什么时候开始学习设计模式？我看到有些同学为了“用设计模式”而用设计模式，把简单的代码搞得非常复杂。另一方面，如果不学设计模式，写出来的代码确实容易变成“面条代码”，难以维护。

我的经验：我写过一个课程项目，刚开始时所有逻辑都堆在一个类里，后来需求一改，改得我头疼。那时我才意识到“高内聚低耦合”不是空话。但我又担心过度设计——在需求还不明确的时候就套用各种模式，反而让代码难以理解。这个度该怎么把握？

问题五（第16章 创新）

原文：第16章讨论了创新的本质，指出“创新不是灵光一现，而是长期积累的结果”。

我的问题：作为一个普通学生，我经常觉得自己“没有创新的天赋”。看到别人做出有意思的项目，会觉得“我怎么就想不到”。书中说创新可以培养，但具体应该怎么培养呢？是广泛阅读、多做项目、还是多和人交流？

我的反思：我注意到身边有些同学想法特别多，总能提出新颖的点子；而我更擅长的是“把别人提出的想法执行好”。这是不是意味着我不适合做创新性的工作？还是说创新的能力可以通过训练获得？希望能在课程中慢慢找到答案。

四、前车之鉴——阅读感想

感想一：《把每天把要做的事情分成ABCD四类》

参考文章：辜新星：时刻调整方向 找到人生的蓝海

这篇文章提到将每天的事情分成四类：A-紧迫且重要；B-重要不紧迫；C-紧迫不重要；D-不重要不紧迫。我反思了一下自己的时间管理，发现大部分时间都花在了C类和D类事情上——比如刷社交媒体、看短视频，这些事情看起来很“紧迫”（因为通知一直在弹），但实际上既不重要也不紧迫。

而真正重要的B类事情——比如系统学习一门技术、做项目积累经验——因为不紧迫，总是一拖再拖，直到变成A类（期末考试前临时抱佛脚）。我决定从这个学期开始，每天花10分钟做第二天的计划，把时间优先分配给B类事情。

感想二：《你是否也觉得自己是科班，但没学懂计算机？》

参考文章：刘帅：在失望中寻找希望

读这篇文章时，我有一种被“点名”的感觉。虽然我是科班出身，上过数据结构、操作系统、计算机网络这些核心课程，但说实话，很多知识只是“知道个名字”，远没有达到“理解”的程度。考试能过，但让我从零实现一个简单的操作系统内核或者一个网络协议栈，我完全不知道从何下手。

这篇文章让我意识到，“学过”和“学会”是两码事。科班的优势在于有完整的课程体系，但如果不主动深入实践，这个优势就发挥不出来。我决定在接下来的学习中，每学一个重要的知识点，都尝试动手实现一个mini版本——比如学完网络协议后，自己写一个简单的聊天程序。

感想三：《把每天胡思乱想的东西记在一个笔记本上》

参考文章：徐宥：掉进读书的兔子洞

这篇文章提到把每天胡思乱想的东西记下来，作为“思维快照”，定期回顾自省。我平时也有随手记录的习惯——遇到不懂的概念、突然想到的问题、看到的好文章链接，都会记在手机备忘录里。但问题是，记完就忘了翻看，那些“思维快照”变成了“思维坟墓”。

读了这篇文章后，我决定改变做法：每周日花半小时回顾这一周的记录，把有价值的内容整理到博客或笔记中，把已经解决的问题划掉，把还没解决的问题标注出来继续思考。这样记录才不会只是形式，而是真正帮助自己成长。

GitHub仓库

我已新建一个与自己GitHub ID一致的仓库，并在README中写下了个人介绍。

GitHub地址：https://github.com/xingwangxiang/xingwangxiang

截图如下：