软件工程第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	作业要求
这个作业的目标	熟悉 GitHub、Git 和博客园的基本使用，了解软件工程课程要求，分析自己的学习现状并制定本学期计划。

一、介绍自己，建博客

大家好，我目前是一名计算机科学与技术专业的本科生。我曾经是建筑与城市规划学院的学生，经过转专业来到了计算机学院进行学习。

最开始来到计算机学院的时候我也很迷茫，后来慢慢学习能够探索到计算机的奥秘时会很开心。

如果要说自己的一个优势，我觉得是比较愿意主动接触新的知识。当我对一个方向产生兴趣以后，我会主动查资料、看教程并尝试实际操作。例如在学习编程和人工智能相关内容时，我不仅希望知道“怎么使用”，也希望逐渐理解背后的原理。

当然，我目前也存在一些不足，例如有时学习的内容比较多，容易出现知识面扩展得比较快，但某些内容掌握得不够深入的问题。因此，我也希望通过写博客的方式，把学习过程中的问题、总结和思考记录下来。

我认为技术博客的意义并不只是完成课程作业。很多知识在刚学会的时候觉得自己记得很清楚，但是过一段时间以后就容易忘记。如果能够把学习过程整理成文字，不仅能够帮助自己重新思考，也可以在以后回顾自己的成长过程。

希望自己能够坚持记录，而不是只在有作业要求的时候才写博客。

二、现状、经验和计划

1. 专业选择与技能现状

我最初并不是一开始就确定要学习计算机，后来在接触编程和计算机相关知识后，逐渐发现自己对软件开发和人工智能方向更感兴趣，因此选择进入计算机科学与技术专业。

目前我已经学习过 C/C++、Python、数据结构、操作系统等课程，也完成过一些课程实验。但离一名合格的计算机专业毕业生还有明显差距，尤其是在独立开发、算法能力、工程实践和 Git 使用方面。

我对目前几项重要技能进行了简单评价：

技能	当前水平	课程结束目标
C/C++ 编程	4	6
Python 编程	4	6
数据结构与算法	3	6
Git / GitHub	2	6
软件工程实践	2	6
调试与解决问题能力	4	7
英文技术资料阅读	4	6

我计划通过以下方式提高自己的能力：

1. 每周保持一定的代码练习量，不只看代码，更要自己独立完成；
2. 继续巩固数据结构、操作系统等计算机基础知识；
3. 学习 Git 和 GitHub，并在项目中实际使用版本管理；
4. 完成至少一个较完整的软件项目，而不是只完成零散实验；
5. 遇到 Bug 时先主动查资料和调试，再向老师、同学和 AI 工具请教；
6. 阅读优秀开源项目，学习别人组织代码和解决问题的方法；
7. 通过博客记录自己的学习过程和遇到的问题。

2. 对课程、师生关系和学术规范的理解

为什么要认真参与课程

我认为大学课程真正的意义并不只是获得一个分数。如果只是为了考试而学习，那么课程结束后很多知识很快就会忘记。特别是软件工程这种实践性很强的课程，真正重要的是在完成项目、写代码和合作的过程中形成自己的能力。

因此，我希望自己在这门课中不是简单完成作业，而是尽量理解每一次作业为什么要这样设计，以及自己真正学到了什么。

我希望的师生关系

我比较希望老师与学生之间是一种“教练和学习者”的关系。老师指出方向、提出要求，而学生需要主动完成训练。

如果作业比较困难，我会选择 C，同时加上自己的处理方式：

先自己查阅资料、尝试解决。如果长时间没有进展，再向同学、助教或老师请教，在真正理解以后完成作业，而不是为了提交而直接复制别人的答案。

引用和抄袭的区别

我认为引用别人的资料本身并不是问题。软件开发本来就需要查阅文档、参考论文、阅读开源代码。

关键区别在于是否说明来源，以及自己是否进行了真正的理解和加工。

如果明确标注参考来源，并在此基础上进行自己的分析、修改和开发，这是正常的学习和研究；如果把别人的文字或代码直接复制下来，并声称是自己的成果，我认为这就是抄袭。

因此，在之后的课程作业中，我会尽量注明参考资料和代码来源，并避免直接复制他人的成果。

是否想当助教

目前我暂时没有担任助教的计划。

一方面，我觉得自己在软件工程实践、项目开发和专业基础方面还有不少需要提高的地方；另一方面，我现阶段更希望先把课程内容真正学懂，把自己的基础打牢。

如果以后自己的能力达到一定水平，我也愿意尝试帮助其他同学解决问题，因为在给别人讲解问题的过程中，也能够进一步检验自己是否真正理解了相关知识。

3. 未来选择与本学期计划

目前我比较希望继续深造，并进一步学习人工智能、计算机视觉等方向。因此本科阶段对我来说，最重要的还是打好计算机基础，同时积累项目和科研实践经验。

相比一些编程基础很强的同学，我的优势是目前对自己的发展方向比较明确，也愿意主动学习新的内容。

我的不足同样明显：计算机基础积累还不够深，算法和工程实践能力仍然比较弱，有时学习的方向比较多，容易出现“什么都了解一点，但没有真正学深入”的问题。

所以这个学期，我给自己的主要目标是：

• 认真完成软件工程课程；
• 提高 C/C++ 和 Python 编程能力；
• 熟悉 Git 和 GitHub；
• 巩固数据结构等基础知识；
• 完成一个可以真正展示的项目；
• 继续了解人工智能和计算机视觉相关内容。

4. 对本课程的计划与期待

我希望这门课能够让我从“会写一些程序”逐渐转变为“知道如何完成一个软件项目”。

除了写代码之外，我希望学习需求分析、团队合作、版本管理、测试和项目总结等真正的软件工程方法。

我目前没有对自己的历史代码量进行非常精确的统计。按照之前完成的课程实验粗略估计：

• C/C++：约 3000 行；
• Python：约 1000～1500 行；
• 其他课程代码：约 1000 行。

累计大约在 5000 行左右。

我认为代码量本身不是衡量程序员能力的唯一标准，但是足够的实践量仍然十分重要。对于希望进入优秀软件公司、互联网公司或者人工智能公司的学生，我认为本科阶段至少应该有 数万行真正理解并亲自完成的有效代码实践，同时拥有几个完整项目。

如果以后从事高校科研工作，代码量可能不是最重要的评价指标，但同样需要具备独立实现算法、复现实验和处理数据的能力。

这学期我计划平均每周投入 10 小时左右在软件工程课程中，包括上课、阅读、编程和完成作业。

在老师给出的选项中，我会选择：

D：比以前的课投入更多时间，直到达到自己的目标为止。

我希望课程结束时能够新增大约 5000～7000 行有效代码，平均每周完成约 300～400 行。我更关注的是代码是否真正理解，而不是单纯为了增加数字。

WOOP 计划

Wish —— 愿望

希望课程结束以后，自己能够独立完成一个较完整的软件项目，并熟练使用 Git 和 GitHub。

Outcome —— 结果

如果能够做到这一点，我不仅可以提高编程能力，也会拥有一个真正能够展示自己能力的项目，为之后的学习、实习和深造提供帮助。

Obstacles —— 障碍

我认为最大的障碍是容易同时学习很多东西，导致注意力比较分散；另外遇到复杂问题时，有时会在一个 Bug 上花费过多时间。

最可能导致失败的因素

最可能的问题不是不会，而是不能长期坚持。如果前几周投入很多时间，后面逐渐放松，那么学期结束时依然很难达到目标。

Plan —— If-Then 计划

如果我发现自己连续几天没有完成课程计划，那么我就减少其他不重要的学习内容，优先把软件工程课程任务完成。

如果一个程序问题独立调试很长时间仍然没有进展，那么我会先记录报错和已经尝试的方法，然后查阅资料，并主动向老师、同学或其他工具寻求帮助，而不是一直停留在原地。

三、《构建之法》阅读与思考

问题一：小型软件作坊真的能够在产品竞争力上与大公司抗衡吗？

出处：《构建之法》第 16 章，第 379 页。

在第 16 章关于软件作坊的讨论中，作者提到了“小即是美”的观念。这里让我产生了一个疑问：小型的软件作坊或者小团队，真的能够拥有和大型公司相近的产品竞争力和影响力吗？

我一开始的想法是，大公司拥有更多资金、人才、服务器资源、品牌影响力和用户渠道，因此从直觉上看，小团队似乎很难真正与大公司竞争。但进一步思考之后，我发现“小”本身似乎也可能成为一种优势。

例如，小团队人数较少，沟通链条短，在确定一个产品方向之后，可以比较快地做出决策和修改产品。相比之下，一个大型公司中的项目可能需要经过产品、开发、测试、管理等多个部门，很多决策需要层层沟通。因此，在产品刚开始探索市场的时候，小团队可能反而更加灵活。

现实中也确实出现过一些由很小团队开发，却产生巨大影响力的软件产品。例如 Instagram 在早期只有一个很小的团队，却获得了大量用户；WhatsApp 在发展过程中团队规模也远小于许多传统互联网企业。这似乎说明，软件产品的影响力并不一定与公司人数成正比。

但是我又觉得，这并不能完全证明“小即是美”。

因为这些小团队能够快速创新是一回事，能不能长期维持一个大规模产品又是另一回事。当一个软件拥有几千万甚至几亿用户以后，就会涉及服务器基础设施、安全、法律合规、客服、商业化以及全球市场运营等问题。这时大公司的资源优势可能会重新体现出来。

因此，我现在更倾向于认为：

小团队可能在“创新速度”和“产品探索”上拥有优势，但大公司在“规模化运营”和“长期资源投入”上拥有优势。

所以我真正困惑的是：作者所说的“小即是美”，究竟更适用于软件产品的创新阶段，还是意味着小型软件组织本身可以长期成为一种比大型公司更有效的软件开发模式？一个软件团队从“小而美”走向规模化之后，是否又不可避免地会出现大公司的管理问题？

问题二：为什么很多创新在刚出现时容易被拒绝或忽视？

出处：《构建之法》第 16 章，第 350 页。

在第 16 章关于创新价值的讨论中，作者提到，创新并不一定会在刚出现时就得到认可，有些创新甚至会遭到质疑、拒绝或者被忽视。

看到这里以后，我产生了一个疑问：

为什么一项后来被证明很有价值的创新，在刚出现的时候反而可能不被人接受？

我最开始认为，如果一个创新真的足够优秀，那么市场或者用户应该能够很快发现它的价值。但仔细思考以后，我发现现实可能没有这么简单。

首先，创新本身往往意味着不确定性。一个已经成熟的产品虽然可能存在缺点，但用户已经知道如何使用它，也已经形成了自己的习惯。一个新的产品即使在某些方面更优秀，也可能要求用户重新学习、改变习惯，甚至承担一定的风险。因此，用户拒绝创新，并不一定意味着这个创新没有价值，也可能只是因为“改变”本身需要成本。

其次，一些创新在早期阶段往往并不完善。新技术可能价格很高、体验不稳定，甚至看起来还不如原来的产品。只有经过不断改进以后，它真正的优势才会逐渐体现出来。因此，我们现在回头看某项技术时，很容易认为它的成功是必然的，但对于当时的人来说，他们面对的其实只是一个尚未成熟的产品。

我还想到一个问题：人们评价创新时，往往会使用已有产品的标准。

例如，一个全新的产品刚出现的时候，人们可能首先问：

“它和我现在使用的东西相比，到底好在哪里？”

但真正重要的创新可能并不是单纯把原来的产品做得更快、更便宜，而是改变了原来的使用方式。这样一来，用旧产品的标准评价一个新事物，本身就可能低估它的价值。

因此，我现在更倾向于认为：

创新的价值和创新被接受的速度并不是完全一致的。一个创新是否具有价值，与社会是否能够立即理解它的价值，是两个不同的问题。

但这又带来了一个新的困惑。

如果我们认为“真正的创新在早期经常不被理解”，那么是否意味着所有暂时不被接受的产品都可以声称自己只是“还没有被理解”？

显然不能。

所以我真正想知道的是：

在一项创新尚未获得市场认可的时候，我们应该通过什么标准区分“真正有潜力但暂时不被理解的创新”和“本身价值有限、只是没有人使用的产品”？

我认为这可能比“创新是否被认可”本身更加重要，因为创新者既不能因为暂时受到质疑就轻易放弃，也不能把所有失败都解释为“市场不理解创新”。

问题三：技术产品的发展真的一定会经历固定的五个阶段吗？

出处：《构建之法》第 16 章，第 368 页。

在第 16 章关于技术产品发展规律的讨论中，作者将一个技术产品的发展过程划分为 A、B、C、D、E 五个阶段。

读到这里时，我对这种划分产生了一些疑问。我能够理解作者试图通过几个阶段来描述一个技术产品从出现、发展到成熟之后的变化，但是我认为，真实世界中的技术产品未必都会严格按照一条固定的路线发展。

相比固定的五阶段模型，我原本更习惯于把一个产品的发展理解为：

萌芽阶段 → 成长阶段 → 成熟阶段 → 衰退阶段

但进一步思考之后，我发现，即使是这种四阶段划分其实也存在同样的问题：它仍然假设一个产品最终会走向衰退。

我认为现实中的产品发展可能没有这么线性。

例如作者提到的 MP3 播放器。随着智能手机的发展，手机已经能够承担音乐播放、视频播放等多种功能，传统 MP3 播放器的市场确实受到了很大的冲击。从整体市场来看，我们似乎可以认为 MP3 播放器已经进入了衰退阶段。

但是，“市场缩小”是否就等同于“产品生命结束”？

我认为未必。

例如对于一些不方便使用智能手机的人群，或者在校园、运动等特定场景下，独立的音乐播放器仍然可能存在需求。也就是说，一个产品虽然退出了大众主流市场，却可能进入一个规模更小、但长期存在的细分市场。

这让我觉得，技术产品的发展可能并不是：

“大市场 → 衰退 → 消失”

而有可能是：

“大众产品 → 市场萎缩 → 转向细分市场 → 长期存在”。

另一个让我产生疑问的例子是传统机械腕表。

以 Rolex 等机械腕表品牌为例，手表最初首先解决的是实用的计时需求。但是随着石英表、电子表以及智能手表的发展，如果只从“计时技术”的角度来看，传统机械表似乎早就应该被更加准确、更加便宜的新技术取代。

但现实并没有完全按照这个方向发展。

一些机械腕表逐渐从单纯的计时工具转变成了工艺、品牌、审美乃至身份象征。它所出售的已经不只是“准确地告诉用户时间”这一功能，而是附加了品牌文化、机械工艺和收藏价值。

这说明一个产品在原有技术功能受到替代之后，也可能通过重新定位找到新的市场，而不是简单地进入衰退直到消失。

因此，我认为作者提出的五阶段模型更适合被看作一种帮助我们理解技术产品发展的“典型模型”，而不一定是一条所有产品都必须遵循的规律。

我真正的疑问是：

当一个技术产品原有的核心功能被新技术取代以后，如果它通过重新定位、进入细分市场或者增加文化和品牌价值而获得新的生命，这还能算是原来产品生命周期中的下一个阶段吗？还是应该被看作一个新的生命周期？

换句话说，我认为技术产品的发展可能不是一条单向的直线，而更像是一棵会产生分支的树。一个产品既可能衰退，也可能转向小众市场、重新定位，甚至重新获得增长。

因此，“一个技术产品是否一定会完整经历作者所描述的五个阶段”，我认为是值得进一步讨论的。

问题四：技能的培养是否存在一条普适的“最优路径”？

出处：《构建之法》第 3 章，第 61 页。

在第 3 章关于技能培养的讨论中，作者谈到了技能需要通过持续练习、实践和积累才能逐渐形成。

读到这里以后，我产生了一个问题：

一项技能的培养，究竟有没有一条相对固定、普遍适用的学习路径？

我以前在学习编程的时候，经常会遇到这样一种情况：一开始会先看教材、视频或者别人的代码，觉得自己已经理解了，但真正让我独立完成一个程序时，却经常不知道应该从哪里开始。

这让我意识到，“知道一个知识点”和“真正掌握一项技能”并不是同一回事。

例如学习 C++ 时，一个学生可能已经知道变量、循环、函数、指针等语法，但是如果让他独立完成一个完整的程序，他仍然可能无法把这些知识组织起来解决问题。也就是说，知识的积累并不会自动转化成技能。

因此，我认为技能培养至少需要经历几个过程：

学习基础知识 → 模仿已有案例 → 独立实践 → 得到反馈 → 发现问题 → 再次练习

其中我认为“反馈”尤其重要。

如果只是重复做自己已经会做的题目，虽然练习时间很多，但能力可能并不会明显提高。相反，如果不断尝试略高于自己当前水平的任务，并通过错误、调试、老师或同学的反馈发现自己的不足，学习效率可能会更高。

但是这里又产生了另一个问题。

不同人的基础和学习方式并不相同。

有些人可能适合先系统学习理论，再进行实践；有些人则可能更适合先完成一个项目，在遇到问题以后再回头补充知识。

例如在学习 Git 时，我认为如果只看 Git 命令的介绍，很容易记不住；但如果真正建立一个 GitHub 仓库，在提交代码、修改文件、解决冲突的过程中学习这些命令，可能反而更容易理解。

因此，我开始怀疑：

所谓“正确的技能培养路径”，是否并不是固定的步骤，而应该根据学习者当前的能力不断调整？

我目前更倾向于认为，一项技能的培养需要形成一个不断循环的过程：

学习 → 实践 → 犯错 → 反馈 → 修正 → 再实践

真正重要的可能不是一次选择了多么完美的学习路线，而是能否长期保持这个循环。

因此，我真正想问的是：

在技能培养过程中，我们应该如何判断自己当前应该继续学习理论，还是应该停止输入知识、转而进行更多实践？又应该如何判断自己的练习是真正有效的练习，而不是简单地重复已经掌握的内容？

我认为这个问题对于编程学习尤其重要，因为很多时候“看懂了”和“会写了”之间还有很大的距离。

问题五：敏捷开发真的适用于所有软件项目吗？

出处：《构建之法》第 6 章，第 127 页。

作者在本章讨论了敏捷开发，强调通过短周期迭代和持续反馈来应对需求变化。我认为这种方式确实很适合需求变化较快的软件项目，因为它可以让团队更早发现问题，避免花费大量时间后才发现方向错误。

但我产生了一个疑问：

敏捷开发是否适用于所有类型的软件项目？

例如普通网站、手机应用可以频繁迭代，但对于航空控制系统、医疗设备软件等对安全性和可靠性要求极高的项目，频繁修改和快速发布是否仍然合适？这类项目可能更加重视严格的需求分析、测试和验证。

另外，“敏捷”是否也可能被错误理解为“没有计划”？如果需求不断变化，却缺乏长期目标，敏捷开发会不会反而导致项目混乱？

因此，我认为敏捷真正的意义不只是“开发得快”，而是缩短反馈周期并及时调整方向。

我真正想问的是：

我们应该根据哪些条件判断一个项目是否适合采用敏捷开发？敏捷与传统的软件工程方法之间又应该如何取舍和结合？

四、前车之鉴

在阅读前人的学习经历之后，我最大的感受是，大学四年看起来很长，但如果只是跟着课程、作业和考试向前走，其实很容易在不知不觉中浪费掉很多时间。不同人的经历虽然不同，但他们反复提到的一点都是：真正决定最后能力差距的，并不只是考试成绩，而是有没有主动学习、独立思考和实际解决问题。

1. 读《在失望中寻找希望》有感

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

这篇文章中让我印象最深的一句话其实就是作者对自己的评价——虽然是计算机科班出身，却没有真正学懂计算机。

作者本科阶段学习过数据结构、操作系统、计算机网络、数据库等大量专业课程，考试成绩也一直不错，但是后来回头看，却发现自己很多时候只是按照老师讲过的方法完成作业，为了考试而掌握知识，并没有真正主动思考这些知识为什么存在、应该如何应用。

这一点对我的触动比较大。

我们在大学里很容易产生一种错觉：只要专业课成绩还不错、考试通过了，就代表自己已经掌握了这门课。但计算机与很多只依赖理论记忆的学科不同，比如数据结构，如果只是知道栈、队列、树和图的定义，却不能真正写出程序解决问题，那么这些知识实际上并没有完全转化成自己的能力。

我现在也会遇到类似的问题。有时候看老师的代码或者教程时觉得自己已经看懂了，但是关闭教程以后让我独立完成，却会发现自己不知道应该从哪里开始。这说明“听懂”“看懂”和“真正掌握”之间其实还有很长的一段距离。

因此，我觉得大学学习不能只满足于“课程完成了”和“考试通过了”。相比成绩本身，我更应该关注自己能不能把学过的知识真正用出来。对于计算机专业来说，主动写代码、做项目、查资料和思考问题，可能才是把课堂知识真正变成能力的过程。

这篇文章也提醒我，大学最大的风险并不一定是考试挂科，而是每天看起来都很忙，却一直按照固定的路线完成任务，几年以后才发现自己并没有形成真正独立解决问题的能力。

2. 读《掉进读书的兔子洞》有感

原文链接：C.https://book.douban.com/subject/4006425/discussion/22802960/

这篇文章中我比较感兴趣的是作者记录“思维快照”的习惯。他会把自己每天想到的问题、学习计划和想做的事情记录下来，并且隔一段时间重新翻看，从过去的记录中观察自己的变化。

我觉得这个习惯真正有价值的地方并不只是“记笔记”，而是能够让自己发现过去学习过程中存在的问题。

很多时候我们会觉得自己每天都在学习：今天学操作系统，明天看数据结构，后天又开始研究另外一个技术。每天看起来都很充实，但是过了几个月以后回头看，却可能发现很多东西只是了解了一点，没有真正学深入。

作者自己也提到过类似的经历：有一段时间读了很多书、接触了很多知识，但是学习内容之间缺少清晰的主线。表面上非常努力，实际上却容易不断更换方向。

这一点我觉得在现在更加明显。互联网能够非常容易地让我们接触到大量课程、技术文章和视频，但信息越多，并不代表学习效率越高。有时候看到一个新技术就很想学，结果原来的内容还没有掌握，又开始了新的东西，最后每一个方向都只停留在入门阶段。

所以我觉得记录学习过程是一件值得尝试的事情。

以后我希望不仅记录“今天学了什么”，还要记录三个问题：

• 我为什么要学这个？
• 我真正掌握了什么？
• 下一步应该继续深入什么？

这样过一段时间重新查看时，就可以发现自己的学习路线有没有发生偏离。

我认为真正有效的学习并不是不断增加自己“接触过”的知识，而是不断增加自己真正理解和能够使用的知识。

3. 读《一直在路上——记我从初中到本科近十年的学习成长历程》有感

原文链接：D. https://www.cnblogs.com/xiaozhi_5638/p/4485805.html

这篇文章中我比较关注的是作者关于自学、项目和实习经历的讨论。

作者在大学期间主动学习了很多课堂之外的技术，也参加了比赛和实习。刚开始时，他认为拥有更多项目和实习经验能够让自己在求职时获得明显优势。但后来进入实际工作以后，他重新认识到，对于应届毕业生而言，企业真正看重的并不只是简历上写了多少段实习，而是一个人的基础是否扎实、学习能力是否足够强。

我比较认同这个观点。

现在很多计算机专业学生都会比较焦虑项目和实习，总觉得一定要尽快让简历上出现很多技术名词、比赛和项目。但是如果基础知识没有掌握，只是按照教程完成一个项目，其实很容易出现“做过，但说不清楚”的情况。

比如一个项目使用了数据库，并不代表真正理解数据库；使用了一个框架，也不代表真正理解这个框架为什么这样设计。如果面试时继续追问底层原理，很快就可能暴露出知识只是停留在使用层面。

但另一方面，我也不认为实践是不重要的。

课堂学习给了我们计算机组成、操作系统、数据结构、数据库等基础知识，而项目和实习则让我们第一次面对真正开放的问题。在实际项目里，不会有人把每一步都写在题目里，我们需要自己查资料、调试 Bug、理解别人的代码以及和其他人沟通。

所以我认为基础学习与实践并不是互相冲突的。

比较理想的状态应该是：

通过基础课程建立知识体系，再通过项目和实践发现自己的知识漏洞，最后回到基础知识中继续补充。

这也让我重新思考自己之后的学习方向。与其单纯追求“做过多少项目”或者“写过多少行代码”，我更希望自己以后完成一个项目时能够真正理解其中的关键技术，并且能够解释为什么这样设计、出现问题时如何排查。

对我来说，实习和项目真正的价值并不只是增加简历上的一行经历，而是检验自己到底有没有把课堂里的知识转化成解决真实问题的能力。

小结

读完这几篇文章以后，我发现这些前人的经历虽然不同，但最终都指向一个类似的问题：

大学学习不能只是被课程推着向前走。

考试成绩、代码量、比赛、项目和实习当然都有价值，但这些东西最终应该服务于能力的形成。如果只是为了完成任务而完成任务，即使看起来做了很多事情，也可能没有真正形成自己的知识体系。

因此，我希望自己接下来的大学学习能够更加主动一些：不仅完成老师要求的课程内容，也主动实践、记录问题、反思学习方法，并通过项目不断检验自己到底有没有真正掌握学过的知识。

我觉得大学四年最大的价值，也许并不是记住了多少知识，而是逐渐形成一种能够独立学习、独立思考和解决问题的能力。

GitHub 练习

我的 GitHub 仓库：

https://github.com/konglang123/konglang123

GitHub README 截图：

Markdown 编辑器设置

博客园后台 Markdown 编辑界面：