软件工程第一周作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class78‑Grade2024‑CS
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class78‑Grade2024‑CS/homework/15710
这个作业的目标	建立个人博客，熟悉博客园发布、Markdown等操作，完成自我盘点，做好大三学习规划

一、介绍自己，建博客
我叫曾堉源，是计算机科学与技术专业的一名大三学生。
在前2年的课程学习里总感觉自己只是应付性学习，在今年我希望可以沉下心来学好java后端开发，做好项目。
平时我也喜欢直播打打游戏，就是有时候玩上头了课内的知识落下了。
二.、现状、经验和计划
当时选择计算机完全看在这份高中是坐办公室敲电脑，感觉挺轻松，而且感觉学的东西算法啥的我也感兴趣，但是这两年学下来有点打击到信心了哈哈。

技能项	目前水平（0-9）	课程结束目标水平（0-9）	能力说明	提升手段
Programming: Design（架构设计，模块化设计，接口设计）	2	5	后端仅入门，只能写单文件简单代码，没有项目模块拆分经验，不懂接口定义；目标：能对小型后端项目做模块划分，定义基础接口，输出简易架构文档。	1. 写代码前先拆分功能模块，画出模块关系图 2. 研读简单开源后端项目，学习目录分层 3. 小项目先写架构与接口文档，再编码
Programming: Implementation（模块实现，逐步细化）	3	6	能独立完成简单小功能编码，但需求拆解粗糙，边界场景考虑不足；目标：可以把小型需求拆分成多个子模块，写出可读性强、可维护代码。	1. 需求拆解先画流程图，自顶向下逐层开发 2. 每个模块完成后，主动测试异常场景 3. 练习拆分复杂需求，控制单个模块代码量
SE: Requirement（需求分析）	4	6	擅长挖掘游戏玩家的表层需求，但业务逻辑、边界场景梳理不够系统；目标：独立编写小型项目需求文档，覆盖常规与异常场景。	1. 项目启动前编写需求文档、用户场景 2. 站在玩家/用户角度思考异常场景 3. 和同学互评需求文档，查漏补缺
Domain Knowledge（业务领域：游戏行业）	5	7	长期玩游戏、做游戏直播，熟悉游戏玩家需求、游戏业务场景；目标：能基于游戏业务场景，完成小型游戏周边工具开发。	1. 分析游戏玩家痛点，构思小工具需求 2. 开发游戏辅助小工具作为课程项目 3. 调研同类游戏工具产品，参考设计
Personal Software Process（个人源码管理 GitHub）	2	5	知道git基础命令，偶尔提交代码；目标：熟练使用Git管理项目代码，规范提交记录。	1. 所有练习项目使用git管理代码仓库 2. 学习分支创建、合并基础操作 3. 养成规范commit提交习惯

（2）阅读一下博客，并务必写一些心得：
a) 你为何要来上课并且认真参与
上课可以系统学习软件工程开发规范，补齐自学容易忽略的项目流程、文档与协作知识。自学缺少外部反馈，课堂与作业互评能及时发现问题。课程任务也能督促我坚持练习，把我在游戏直播积累的用户分析、自主学习能力迁移到后端开发，建立工程化思维。
b) 你在大学中体验到了哪种师生关系，你希望这门课是什么师生关系？如果老师布置的作业对你来说有些困难， 你会怎么样：
Buddies / Buddies (哥们 / 哥们)
E、再好好思考一下 请教ai ai解决不了再找同学老师
c) 在工作中，我们要引用文献，参考别人的资料，在别人工作的基础上继续开发， 这些活动和抄袭、剽窃的区别是什么？
合理引用与参考，需要标注来源、尊重原作者版权，仅借鉴思路，不直接挪用成果，属于站在前人基础上创新。抄袭剽窃不注明出处，直接复制他人成果冒充自己的作品，侵占原作者知识产权，属于学术不端。引用是合规借鉴，剽窃是窃取成果。
（3）未来方向与本学期规划
结合前人经验，我选择学习后端开发，并以游戏相关小型工具作为课程实践项目。优势在于我长期接触游戏行业，有游戏直播经验，更能理解玩家的真实需求，擅长从用户视角思考产品场景，在需求分析环节会更容易抓住重点。同时我自主搜集资料、迭代内容的能力较强，可以快速调研同类产品。劣势是后端基础薄弱，前两年荒废较多，代码工程化经验不足，在架构设计、单元测试等方面落后不少同学。

本学期规划：跟随课程补齐软件工程相关知识，系统学习后端基础；练习模块化设计、Git 版本管理，做好项目文档；以游戏小工具作为项目，逐步完成需求分析、架构设计、编码自测；坚持在博客持续记录学习随笔，积极参与同学代码互评，按时完成各项课程任务，稳步提升代码质量与工程实践能力。
（4）课程学习计划
参考国内外软件工程本科课程，我希望掌握规范化软件开发流程，建立工程思维，学会需求分析、架构设计、版本管理、项目文档编写。期待依托课程完成完整小型项目，将后端知识落地实践。课堂积极参与讨论，认真完成随笔、项目、互评等任务，本次课程不申请助教。
目前代码量：Python 约 2200 行，Java 约 800 行。入职一线互联网公司一般需要一万行左右高质量实践代码；从事高校科研教学，除代码能力外，还需要科研项目与论文积累。
每周投入课程时间：12 小时（包含课堂时间），选择D：比以前课要多很多，直到达成目标为止。
课程结束目标代码量：4000 行，每周完成 300 行实践代码。

WOOP

Wish：学好软件工程，独立完成游戏工具课程项目，补齐工程开发短板，坚持博客记录学习过程，养成规范编码习惯。
Outcome：能够独立完成完整软件项目，熟练撰写项目文档、做模块划分与代码评审，后端工程能力得到提升，为后续求职打好基础。
Obstacles：内部障碍：后端基础薄弱，容易分心、拖延，调试 bug 容易烦躁；外部障碍：其他课程占用时间，游戏娱乐容易分散注意力。最可能失败因素：自律不足，任务持续拖延，导致项目进度滞后。
Plan（If-then 预案）：

1. 如果出现拖延不想编码，那么立刻启动最小任务，先写 20 分钟代码。
2. 如果娱乐内容干扰学习，那么将手机放到别的房间，专心完成当前模块。
3. 如果长时间无法解决 bug，那么先记录问题，查阅资料或和同学交流，不盲目死磕。
   三、提有质量的问题，给认真的反馈

问题 1（第 1 章 概论 1.3 软件工程目标：足够好的软件）

我看了这一段文字：软件工程的目标，是在约束条件下做出 “足够好” 的软件，而不是无限追求完美。
我有这个问题：如何判断软件已经达到 “足够好”，避免两种极端，一种是不断加功能无限延期，另一种是仓促上线留下大量隐患？
我查了资料，MoSCoW 优先级方法可以划分必须、应该、可以、暂不做需求；MVP 最小产品思想优先交付核心功能。根据我的实践，我之前构思游戏小工具，总想一次性做完全部功能，导致项目迟迟无法交付。
但是我还是不太懂，针对小型课程项目，“足够好” 的量化标准应该怎么设定？

问题 2（第 2 章 敏捷开发 2.1 敏捷原则）

我看了这一段文字：敏捷强调可用的软件高于完备的文档，个体和互动高于流程和工具。
我有这个问题：新手团队在敏捷开发时，如果过度弱化文档，会不会导致后续维护、代码交接困难？
我查了资料，敏捷不是不要文档，只拒绝冗余文档，提倡刚好够用的文档。根据我的实践，我自己写代码习惯不写注释文档，后续回看自己代码很难看懂。
但是我还是不太懂，单人课程项目里，敏捷流程是否还需要保留需求、架构这类基础文档？

问题 3（第 13 章 软件测试 13.1 单元测试）

我看了这一段文字：单元测试由代码作者编写，用来验证模块逻辑正确性，是质量保障基础。
我有这个问题：当项目工期紧张时，单元测试会占用大量编码时间，优先级是否可以降低？
我查了资料，很多企业实践证明，前期单元测试能大幅减少后期调试、修复 bug 的总耗时。根据我的实践，我写代码习惯写完直接手动运行测试，几乎不写单元测试。
但是我还是不太懂，对于小型后端工具项目，单元测试覆盖到什么程度就够用？

问题 4（第 16 章 IT 行业的创新 16.1 创新的迷思之五）

我看了这一段文字：迷思之五：要成为领域专家，才能创新；事实是 70% 的创新来自本领域之外。
我有这个问题：作为后端新手，缺乏深厚技术功底，依托游戏行业经验做小工具创新，会不会技术能力限制创新落地？
我查了资料，很多工具类产品创新不在于底层技术突破，而在于挖掘用户未被满足的需求。根据我的实践，做游戏直播时我能发现玩家痛点，但是经常受限于代码能力没法实现工具。
但是我还是不太懂，这种需求层面创新，如何评估它是否属于软件工程意义上有效创新？

问题 5（第 8 章 需求分析 8.2 Kano 模型）

我看了这一段文字：Kano 模型把需求分为基础需求、期望需求、兴奋需求。
我有这个问题：面向游戏玩家的工具，怎么快速区分哪些是基础刚需、哪些只是玩家一时感兴趣的兴奋需求？
我查了资料，可以通过问卷、用户访谈收集反馈来分类需求。根据我的实践，直播时经常收到玩家提出很多花哨功能想法，很难判断是否真的必要。
但是我还是不太懂，用户主观喜好波动很大，Kano 模型在小众玩家群体里会不会失效？
四、前车之鉴
C.https://book.douban.com/subject/4006425/discussion/22802960/
读完这位学长的大学成长经历，我深受启发。学长大学前期也曾心态浮躁、自负自卑反复波动，看似盲目学习、广泛涉猎，却坚持逐行敲代码、精读经典书籍、坚持自学积累。他让我明白，大学没有无用的积累，所有看似不起眼的沉淀，都会在未来不经意间发挥作用。

学长最大的经验教训是：广而不深的学习收效甚微，深耕吃透知识远比浅学多书更有价值。反观我自己，前两年荒废学业、基础薄弱、学习浮躁。今后我会借鉴学长踏实实干的学习方法，沉下心深耕后端知识，坚持动手实践、积累笔记，拒绝敷衍学习，稳步补齐短板，踏实走好大学剩余路程。
G. https://news.cnblogs.com/n/531362/
我是科班学生，但前两年荒废，后端只懂皮毛，某种意义上有 “野生自学” 的状态，会写能运行的代码，但工程规范薄弱。科班给我的优势是有体系课程、作业与团队互评的环境，但如果只是被动上课，一样会变成 “野生式” 学习。

文章也提醒我：出身不是决定性因素。不管科班还是自学，核心是补齐工程能力，重视测试、文档、版本控制。我不能只满足代码跑通，要利用课程训练规范开发，规避野生程序员重广度、轻深度的短板。
B.https://book.douban.com/subject/4006425/discussion/22803961/
作者是计算机科班出身，本科成绩优异、手握奖学金，却只是机械听课刷题，没有真正吃透知识，看似科班，实则并未学懂计算机。毕业后在企业工作，业务偏向系统集成，缺少深耕技术的环境，于是选择工作三年后考研进入清华读研。

旁听朱仲涛老师的数据结构课让他醒悟：计算机学习重在动手实践与主动思考，而不是死记硬背。求职面试的失利，更让他意识到自己基础不扎实，很多知识只知其然，不知其所以然。这提醒我，无论是不是科班，不能满足于完成作业、拿到分数。学习计算机要主动深挖底层原理，多动手编码，养成独立思考的习惯，扎实打磨基本功，避免只停留在表面学习。

https://github.com/ZYY190/ZYY190