第一周作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标	发表一篇有关自己的随笔

1. 介绍自己

我是朱海碲，目前是广东工业大学的一名大三学生，主修计算机科学与技术。我比较随性，性格幽默内向，不擅长跟陌生人来往，平时没什么爱好，最喜欢的是带着我的相机在外面拍照。这几年一直做好本职工作，学习上的事都认真完成，收获匪浅。

2. 现状、经验和计划

(1)

关于我为什么选择这个专业，当时我也没怎么研究过，因为我对什么都不感兴趣，填志愿的时候想着计算机比较热门而且也是主流，所以就选择了这个专业。至于我离合格的 IT 专业毕业生还有哪些差距，我觉得差得多了，我远远还不够那个水平，不管是编程水平、项目经历还是实习经历都还需要巨大努力。

在技能调查表中，我选择了 5 个我认为对我特别重要的技能：

• 需求对齐与代码健康度（当前水平 2，期望水平 4）
• 验证深度与测试覆盖（当前水平 1，期望水平 3）
• 智能体编排与工具使用（当前水平 2，期望水平 4）
• 开源杠杆与社区贡献（当前水平 1，期望水平 3）
• 工程复现性与构建完整度（当前水平 1，期望水平 3）

接下来我的提升方法是：

• a. 当然还是继续进行代码的练习，提高代码量，这是一门实践专业。
• b. 选择比自己目前水平稍难的项目做，只做完全对标自己水平的项目是没法进步的。
• c. ai 的辅助使用是必不可少的，不仅仅是写代码，在帮助我提升水平、解决问题上也有巨大帮助。
• d. 网络课程也是重要助力，实话说，我上课很难听进去，有时是因为声音太小，有时候是 ppt 看不清（因为我不喜欢坐前面而且近视度数很高），但是网络课程我倒是能专心下来。
• e. 最后就是 github 上的开源项目，选择一些做点自己想法的修改，让学习不会太无聊死板。

(2)

a) 我认为上课并且认真听讲就是学生的本职工作，是作为一个学生应该做到的，但是如果是有实习的情况下我认为应该专注实习，毕竟实习是真正的实践，课堂听讲终究是理论，最后还是要回归实际。

b) 我体验到的关系是餐馆 / 食客，但我希望是哥们 / 哥们。我选择 E。当我觉得作业难的时候，我肯定是学会选择去问老师的，因为我太内向了，我会去问我的朋友，但绝对不会不写，最多抱怨两句为什么作业出这么难，然后乖乖完成。

c) 引用文献，参考别人的资料，在别人工作的基础上继续开发我认为是现在普遍存在的，也是必要的，因为这样才能在一个问题上产出多种想法，众人拾柴火焰高，能推进优化，这跟抄袭、剽窃有着本质上的区别，抄袭、剽窃完全是恶意的行为，是为了完成一己私欲的恶劣行径，是对他人成果的窃取和玷污。

(3)

其实我现在挺迷茫的，上面说了我对什么都不感兴趣，所以我也不好说我以后要做什么行业，现在最可能的就是从商和考公，但是考公太坐牢了，从商的话在我们那边行业基础很好，但是现在行情太差了，所以真不好说。我觉得我对比其他人没有什么优势，劣势的话就是我的热情比较低，就是对于这门学科没有动力，如果两年都没能让我对计算机感兴趣的话，可能我真的不适合。这学期的规划当然还是一如既往好好学习专业知识，多花时间。

(4)

既然这门课都叫软件工程了，那目标肯定就是能自己做出一个小软件来。我觉得计算机的课程都差不多，互相联系，所以没什么期待。我不想当助教，我不是那种人。当前的代码量是 java4000 行，我打算平均每周拿出 5 个小时用在这门课上，C: 比以前的课稍多一些。

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

问题一

• 阅读位置：第 3 章 软件工程师的成长

• 我的问题：程序员是不是只要技术能力强，就可以成为一名优秀的软件工程师？

• 阅读后的思考：书中让我印象比较深的一点是，软件工程师的成长并不只是学习更多的编程语言和技术。实际的软件开发还需要沟通、分析问题、理解需求以及和团队成员合作。这一点和我平时学习编程的感受比较接近。以前遇到一个问题时，我通常第一反应是去搜索代码怎么写，而不是先分析这个问题到底是什么。有时候代码虽然能够运行，但并没有真正解决问题。例如在做小组项目时，一个成员可能技术能力比较强，但是如果不能和其他人沟通，就容易出现 “自己觉得做对了，但是和其他人的部分接不上” 的情况。

• 我的观点：我认为技术能力是程序员的基础，但不是全部。真正的软件开发不仅是把代码写出来，还需要知道为什么写、给谁使用以及怎样和其他人一起完成。

问题二

• 阅读位置：第 8 章 需求分析

• 我的问题：一个软件增加了很多功能之后，是不是就一定比功能少的软件更好？

• 阅读后的思考：在学习和做课程项目的时候，我们经常会有一种想法，就是 “功能越多，项目看起来越厉害”。但是读完相关内容后，我觉得这种想法并不一定正确。一个软件如果有很多功能，但是其中大部分功能用户根本不会使用，那么这些功能不仅没有增加软件价值，还会增加开发和测试的工作量。例如一个学习类软件，如果最重要的是查看课程和提交作业，那么把这两个功能做好可能比增加十几个不常用的小功能更加重要。

• 我的观点：我认为软件开发应该优先考虑功能的实际价值，而不是功能数量。特别是时间有限的课程项目，更应该先保证核心功能能够正常运行，再考虑增加其他功能。否则很容易出现 “什么都有一点，但是没有一个功能真正做好” 的情况。

问题三

• 阅读位置：第 9 章 团队合作

• 我的问题：团队成员是不是应该一直讨论到所有人都同意，才能做出最终决定？

• 阅读后的思考：软件项目通常不是一个人完成的，不同成员有不同的想法是很正常的。充分讨论可以让大家发现问题，也可以避免一个人做出错误决定。但是我在实际的小组作业中也发现，讨论并不是越长越好。例如一个小组需要选择一种技术方案，两个成员分别支持不同的方法。如果一直争论哪个方法更好，可能讨论一个小时还没有结果，但是项目实际上并没有向前推进。所以我觉得团队合作中存在一个很现实的问题：讨论需要时间，而项目的时间是有限的。

• 我的观点：我认为团队讨论应该有一个 “结束点”。比较重要的问题可以充分讨论，但是对于一些影响不大的问题，没有必要追求所有人完全一致。如果经过讨论仍然无法统一，可以由负责人根据项目目标做出决定。好的团队不是没有分歧，而是能够在出现分歧后继续向前推进。

问题四

• 阅读位置：第 12 章 用户体验

• 我的问题：如果用户提出了一个功能需求，开发团队是不是就应该把它实现出来？

• 阅读后的思考：从用户角度来看，当然希望软件能够满足自己的需求。但是从开发人员的角度来看，一个需求从提出到真正实现，中间还需要考虑开发时间、技术难度以及后续维护等问题。有时候用户提出的功能看起来很好，但是实际使用的人可能很少。如果为了这个功能修改大量代码，甚至影响原来的核心功能，那么它的价值可能就没有想象中那么高。我觉得这也是开发人员和用户容易产生分歧的地方。用户更加关注 “我想要什么”，而开发人员需要考虑 “这个东西值不值得做”。

• 我的观点：我认为用户需求很重要，但不能简单地理解成用户说什么就做什么。开发团队应该分析需求背后的真正原因，再结合开发成本和实际价值做决定。这样既可以满足用户，也能够避免项目不断增加没有必要的功能。

问题五

• 阅读位置：第 15 章 软件发布

• 我的问题：一个软件如果还存在一些不足，为什么不等到全部解决之后再发布？

• 阅读后的思考：以前我对软件发布的理解比较简单：程序全部开发完成、测试没有问题之后，再正式发布。但是软件实际开发并不是这么简单。一个产品在真正投入使用之前，开发人员很难预测用户会遇到什么问题。有些问题只有真正的用户使用之后才能发现。比如一个软件在开发人员自己测试的时候觉得操作很方便，但是普通用户使用时可能根本找不到某个功能。这种问题单靠开发人员自己测试不一定能够发现。因此，提前发布一个基本可用的版本，再根据用户反馈继续修改，我认为是有一定道理的。

• 我的观点：我认为软件不一定要追求 “100% 完美” 之后再发布。但是这里也需要一个前提：发布的版本至少应该能够正常使用，不能因为追求快速发布而忽略基本质量。所以我比较赞同 “先做出一个可用版本，再不断改进” 的思路。这样可以更早发现真正的问题，也能避免开发人员一直闭门造车。

下面这个问题我选C

4. 前车之鉴

文章 B

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

读完之后，我最大的感受是，计算机专业的学习不能只依赖课堂和书本。文章中让我印象比较深的是，作为计算机专业的学生，虽然大学里学习了很多专业课程，但真正到了实践中，还是会发现自己掌握的东西远远不够。这让我认识到，“学过” 并不代表 “学会”，更不代表能够熟练运用。在平时的学习中，我也会遇到类似的问题。有时候为了完成作业，会比较关注程序能不能运行、答案对不对，却没有认真思考其中的原理。这样虽然能够完成一次任务，但是过一段时间再遇到类似问题，还是可能不会做。相比之下，如果能够自己动手多写一些代码、多做一些项目，把课堂上学到的知识真正用起来，理解会更加深刻。这篇文章也让我意识到，大学阶段不能只是被动地完成老师安排的学习任务，还需要主动寻找实践机会。计算机技术更新很快，只靠课堂上的内容很难完全适应以后真正的工作。现在多积累一点实践经验，多发现自己的不足，以后进入工作岗位时才不会觉得什么都不会。总的来说，这篇文章让我更加认识到理论学习和实践同样重要。专业课程是基础，而实践是检验自己是否真正掌握知识的一种方式。以后学习计算机相关知识时，我应该少一点 “为了完成任务而学习” 的想法，多思考这些知识到底能解决什么问题，并通过实际编程把它真正变成自己的能力。

文章 C

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

读完这篇文章后，我印象最深的是作者对自学和独立思考的重视。作者从小学开始就通过自己看书、做题来学习，遇到不会的问题也会自己思考，而不是马上寻找答案。后来到了大学，他又通过亲手敲《Thinking in Java》等书中的程序，把书本知识真正转化成自己的能力。这一点让我比较有感触。平时学习编程的时候，我有时会直接看别人写好的代码，觉得自己 “看懂了” 就算学会了。但是实际上，真正自己动手写的时候，还是会遇到很多问题。作者提到自己把书中的程序一个字母一个字母敲出来，我觉得这种看起来比较慢的方法反而能够让自己真正理解代码。文章还让我认识到，学习不一定要追求快。作者提出 “慢即是快”，通过自己做题、实践来加深理解。相比于短时间看很多资料，我认为把一个知识点真正弄懂，并且能够自己应用出来，可能更加重要。另外，作者大学前期也经历过自负和自卑的心理变化，这让我觉得学习过程中有迷茫其实很正常。重要的是不能一直停留在这种状态，而是要找到适合自己的学习节奏和目标。总的来说，这篇文章让我最大的收获就是：学习计算机不能只看别人怎么做，更重要的是自己动手去做、去思考。以后学习编程时，我也应该少一些 “看懂了就算了” 的学习方式，多写、多练、多思考，把知识真正变成自己的东西。

我的GitHub仓库地址 https://github.com/csxy-boy/csxy/blob/main/README.md