第一周作业

一、准备工作

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标	写博客、谈谈现状、未来规划与GitHub，求求各位给项目点下star拿下下面这张好看的名片,让ai改一改就是你的了

GitHub profile：https://github.com/Thadopz/Thadopz

博客园后台

二、正文

1.自我介绍

大家好，我是广工28届的计科学生，开门见山地说，我还是爱写技术文档的，先摆出我自己的blog网站：http://thablog.duckdns.org ，文章虽然有点少，但是读了我觉得是会有所收获的。

我爱了解各种新鲜技术，喜欢折腾各种新鲜的技术玩意儿，最近最火的应该是GPT Astra和Claude Fable 5.1发布了吧，不知道各位有没有关注，虽然Astra充满了AGI的噱头，但也许是迈向未来的一大步呢，也许能证明LLM真的能走完AGI的路呢，就好像我们现在一样，乾坤未定，虽然也快了，明年就得备战暑期实习了，实际上应该只有半年时间了（笑哭）。

为了了解更多更深的技术，也为了就业优势，我折腾了很多项目，像是搜索引擎、异常处理agent、AI绘画等等，虽然有些项目还不成熟，但我还是会继续折腾下去的，也说不清是为什么，这也许算是一种优势吧。

2.现状、经验和计划

(1) 选择这个专业的理由、与合格毕业生的差距

说实话，我从来没有考虑过除了计算机之外的专业，我自打一岁起就开始玩电脑，从来没设想过自己会从事其他行业的工作，换句话说，我感觉我一辈子都不应该离开计算机，即使这个行业可能会随着时间逐渐式微，我也会陪着它。

专业知识上，我认为我还有很多不足，像是操作系统、计算机网络、数据库等等，我都没有深入学习过，只是在做项目的时候调用，要说理解吧基本的原理我都知道，但是dfs地问下去我就不知道了；技能上，我认为我已经熟练掌握基本的CRUD开发，对于分布式设计也有一定的处理能力，能够不用ai独立写完MIT 6.824的分布式系统课程的作业，像是Raft、MapReduce等等；经验上，我认为我还缺乏一些大型项目的开发经验，我没有做过特别完整的项目，只是做过一些小的demo，即使是在实习也是没有接触过特别大型的项目。

软件工程能力	当前水平	课程结束后的目标
需求分析与代码质量	L1	L2
软件测试	L1	L2
Git/GitHub 使用	L2	L3
软件架构与模块化	L1	L2
AI 辅助编程	L3	L4
Debug 与问题解决	L1	L2
团队协作与工程规范	L1	L2

（2）心得

• a）总结起来就是，对于学生来说，温故而知新，对于课程而言，学生理应成为评判的主体，课程的设计应当以学生为中心？我大二大部分课都是不听的只靠自学，为什么呢，因为没什么精力听完一整节课，从高中就一直是这样了......有些课程实际上也并不需要怎么学习，一部分像算法和数据结构考的比较基础，os、计网和计组有用但是对于面试而言还是刷刷面经重要，不过我认为总有一天我会回来重新深造的，目前还是处在一个嚼一会就咽下去的阶段。
• b）悲观地说，目前我理解的师生还停留在路人阶段，不过可以的话，我也想和老师多交流，能成亦师亦友的关系最好啦，如果老师布置的作业对我来说有些困难， 我会尽可能完成，如果实在做不到，我可能会向老师请教，老师也可以给我一些建议，或者给我一些参考资料，我会尽量去学习和理解，毕竟我感觉到职场上犯错的成本远高于学校了XDD。
• c）被引用的文献，被参考的资料，某种意义上是互联网精神的体现，这其实也是防君子不防小人（开源打包成闭源）了，反正需要注意一下许可是什么形式的，按照规则行事。

（3）未来规划

从事后端开发亦或者紧追agent开发，虽然我觉得agent开发大部分hc都是后端带点vibe coding规范，这个hc水分很大，实际上agen的水分也大，可能明年就会有大批做agent的公司会暴死了，如果真这样的话，那还是尽早入场吧，这个节骨眼只可追高，不可抄底了XD。

（4）计划、期待、如何度过、代码量、平均时长

其实我也不知道怎么度过，可能就是在写写代码、博客，看看文档吧；期待学到更多的知识，不断提升自己的能力；在coding中度过。

代码量，C++写了12200行，Golang15200行手写项目、算法题解法+33300左右vibe coding产物；不知道，我觉得光靠这个代码量衡量进不进大厂，高校科研工作就很诡异，形式又粗暴的指标产物。

3. 提有质量的问题，给认真的反馈

快速阅读《构建之法》之后，我发现书中的很多内容虽然能够理解大概意思，但是如果真正放到实际的软件开发过程中，还是会产生很多问题。下面是我阅读过程中产生的五个疑问。

问题一：单元测试是不是写得越多越好？

对应章节：第2章 2.1 单元测试

这一节介绍了单元测试的重要性。以前我写程序时，一般都是把程序运行起来，输入几个数据，看到输出结果正确，就认为程序基本没有问题。读完这一节后，我认识到这种测试方式其实很不全面，因为修改一部分代码以后，可能会影响之前已经能够正常工作的功能。

但是这又让我产生了一个问题：单元测试到底应该写到什么程度？

如果是一个比较简单的函数，为它设计很多测试用例，甚至测试代码比原来的功能代码还长，这样是否值得？如果为了提高所谓的“测试覆盖率”而给每一行代码都设计测试，会不会反而花费太多开发时间？

我的理解是，测试应该重点关注容易出错的部分、边界情况以及核心功能，而不是单纯追求测试数量。但这样又产生了新的问题：在真正的软件项目中，应该用什么标准判断“测试已经足够了”？是看代码覆盖率，还是由开发人员根据经验判断？

这也是我目前比较困惑的地方。

问题二：结对编程真的一定比一个人编程效率高吗？

对应章节：第4章 4.5 结对编程

书中介绍了结对编程，两个人共同完成开发，一个人负责输入代码，另一个人负责观察、检查和思考，并且不断交换角色。

这种方式的优点比较明显，比如一个人写错代码时，另一个人可能马上发现，也可以互相讨论解决方案。但是我想到一个实际情况：如果两个人的编程水平差距比较大，那么会不会变成一个人在写代码，另一个人在旁边看，却无法真正参与？

对于一些很简单的任务，两个人共同完成可能还没有一个人单独完成快。

所以我的问题是：结对编程适合所有开发任务吗？还是只适合一些比较复杂、容易出错或者需要讨论的任务？

我认为结对编程最大的意义可能并不是单纯提高“写代码的速度”，而是减少错误、交流思路和分享知识。但是如果项目时间很紧，团队应该怎样判断什么时候使用结对编程，什么时候让成员独立开发再进行代码复审？我觉得这可能比单纯强调结对编程本身更加重要。

问题三：敏捷开发接受需求变化，那么变化到什么程度才算合理？

对应章节：第6章 6.1 敏捷的流程简介、6.2 敏捷流程的问题和解法

敏捷开发强调快速迭代，并且能够根据用户反馈及时调整需求。我觉得这一点很符合现实，因为开发一个软件之前不可能把所有事情都想得非常清楚，用户自己也可能在看到产品以后才知道真正需要什么。

但是如果用户一直修改需求，就会出现另一个问题。

例如团队已经完成了一个功能，用户突然要求改变功能；修改以后，过几天用户又提出另一种想法。如果每一次变化都马上接受，那么开发人员可能一直在修改之前的代码，项目计划也很难执行。

因此我的问题是：敏捷开发强调“响应变化”，但是怎样避免它变成“用户说什么就改什么”？

我认为敏捷并不意味着完全没有计划，团队还是应该有当前阶段的目标。对于新需求，可以先记录下来，在下一次迭代中讨论优先级，而不是随时打断正在进行的工作。

但实际项目中应该由谁决定一个需求是立即修改，还是放到下一个迭代，我目前还没有非常清楚的答案。

问题四：用户提出的需求就一定是真正的需求吗？

对应章节：第8章 8.3 获取用户需求——用户调研、8.5 功能的定位和优先级

需求分析让我比较感兴趣的一点是，我们开发软件最终是为了用户，但是用户自己并不一定能够准确描述自己的需求。

例如一个用户可能说：“我希望这里再增加一个按钮。”但实际上他真正的问题可能是当前操作步骤太复杂。如果开发人员只是按照他说的增加按钮，可能解决的只是表面问题。

这让我想到：需求分析的时候，开发人员应该在多大程度上相信用户直接提出的需求？

如果完全听用户的，产品可能最后堆积大量功能；但是如果开发人员认为自己“比用户更懂用户”，又可能做出一些用户根本不需要的东西。

我目前认为比较合理的方法应该是先听取用户意见，再通过实际使用场景、访谈和测试去验证需求，而不是简单地把用户说的话直接变成功能。

因此我想知道，在实际的软件工程项目中，怎样才能比较准确地区分“用户提出的功能”和“用户真正想解决的问题”？

问题五：使用成熟技术解决一个普通问题，还能算创新吗？

对应章节：第16章 16.1 创新的迷思、16.2 创新的时机

读到创新这一章时，我想到现在很多学生项目都会强调“创新点”。有时候为了体现创新，会加入人工智能、大数据等比较新的技术，但是最后这些技术可能和真正需要解决的问题关系并不大。

相反，一个项目可能没有使用特别新的算法和技术，只是把已有技术组合起来，把一个现实中的小问题解决得很好。

所以我的问题是：软件工程中的创新到底应该更关注“技术是不是新的”，还是“有没有真正解决问题”？

我个人目前更倾向于后者。因为对于用户来说，他们可能并不在乎程序用了什么算法和框架，只关心软件是否好用、能不能解决问题。

但是如果完全使用已有的方案，只是在细节上做改进，那么这种改进做到什么程度以后才能算创新？我觉得“创新”和“改进”之间的界限并不是特别清楚，这也是阅读这一章之后我的一个疑问。

关于课程反馈

对于课程中的提问和反馈，我目前会选择 C：有问题就问，至少一学期提三个问题，认真按时填写反馈。

我觉得自己目前还很难做到 D 中所说的“经常主动给老师和助教反馈”，因为有时候即使遇到问题，也会先自己查资料，或者觉得问题比较简单而不愿意提出来。

但是这次阅读也让我意识到，提问本身也是学习的一部分。如果一直不提问题，有时候并不是因为真的全部理解了，而可能只是没有深入思考。

所以在之后的课程中，如果遇到自己查资料以后仍然不能解决的问题，我会主动向老师、助教或者同学提问。同时，对于课程安排、作业难度和自己的学习情况，也会尽量认真填写反馈，而不是为了完成任务随便写几句话。

4. 前车之鉴

阅读前人的学习经历之后，我最大的感觉是，他们遇到的很多问题其实现在的大学生依然会遇到，比如只关注考试成绩、不知道应该怎样学习计算机、过度追求项目经验，以及不知道大学期间应该把时间花在哪里。

下面是我阅读其中三篇文章后的感想。

4.1 《刘帅：在失望中寻找希望》

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

这篇文章让我印象比较深的一点是，作者虽然是计算机科班出身，也学习了数据结构、操作系统、计算机网络等很多专业课程，而且考试成绩并不差，但是后来回过头看时，却觉得自己并没有真正“学懂计算机”。

我觉得这种情况其实很值得警惕。

大学里很容易把“考试通过”和“真正掌握”混在一起。老师讲什么就记什么，作业要求什么就完成什么，考试之前再集中复习一下，最后可能成绩还不错。但是如果让自己真正解释一个概念，或者把学过的知识用来解决一个没有见过的问题，就可能发现理解得并没有想象中那么深。

文章中关于数据结构学习经历的部分也让我感触比较深。数据结构本身应该是一门实践性很强的课程，如果只是记住栈、队列、链表、树的定义，却没有真正动手实现和使用它们，那么考试结束以后可能很快就忘了。

因此，我觉得以后学习专业课时不能只考虑“考试会不会考”，还应该多问自己几个问题：这个知识为什么会出现？它解决了什么问题？如果让我自己实现，我能不能完成？

我希望自己以后能够少一些机械完成任务，多一些主动思考和实践。成绩可以反映一部分学习结果，但不能完全代表真正的能力。

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

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

这篇文章给我最大的启发是“实践”和“基础”并不是矛盾的。

作者在大学早期逐渐发现，仅仅看书并不能真正学会编程，因此开始把书里的程序实际运行起来，同时通过网络查资料、自己解决问题。后来他又特别强调基础知识的重要性。

以前我有时会觉得，会使用一个新的框架、能够做出一个网页或者一个小程序，就算学到了比较实用的东西。相比之下，数据结构、操作系统、计算机组成原理这些课程看起来没有那么直接。

但是看完这篇文章以后，我发现这种想法可能比较短视。

框架和工具更新很快，今天流行的技术几年以后可能就不再流行，但是数据结构、算法、操作系统这些基础知识变化不会那么快。如果基础比较扎实，再学习新的工具可能会更容易。

文章中对于实习经验的看法也让我改变了一些想法。以前我认为实习经历越多越好，但是对于一个还在学校学习的学生来说，如果专业基础都没有掌握好，只是为了简历好看去追求项目和实习，可能反而会本末倒置。

所以我觉得大学阶段比较合理的路线应该是：学习基础知识的同时坚持动手实践，在有一定基础之后再通过项目和实习检验自己。 不能只看书，也不能只追求“做过多少项目”。

4.3 《我的软件开发生涯（10年开发经验总结和爆栈人生）》

文章链接：https://www.cnblogs.com/unruledboy/p/DevCareer.html

这篇文章最让我意外的是，作者本身并不是计算机专业出身，而是英语专业，但是后来依然长期从事软件开发，并且接触过很多不同的开发技术。

这让我感觉，专业背景确实会影响一个人的起点，但并不能完全决定最后能够走多远。

计算机行业中的技术一直在变化，一个人在大学里不可能把以后工作需要的所有技术全部学完。即使现在掌握了一种语言或者框架，几年以后也可能需要学习新的东西。因此相比于记住某一种具体技术，持续学习的能力可能更加重要。

另外，文章中还提到了交流能力和团队开发的问题。我以前理解程序员的工作时，比较容易把注意力放在“代码写得好不好”上，但是一个真正的软件项目不可能只依靠一个人完成。代码规范、团队沟通、需求理解、与其他成员协作，这些能力同样会影响最终的软件质量。

所以这篇文章让我认识到，我现在需要学习的不仅仅是更多编程语言。相比于盲目追求“我会多少种语言”，我更应该先把一种语言和基本的编程能力学扎实，同时提高自己查资料、解决问题和与别人合作的能力。

总结

阅读这些前人的经历之后，我发现他们反复提到的其实不是某一种具体的编程语言或者技术，而是一些更加长期的能力：主动学习、动手实践、重视基础、独立思考和与别人交流。

这些道理看起来都很简单，真正困难的是能不能长期做到。

对于现在的我来说，与其一下子给自己制定“成为技术大牛”这样的目标，不如先把眼前能够做到的事情做好：认真完成课程项目，遇到问题主动查资料和提问，多写代码，多做总结，并且定期回头看看自己真正学会了什么。

希望等到这门软件工程课程结束的时候，再回来看现在写下的这些内容，能够看到一些比较明显的变化。