软件工程第一次作业

第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标	学会使用博客、Markdown 写作 和 GitHub，对自己的专业能力、课程计划和未来方向做一次认真梳理。阅读《构建之法》并提出有质量的问题。

一、介绍自己

大家好，我是冯柏森，目前就读于广东工业大学。这是我在博客园发布的第一篇正式随笔。以前我更多是把学习内容写在本地笔记、Word 文档或者聊天记录里，很少把自己的学习过程公开整理出来。通过这次作业，我开始意识到：写博客并不只是为了完成任务，它更像是给自己留下学习轨迹。

我认为写博客至少有三个意义。

第一，写博客可以倒逼自己把知识讲清楚。平时我以为自己懂了一个知识点，但真正要写出来时，才会发现很多地方只是“感觉学懂了”，并没有形成自己的知识体系。

第二，写博客可以积累个人作品。无论找实习、做项目，还是读研深造，一个长期维护的技术博客都可以展示自己的态度和成长过程。

第三，写博客可以练习公开表达。IT 行业不是只会写代码就够了，还需要我能写文档、能沟通需求、能解释方案、能复盘问题。博客正好是一个低成本的训练场。

我的一个闪光点是唱歌。

我并不是一开始就擅长它，也不算特别擅长它。刚开始的时候，我被分到高音部。面对高音声部的谱子，我拼尽嗓子才能唱出来；我一开始也认为自己唱不了，但在声乐老师的指导和自己的持续练习下，半年后，我完全适应了高声合唱，并且代表学校参加了合唱比赛。这个过程让我明白：所谓优势并不一定是天生的，很多时候是通过持续投入慢慢积累出来的。

二、现状、经验和计划

2.1 我为什么选择这个专业

我选择计算机科学与技术的原因，主要有以下几点。

首先，因为热爱。很多想法都可以通过代码快速变成可以运行的程序。写出一个能解决问题的小工具，或者完成一个可以展示的项目，会带来很强的成就感。

其次，我也考虑到未来就业和发展空间。无论是互联网、人工智能、软件开发、数据分析，还是传统行业的信息化建设，都离不开计算机技术。因此，这个专业给了我比较多的选择。

但是，离成为一个合格的 IT 专业毕业生，我还有明显差距。具体来说，我认为自己主要差在以下几个方面：代码量还不够，项目经验不足，算法和数据结构掌握还不扎实，表达和协作能力也需要继续训练。

2.2 技能调查与自我评估

技能	目前水平	课程结束目标	提升计划
编程能力	3	5	每日完成Leetcode题目x3
数据结构与算法	3	5	复习408内容，并配合刷题
Git / GitHub 使用	2	5	熟悉 commit、branch、push、pull request
软件工程基础	2	5	阅读《构建之法》，理解需求、设计、测试、团队协作等概念
调试与测试能力	1	5	写代码时主动设计测试用例，记录 bug 和修复过程
文档写作能力	4	6	参考优秀开源项目的Markdown文档
团队沟通能力	3	5	在小组项目中主动沟通进度，学习用文档和会议同步信息

2.3 为什么要来上课并认真参与

我认为，上课并不是简单地“坐在教室里听老师讲”。如果只是被动听课，学习效果往往很有限。真正有效的学习应该包括预习、听课、实践、提问、反馈和复盘。

我来上这门课，是因为软件工程不是一门只靠自学语法就能掌握的课程。编程语言可以自己看视频学，但软件工程更强调如何把一个想法变成可靠的软件，如何和别人协作，如何控制项目进度，如何处理需求变化，如何测试和维护。这些内容如果没有真实任务和课程要求，很容易被忽视。

对于“认真参与”，我的理解是：不一定一开始就很强，但要愿意投入时间，愿意面对困难，愿意把作业认真做完。软件工程课程可能会比普通理论课更麻烦，因为它要求写代码、写博客、做项目、交流反馈。但也正因为麻烦，它才更接近真实的软件开发。

2.4 我希望的师生关系

在大学中，我体验过几种不同的师生关系。有些课是老师讲、学生听，期末考试结束后这门课也就结束了；有些课则更强调互动、作业和实践，老师像教练一样不断指出问题，让学生在训练中提高。

我更希望这门课采用类似“教练和运动员”的师生关系。老师不是简单地把知识讲完，而是通过任务、项目、反馈和要求，帮助学生真正提高能力。学生也不能只等老师喂答案，而应该主动训练、主动提问、主动改进。

如果老师布置的作业对我来说有些困难，我会选择：

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

当然，现实中我可能也会有拖延和畏难情绪，但我认为不能因为难就放弃。软件工程本来就是解决复杂问题的学科。如果每次遇到困难都逃避，以后面对真实项目也很难胜任。

2.5 引用、参考与抄袭的区别

在学习和工作中，我们经常需要引用文献、参考资料、复用开源代码，或者在别人已有工作的基础上继续开发。我认为这些行为和抄袭、剽窃的关键区别在于：是否诚实说明来源，是否真正理解内容，是否加入自己的工作，是否遵守规则和协议。

我觉得：

合理引用是指：我使用了别人的观点、数据、代码或图片，并清楚标明来源，同时说明这些内容在我的工作中起到什么作用。

参考资料是指：我通过阅读别人的文章或代码获得启发，但最终用自己的理解重新组织内容，形成自己的表达或实现。

而抄袭、剽窃则是：直接复制别人的内容，却假装是自己完成的；或者只是简单改几个变量名、改几句话，就当作自己的成果。这种行为不仅不诚信，也会让自己失去真正学习的机会。

在这门课中，我会尽量做到：引用资料标明链接，参考代码注明来源，团队合作说明每个人贡献，使用 AI 工具时不把 AI 生成的内容直接当作完全由自己独立完成的成果。

2.6 我为未来做什么准备

几年后，我可能会选择就业。目前我更倾向于提高工程能力，争取找到一份软件开发或人工智能相关实习。

在这个选择下，我认为自己相比其他同学有一些优势，也有一些劣势。

我的优势是：

1. 我愿意承认自己的不足，不会假装自己已经很强。
2. 我有一定的自学能力，遇到问题会尝试查资料解决。
3. 我比较重视记录和总结，愿意通过博客整理学习过程。
4. 我对技术方向有兴趣，希望能通过项目看到实际成果。

我的劣势是：

1. 代码量还不够，很多知识停留在“知道”而不是“熟练使用”。
2. 项目经验不足，对真实开发流程理解不深。
3. 做事有时会分心，计划制定得很好，但执行不够稳定。
4. 遇到复杂问题时，容易焦虑，而不是拆解问题，从小到大。

针对这些情况，我给自己本学期的规划是：

• 每周保证固定时间学习软件工程课程。
• 每次作业尽量提前完成，不拖到最后一天。
• 把课程项目当作真实项目来做，不只追求能交差。
• 每周至少一次整理博客或学习笔记。
• 主动学习 Git、GitHub、测试、文档写作等工程能力。
• 遇到不会的问题，先独立思考和搜索，再向老师、助教或同学请教。

三、我在这门课的计划

3.1 我对课程的期待

我希望这门课不仅教我“软件工程是什么”，更能让我真正体验一次软件开发的过程。我期待课程中能有比较真实的项目任务，让我从需求分析、设计、编码、测试、发布、复盘等环节中理解软件工程。

我也希望老师和助教能给出具体反馈。比如博客哪里写得空泛，代码哪里不规范，项目哪里考虑不完整，团队协作哪里有问题。这样的反馈虽然有时会让人不舒服，但比只给一个分数更有价值。

我不想当助教。我没有这么多精力担任，且以我目前的能力来看，我还需要先把自己的基础打牢。

3.2 我目前的代码量

目前我的代码量大约如下：

语言 / 类型	估计代码量
C / C++	20000 行
Python	3000 行
Markdown / 文档	15000 行

这些代码量中，有一部分是课程作业，有一部分是OJ代码，还有一部分是个人项目。坦白说，我目前的代码量还不够，尤其是完整项目代码比较少。很多时候我只是写过某个知识点的练习，但没有把它们组合成一个真正可用的系统。

我认为，为了有资格入职一流的软件公司、互联网公司或人工智能公司，不能只看代码行数，但代码量确实能反映实践程度。比较理想的情况是，在大学阶段至少积累几万行有质量的代码，并且有几个能展示的完整项目。

如果从事高校教学科研工作，除了代码能力，还需要论文阅读能力、数学基础、实验设计能力、英文写作能力和长期研究能力。代码量仍然重要，但更重要的是能否用代码验证想法、复现实验、改进方法。

3.3 每周投入时间

我计划平均每周拿出8h用于这门课，包括上课时间、阅读时间、写代码时间、写博客时间和团队协作时间。

如果前两年我确实浪费了一些时间，那么这学期我不能只停留在口头上说“我要努力”。我会选择：

D：比以前课要多很多，直到达到目标为止。

我知道这个选择并不容易，因为坚持比立 flag 难得多。所以我会把目标拆小，不靠一时热情，而是靠每周固定执行。

3.4 本课程结束时的代码量目标

我计划在本课程结束时，新增代码量达到12000行左右。按照一个学期计算，平均每周需要完成大约750行代码。

这里的代码量不是指复制粘贴，也不是指无意义堆行数，而是指自己理解后写出的、和课程项目或练习相关的有效代码。除了代码量，我还会关注代码质量，例如命名是否清楚、结构是否合理、是否有必要的注释和测试。

四、使用 WOOP 方法制定课程计划

4.1 Wish：我的愿望

我在这门课程中的愿望是：通过一学期的学习，真正理解软件工程的基本过程，并完成一个可以展示的项目，同时养成写博客、用 GitHub 管理代码、主动复盘的习惯。

这个愿望比较具体，不只是“我要学好软件工程”，而是要落实到项目、代码、博客和工具使用上。

4.2 Outcome：愿望实现后的结果

如果这个愿望实现了，我希望学期结束时能看到几个明显变化。

第一，我的 GitHub 主页不再是空的，而是有持续提交记录和可展示项目。

第二，我的博客园不再只有一两篇作业文章，而是能看到自己从不会到逐渐熟练的过程。

第三，我面对一个软件项目时，不再只想着“先写代码”，而是会先思考需求、设计、测试、分工和维护。

第四，我的表达能力会有所提高，能够把一个技术问题讲清楚，而不是只会说“我大概懂了”。

如果能做到这些，即使我的水平还没有达到很高，我也会觉得这个学期是有收获的。

4.3 Obstacles：可能遇到的障碍

我认为最可能妨碍我完成目标的因素是：不能长期自律，容易拖延。

具体表现是：刚开始计划很认真，但过几周后，如果其他课程作业变多，或者项目遇到困难，我可能会开始拖延。比如本来计划周三完成代码，结果拖到周末；本来计划写博客复盘，结果觉得麻烦就省略；本来遇到 bug 应该认真调试，结果开始刷手机逃避。

这个问题的本质不是我不知道应该学习，而是执行力不稳定，容易被短期轻松的事情吸引。

4.4 Plan：if-then 风险防范计划

为了克服这个问题，我制定以下 if-then 计划：

1. 如果我发现自己连续 10 分钟没有推进作业，只是在刷网页或看手机，那么我就立刻离开座位 10 分钟，回来后只做一个最小任务，例如写完一个函数或提交一次 commit。
2. 如果我在代码问题上卡住超过 20 分钟，那么我就把问题写成文字，包括报错信息、我尝试过的方法和目前猜测，然后再去搜索或请教同学。
3. 如果我到了周五还没有完成本周课程任务的一半，那么周末第一件事必须先处理软件工程作业，不能先安排娱乐活动。
4. 如果团队项目中我负责的部分无法按时完成，那么我会提前告诉队友，而不是等到最后一天才说明情况。

我希望通过这种具体计划，减少“想努力但做不到”的情况。

五、阅读《构建之法》后提出的 5 个问题

以下问题来自我快速阅读《构建之法》后的思考。因为目前我对软件工程的实践经验还不够，所以有些问题可能比较初步，但它们确实反映了我阅读时的困惑。

问题一：第 1 章“概论”——软件工程会不会让小项目变复杂？

书中强调软件不仅仅是程序，还包括软件工程中的需求、设计、测试、维护、团队协作等内容。我的疑问是：对于一个很小的个人项目，是否也需要完整的软件工程流程？如果流程太多，会不会反而降低效率？

我提出这个问题，是因为我以前写小程序时，通常是想到哪里写到哪里，很少提前写需求文档或测试计划。对于几十行、几百行的小程序，这种方式好像也能完成任务。但是如果项目变大，这种随意写法就可能导致代码混乱、后期难以维护。

所以我的理解是，软件工程并不是要求所有项目都使用同样复杂的流程，而是要根据项目规模选择合适的方法。小项目可以简化流程，但仍然应该保留一些基本习惯，比如明确目标、记录问题、使用版本管理、做基本测试。

我的困惑是：作为初学者，如何判断一个项目应该使用多严格的软件工程流程？有没有一个适合学生小项目的最低标准？

问题二：第 3 章“软件工程师的成长”——代码量和能力之间是什么关系？

第 3 章讨论软件工程师的成长，这让我想到一个问题：代码量是否真的能代表一个人的编程能力？

一方面，我认为代码量很重要。没有足够练习，就很难真正掌握编程。很多语法、调试技巧、工程习惯，只有在不断写代码时才能形成。

但另一方面，如果只是机械地堆代码行数，复制粘贴很多重复内容，也不一定能提高能力。真正有价值的代码量，应该是自己理解后写出来的，并且经历过调试、测试和修改。

所以我目前的观点是：代码量不是能力的全部，但它是能力成长的重要基础。没有代码量，谈工程能力容易变成空话；只有代码量，没有总结和质量意识，也很难成为合格的软件工程师。

我的问题是：对于大学生来说，怎样的代码量才算“有效代码量”？课程是否应该更强调代码质量、项目完整度，而不是单纯统计行数？

问题三：第 5 章“团队和流程”——团队合作中，个人能力强是否一定是好事？

第 5 章涉及软件团队和流程。我读到团队相关内容时想到：在团队项目中，一个能力特别强的人是否一定能让团队变得更好？

从直觉上看，团队中有强者当然是好事，因为他可以解决难题，提高项目质量。但如果这个人不愿意沟通，或者把所有重要部分都自己完成，其他成员可能会失去参与感，团队也可能形成依赖。一旦这个人离开，项目就很难继续维护。

反过来，如果团队成员能力平均但沟通顺畅，分工明确，也许项目推进会更稳定。

因此，我认为软件团队不只是把几个会写代码的人放在一起，更重要的是让每个人知道自己负责什么、什么时候交付、遇到问题怎样同步。

我的问题是：团队项目中应该如何平衡“效率”和“共同成长”？如果一个人写得最快，是应该让他多写，还是应该让其他同学也承担关键任务？

问题四：第 9 章“项目经理”——PM 不写代码，为什么仍然重要？

第 9 章提到项目经理相关内容。我的疑问是：如果 PM 不直接写代码，那他的价值主要体现在哪里？

作为学生，我以前容易认为项目中最重要的人就是写代码的人，因为代码最终决定程序能不能运行。但阅读后我发现，一个项目能否成功，不只取决于代码，还取决于需求是否清楚、进度是否合理、沟通是否顺畅、风险是否被提前发现。

如果没有人负责协调，团队可能会出现这些问题：大家都在写代码，但写的方向不一致；需求变化了，但有人不知道；某个模块延期了，却没有提前暴露；最后集成时才发现接口对不上。

所以我开始理解 PM 的作用：他不一定直接产出代码，但他要保证团队朝同一个目标前进。

我的问题是：在学生团队项目中，PM 应该由能力最强的人担任，还是由沟通能力和责任心更强的人担任？如果 PM 技术能力不够，会不会影响判断？

问题五：第 16 章“IT 行业的创新”——创新是靠灵感，还是靠长期积累？

第 16 章讨论 IT 行业的创新。我的问题是：创新到底主要来自突然的灵感，还是来自长期积累后的结果？

以前我对创新的理解比较简单，觉得创新就是突然想到一个别人没想到的点子。但现在我觉得，真正有价值的创新往往不是凭空出现的，而是建立在对用户需求、技术能力、行业问题和已有方案的长期理解上。

比如一个软件产品的创新，可能不是发明全新的技术，而是把已有技术用在更合适的场景中，或者把用户体验做得更好，或者把一个复杂流程变得更简单。

我的困惑是：对于基础还不够扎实的大学生来说，应该怎样训练创新能力？是先大量学习和模仿，还是一开始就尝试做与众不同的东西？

我目前的看法是：初学阶段可以先模仿优秀作品，理解别人为什么这样设计；等基础更扎实后，再逐步尝试改进和创新。没有基础的创新，可能只是空想；没有创新意识的学习，也可能只是重复劳动。

六、我会如何认真反馈

对于课程反馈，我会选择：

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

如果后续我对课程有更多想法，也希望能逐渐做到 D：经常提问题，平时就给老师和助教提反馈。

我认为反馈不是挑刺，而是帮助课程变得更好。学生认真反馈，老师才能知道哪些地方讲清楚了，哪些地方还需要调整。对学生来说，提问和反馈也是一种主动学习。只有把自己的困惑说出来，才有机会得到更具体的帮助。

七、前车之鉴：阅读前人经验后的感想

7.1 关于时间管理

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

这篇文章提到把每天要做的事情分成 ABCD 四类：

• A：紧迫且重要；
• B：重要但不紧迫；
• C：紧迫但不重要；
• D：不重要也不紧迫。

我以前也尝试过列计划，但经常只是简单写一个待办清单，没有区分事情的重要程度。结果就是：我很容易先做简单的、马上能完成的事，而把真正重要但有难度的事情拖到最后。

比如学习编程就是典型的 B 类事情。它很重要，但很多时候不紧迫。如果没有考试或作业逼着我，我可能就会拖延。可是从长期来看，真正决定能力差距的，恰恰是这些重要但不紧迫的事情。

这篇文章给我的启发是：不能只被截止日期推着走。软件工程这门课中，写代码、读书、写博客、复盘项目，很多都需要提前做。如果总是等到最后一天，质量一定不会高。

所以我打算以后每周开始时先区分任务优先级，把软件工程课程中的项目推进、代码练习和博客复盘放到比较重要的位置，而不是等快截止了才处理。

7.2 关于“科班但没学懂计算机”

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

这篇文章让我有些共鸣。作为计算机相关专业的学生，有时候我们会觉得自己“应该懂计算机”，但真实情况可能是：很多课程学过了，却没有真正掌握；很多概念听过了，却不会应用；很多代码写过了，却不能独立完成一个项目。

我觉得这种问题的原因之一是学习方式太被动。有些课程结束后，我只记得考试重点，却没有形成系统能力。比如数据结构学过链表、栈、树、图，但如果真正让我从零实现一个完整功能，我可能还是会卡住。

这篇文章提醒我：科班出身只是一个起点，不是能力保证。真正的能力来自持续实践、主动学习和不断总结。如果只满足于“我上过这门课”，而不去问“我能不能用它解决问题”，那就很容易变成表面学习。

因此，在这门软件工程课中，我希望自己不要只追求分数，而是要真正通过作业和项目补上工程实践这一课。

7.3 关于实习经验和自学摸索

阅读链接：
https://www.cnblogs.com/xiaozhi_5638/p/4485805.html

这篇文章让我思考一个问题：实习经验对应届生到底重不重要？我认为答案是重要，但实习并不是唯一标准。真正重要的是有没有接触过真实问题，有没有经历过需求变化、代码协作、bug 修复、项目交付这些过程。

学校里的课程项目和企业实习当然不完全一样，但课程项目可以提前训练很多基础能力。例如：如何用 Git 协作，如何拆分任务，如何写文档，如何测试，如何按时交付。这些能力如果在学校阶段完全没有训练，到了实习或工作中就会很吃力。

这篇文章也让我意识到，自学摸索很重要，但不能只靠碎片化学习。看视频、看教程、收藏资料都不等于真正掌握。必须通过项目把知识串起来，才能形成能力。

所以我希望自己本学期能把软件工程课程项目当成一次“小型实习”来对待，不只是完成老师要求，而是尽量按照真实开发的方式要求自己。

八、总结

通过这次作业，我第一次比较系统地思考了自己为什么学习这个专业、目前差在哪里、这门课应该怎么学、未来想往哪里走。

我最大的感受是：软件工程课程不是一门可以轻松混过去的课。它要求我们写代码、读书、写博客、做项目、提问题、给反馈。这些事情看起来很杂，但其实都指向同一个目标：让我们从“只会写一点代码的学生”，逐渐成长为“能参与真实软件开发的人”。

我目前还有很多不足，比如代码量不够、项目经验不足、自律不稳定。但至少从这篇博客开始，我希望自己能把学习过程记录下来，把计划落实到每周行动中。

接下来，我会努力做到：

1. 按时完成每次作业；
2. 坚持使用 GitHub 管理代码；
3. 每周投入固定时间写代码和复盘；
4. 遇到问题主动搜索、提问和总结；
5. 把课程项目当成真正的工程训练。

希望在学期结束时，我能回头看到自己确实进步了，而不是只留下几句空洞的口号。

九、注释

编辑界面

Github页面