软件工程第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	第一次作业
这个作业的目标	完成个人能力盘点，明确软件工程课程学习目标，阅读《构建之法》并提出问题，同时熟悉博客园、Markdown、Git 与 GitHub 的基本使用

1. 自我介绍

大家好，我是GDUT的CS系的学生（出于个人隐私就不写真名了）
这个是我的个人网站：airchord.org

我认为自己比较明显的一个特点是愿意把感兴趣的想法真正实现出来。

从最初接触 GUI，到后来尝试 Unity、Web 开发、服务器部署，再到 AI Agent，我经常会因为一个想法去学习原本完全陌生的技术。这个过程没有一个明确的结束时间，而是在过去几年中逐渐形成的习惯。

我觉得自己真正积累下来的并不是 会多少框架，而是面对一个陌生技术时，能够通过查资料、阅读文档、测试和调试，最终将问题逐渐缩小并解决。

如果要用一句话描述我的计算机学习方式，我可能会选择“先做出来，再追着问题学习”。

相比单纯按照某一门语言或教材学习，我更喜欢从一个实际项目开始。例如，我曾经使用 Unity 和 Godot 开发游戏原型，也接触过GUI开发、Web 开发、爬虫、Linux 服务器部署以及 AI Agent 等方向。在开发过程中遇到不会的问题，再反过来学习对应的技术。

这种学习方式让我比较早地接触到了“一个完整的软件到底是怎样工作的”，但也带来了明显的问题：我的知识比较分散，很多时候知道“怎么把东西做出来”，却未必能系统地解释为什么应该这样设计。

因此，我希望软件工程这门课能够帮助我从 会写程序 逐渐转向 会做软件。

2. 现状、经验和计划

2.1 为什么选择计算机，以及现在距离合格毕业生还有多远

我选择计算机专业，主要源于对编程和游戏开发的兴趣。我喜欢计算机的一点，是一个想法可以通过程序真正变成能够运行和交互的东西。

进入大学之后，我对计算机的理解逐渐发生变化。以前我会比较关注“用了什么语言”“学了什么框架”，现在则越来越意识到，一个真实的软件项目还涉及需求、架构、数据库、网络、测试、部署、维护和团队协作等大量问题。

因此，我认为自己目前距离“合格的 IT 专业毕业生”最大的差距，并不只是少掌握某几个框架，而是缺乏足够系统和成熟的软件工程能力。

技能	当前水平	课程结束目标	提升方法
程序设计与编码	5	6	多练习算法题
数据结构与算法	4	5	复习基础算法，尝试在实际开发中使用更优算法
Git 与版本管理	4	6	多使用分支、Issue、PR 和 Code Review
软件设计与架构	3	5	学习模块划分、接口设计和设计原则，并应用到课程项目
软件测试	3	5	学习并实际编写单元测试、集成测试
团队协作与项目管理	4	5	使用任务拆分、迭代、进度跟踪和定期同步
阅读文档和自主学习	6	7	更多阅读官方文档和源码，减少只依赖二手教程

2.2 关于上课、师生关系以及抄袭

（1）为什么要来上课并认真参与

我认为大学课程真正稀缺的资源并不是教材内容本身。大多数编程知识确实都能从互联网、书籍或者 AI 工具中找到，但课程能够提供相对完整的学习路径、阶段性要求、学习环境以及反馈。

我过去比较习惯项目驱动式学习，它的优点是目标明确，但缺点也很明显：容易只学习当前项目急需的部分，对不感兴趣或者暂时用不到的基础知识主动跳过。

因此，对我来说，认真参与课程的重要意义之一，就是让自己完成一些 如果完全自由选择，我可能不会主动完成 的训练。

（2）关于师生关系

我会选择 C。
如果作业有困难，我会首先自己查资料和尝试解决；如果仍然无法解决，再带着已经尝试过的方法和具体问题去询问同学、老师或助教。

我并不认为 作业困难 本身是不合理的，在 AI 时代下，知识已经开始逐渐平权，获取知识越来越方便，完不成的作业或许已然成为过去式。

我个人认为：老师在当下更多扮演的是 规划者 和 答疑者 的角色。

（3）引用与抄袭的区别

合理引用 / 借鉴	抄袭 / 剽窃
明确标明来源	刻意隐藏来源
理解后重新组织	大段复制后声称是自己的
在别人的工作基础上继续分析	直接把别人的成果当自己的成果
使用第三方代码时说明来源和许可证	未经说明复制代码
可以解释自己使用的代码	自己都不知道复制代码在做什么

在编程中，完全不参考别人的代码并不现实。查阅文档、开源项目和论文，本身就是开发的一部分。关键区别在于是否诚实说明来源，以及是否真正理解和完成了属于自己的工作。

2.3 我的未来方向

目前我比较感兴趣的方向是软件开发、游戏开发、Web开发以及 AI Agent 相关技术。未来最终会具体选择哪一种岗位，我现在还没有完全确定。

但我发现，这些方向虽然表面差异很大，对基础能力的要求却有很大重叠：代码能力、系统设计能力、算法基础、团队协作、调试能力以及持续学习能力。

所以现阶段我并不准备过早限定自己，而是优先补齐这些通用能力。

我的优势	我的劣势
比较愿意主动尝试项目	学习方向有时过于分散
接触过不同技术栈	部分基础知识不够扎实
有独立解决问题的习惯	测试和规范意识不足
对新技术接受速度较快	有时容易追求“做出来”而忽视工程质量
有一定团队项目经历	项目管理经验仍然不足

2.4 我对软件工程课程的计划

我估算自己写的代码量大致如下：

语言	估算的代码量 （不计Vibe Coding）
C#	约 35,800 行
C/C++	约 15,200 行
Java	约 2,700 行
Python	约 2,300 行

一流软件公司需要多少代码量？

我认为代码量只能作为经验积累的一个非常粗略指标。一流软件公司不会按照总代码行数招聘，一个写过 10 万行重复业务代码的人，也不一定比认真完成过 3 万行高质量项目代码的人更优秀。

如果一定要给自己设置一个量化参考，我希望本科阶段能够积累 5 万～10 万行真正理解、亲自参与设计和维护的有效代码，同时拥有若干能够完整说明设计、测试、部署过程的项目。

科研工作则更加不能单纯以代码量衡量。科研更重要的是问题定义、文献阅读、实验设计、数学与理论基础，以及将想法实现并验证的能力。

课程计划投入时间

我计划平均每周投入 8～10 小时 在这门课程中，其中包括上课、阅读、编码、博客和团队项目时间。

课程代码目标

自己动手写4000-7000行有效代码

Wish

在课程结束时，我希望自己能够完整参与一次比较规范的软件工程项目，并真正理解需求分析、任务拆分、版本管理、测试、团队协作和迭代开发，而不仅仅完成编码。

OutCome

如果达到目标，我希望自己再面对一个新的软件项目时，不再直接打开 IDE 开始写代码，而是能够先思考需求、模块边界、接口、测试方式和协作流程。

Obstacles

我最可能失败的原因不是技术学不会，而是兴趣过于分散。

我经常同时对游戏开发、AI、Agent、Web、服务器等多个方向感兴趣。当出现新的想法时，容易将原本正在进行的任务暂停，转而研究新东西。短期看似学到了很多，但长期可能导致项目无法持续深入。

Plan

• 拆分项目任务，按照一个个闭环来逐渐完善项目
• 合理分配时间，多设置deadline
• 多写技术文档，按照技术文档的方向来开展后续工作

3.《构建之法》快速阅读后的 5 个问题

问题一：软件到底什么时候才算“足够好”？会不会成了偷懒交差的借口？

出处：第 1 章 概论，1.2.5 软件工程的目标——创造“足够好”的软件

“软件工程的一个重要任务，就是要决定一个软件在什么时候能‘足够好’，可以发布。”
“有实际用处的同时又是完美的软件，在世界上是不存在的……软件团队为什么还要把这些不完美的软件发布出来呢？为什么不能等到它们完美之后再发布？”

我的困惑：

书中说世界上没有绝对完美的软件，只要“足够好”就能发布。可是在实际开发中，这个“足够好”的尺子到底该由谁来量？怎样才算真的足够好？

问题二：我反对“技能的反面是解决问题”这个说法

出处：第 3 章 软件工程师的成长，3.3 技能的反面

“巴克斯顿说技能的反面是‘Problem Solving’——‘解决问题’……一个IT专业的大学生来面试……你发现他把时间都花在‘解决（低层次）问题’上了……怎么提高技能呢？答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后再有时间和脑力来解决较高层次的问题。”

我反对作者的观点：

作者引用巴克斯顿的观点，认为熟练的“技能”就应该像肌肉记忆一样，不用过脑子自动就能操作；如果你还在耗费脑力去查语法、解决问题，就说明你根本谈不上掌握技能。

我的观点：

把“解决问题（Problem Solving）”放到“技能”的对立面，甚至认为“不用过脑子的操作”才叫技能，这观点有点偏了。我认为，真正的核心技能，恰恰就是面对未知时结构化拆解和解决问题的能力。

首先，不应该把死记硬背当成真本领。现在编程语言和工具更新太快了，今天写 C++、明天用 Python、后天可能又要用 Rust。如果一个人只是因为熟练掌握了某套 API 的写法、打字不用查文档，那只能算打字熟练工，遇到稍微复杂点的死锁、内存泄露或者算法优化，照样抓瞎。真正厉害的工程师，值钱的地方就在于他懂得系统底层原理，懂得怎么去“解决问题”，而不是把脑子练成肌肉记忆。就像作者自己拿魔方举的例子，光靠背口诀把魔方转六面出来，换个不同结构的魔方立马就不会了，这种“不用脑子的熟练”，真的能代表高水平的技能吗？

问题三：结对编程真的有那么神吗？会不会纯属折磨人

出处：第 4 章 两人合作，4.5 结对编程

“在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作……如果运用得当，结对编程可以取得更高的投入产出比（Return of Investment）。”

我有这个问题：对于绝大多数普通团队或学生小组来说，让两个人整天挤在一起看一个屏幕敲代码，真的比“定好接口、各写各的，最后做Review”更划算吗？

问题四：我反对拿“交付时间的稳定性（低方差）”来衡量工程师是否成熟！

出处：第 3 章 软件工程师的成长，3.1 个人能力的衡量与发展

“从总用时来看，Al的平均用时比Bob少一天，似乎应该是稍稍优秀一些，但是从标准方差（Standard Deviation）来看，Al的方差是5.3，而Bob是1。显然Bob比Al的交付时间要稳定得多。在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面……一个成熟的软件工程师应该能够降低任务交付时间的标准方差。”

我反对作者的观点：

作者通过两个程序员的对比，认为 Bob 每次用时都很均匀、方差极小，所以比总用时更短但方差大的 Al 更成熟、更值得信赖。

我的观点：

在真正的研发工作中，如果片面追求交付时间的“低方差”，很容易搞成“大家一起磨洋工”的反向激励，甚至把有探索精神的人给扼杀了。

问题五：敏捷冲刺时间到了就必须收尾，那底层的“技术债”到底谁来还？

出处：第 6 章 敏捷流程，6.2 敏捷流程的问题和解法

“冲刺阶段是时间驱动的（Time-boxed），时间一到就结束。这个特点看似不起眼，但其实它有效地断了各种延期想法的后路，很高明。”
“长期任务：软件项目中常常有一些比较艰难和底层的任务，完成这些任务需要超过Sprint所计划的时间……在作者的经验中，这些任务往往在短周期的迭代中得不到应有的重视，一直拖着，最后导致团队要花大量的时间来解决问题。”

我有这个问题：
敏捷要求每个冲刺时间卡死，到点了就必须交付能看到的可运行软件。那那些对用户“看不见”却至关重要的重构、底层算法优化和技术债务，到底该怎么从制度上保证不被一直拖死？

作业要求中的问题：

认真反馈：既然是健身/教练的关系， 那么健身学员就会经常提问“为何我的肥肉还在？为何我肌肉不长?为何要做这个练习？... ... ”； 为了改进教学，收集资料，老师在教学过程中会要求学生填写对课程的反馈， 你会怎么做？

我选择C

4. 前车之鉴

1. 科班，但是否真的学懂了计算机？

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

读完这篇文章，我比较有感触的一点是，“计算机专业学生”和“真正理解计算机”之间其实还有很大的距离。大学里学过数据结构、操作系统、计算机网络等课程，并不代表真正掌握了这些知识。我自己平时也更偏向通过项目学习，经常会为了完成某个功能快速接触新的框架和技术，但有时对底层原理理解得并不深入。因此相比不断追求新的技术，我认为之后也需要花时间重新整理和巩固基础知识。

2. 培训式速成和大学基础教育

文章链接：https://www.cnblogs.com/geniusalex/p/4928713.html

以前学习编程时，我也会觉得一些基础课程距离实际开发比较远，例如操作系统、计算机组成原理等内容似乎不能马上帮助我完成一个项目。但随着接触的项目越来越多，我逐渐发现很多开发中的问题最终还是会回到这些基础知识上。培训或者短期教程可以帮助人快速学会使用一种工具，而大学教育更重要的价值可能是建立比较完整的知识体系。因此，我认为基础课程未必能够立刻产生效果，但长期来看仍然很重要。

3. 热情、能力与选择

文章链接：http://coolshell.cn/articles/4561.html
这篇文章让我想到自己目前的学习状态。我对游戏开发、AI、Agent、Web 等很多方向都有兴趣，这种兴趣让我愿意主动尝试新的项目，但也容易导致学习方向比较分散。我认为仅仅“感兴趣”还不够，真正决定未来方向的应该是长期投入之后形成的能力。因此现阶段我更希望先提高编程、软件设计和工程实践这些比较通用的能力，再通过持续实践逐渐确定自己真正适合并愿意长期发展的方向。

6. 总结

过去我更多关心“怎么把一个东西写出来”，而软件工程课程让我开始思考另一个问题：怎样让一群人持续、可靠地把一个软件做好。

我希望这个学期结束时，我获得的不只是又完成了一个课程项目，而是能够回头审视以前写过的程序，看出其中哪些地方只是“能运行”，哪些地方真正接近“工程”。

7. 附件

github地址：https://github.com/hhd233cored