第一周作业

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

1.自我介绍
大家好，我是24级计算机科学与技术6班的陈建志。我性格内向，平日喜欢看动漫打游戏。我没有特别出众的特点，若要硬说的话，做事严谨、踏实负责，同时语言学习能力也是我引以为傲的技能。
内向的性格也助力了这些特质，让我能够沉下心，长时间专注查阅文档、调试代码，适合静下心钻研技术问题。严谨踏实的习惯同样可以迁移到软件工程学习中：写代码仔细校验边界条件，做完项目主动复查，对待测试、文档工作不敷衍，认真完成分配的团队任务。

2.现状、经验和计划
（1）起点
说起为什么学计算机，还得从游戏讲起。我很喜欢玩《炉石传说》，玩得多了，就开始好奇那些个体之间的互动到底是怎么实现的——为什么打出这张卡就能触发连击，为什么每个随从会有不同的状态。带着这份好奇，我最初选择了数字媒体技术专业，想离游戏和交互更近一些。但深入学习后我发现，自己更想弄明白的其实是这些现象背后的逻辑：一套系统是怎么被设计出来、又是怎么跑起来的。于是在大一，我转专业来到了计算机科学与技术。可以说，是游戏把我领进了门，但真正让我留下来的，是对"这些东西到底是怎么工作的"那份好奇心。

技能	当前水平	课程结束期望水平	提升手段
程序理解	4	6	每周精读一个开源项目的小模块（先选star高、文档完善的仓库），先看懂再自己复述，学习别人的模块划分、命名和注释习惯
架构、模块化、接口设计	2	5	把课程大作业当真实项目，动手前先画模块图和接口设计；每完成一个模块主动复查，写清接口说明，学习分层与解耦的常见做法
模块实现	3	6	每学一个知识点就动手写代码并跑通，不只看懂；坚持每周积累代码量，用博客把自己写过的东西复盘一遍
效能分析和改进	2	6	学习用复杂度（big-O）预先估算效率，并学会使用profiler等性能分析工具；对做好的模块主动做基准测试，读英文原版优化资料（发挥我的语言优势）
调试	2	5	改掉"靠猜、只靠printf"的习惯，遇到bug按"复现->二分定位->看日志/断点->修复->补回归测试"的流程处理，并习惯在自己的代码里加日志
大数据处理	1	6	先打牢 SQL/Python 数据处理基础，再系统学习一个大数据的框架（如Spark），用它跑通"读取->清洗->分析->出结果"的完整流程；找一份真实数据集做个小项目并写博客记录
对照技能调查表自评后，我离一名合格的IT毕业生还有不小差距：缺少真实项目经验，写过的代码大多是课程作业；调试手段单一，遇到bug主要靠猜；对性能分析和架构设计几乎没概念；团队协作和文档能力也还在起步阶段。

(2)a）大学生上课为什么一定要认真听讲？
Scalers这篇博客最打动我的一句话是："认真听讲是一种能力，能力就像肌肉一样需要训练。"我以前总觉得认真听课是态度问题，想认真就能认真；读完才发现它是能力问题——如果大学四年每一堂课都放任自己走神，肌肉就会萎缩，到了关键时刻（比如面试、做项目）根本绷不起来。
我也认同他说的"不要用短浅的目光判断一门课有没有用"。我本来是因为喜欢游戏才学的数字媒体技术，后来转专业到计算机，一路上见过太多同学用"这门课没用、老师讲得水"来给自己不听课找理由。说实话，以我们现在的知识储备，确实很难判断一门课未来有没有用；与其带着情绪混过去，不如把它当成一次训练自己"入定"能力的机会。
不过我也看了北航那位同学（CookieLau）的思考，他提出了一点我很赞同：不能走到另一个极端。认真听讲不该是单向的强制，好的课堂本身就能吸引学生——他写的高宁老师、还有那位"上课只打开 VS6 现场敲代码"的 C++ 老师，都让人发自内心地不想走神。所以我的态度是：老师把课讲好，学生把耳朵竖起来，是双方的功课。 如果我觉得某节课确实收获不大，与其在底下玩手机，不如把疑问记下来，课后带着具体问题去问老师——这既是尊重老师的时间，也是对自己的学习负责。
b）我体验到的师生关系 + 我希望的关系
邹欣老师把大学里的师生关系分成了好几种：园丁与树苗、餐馆与食客、保姆与幼儿、路人甲与路人乙、老板与雇员，以及最理想的健身教练与健身学员。
上大学以来，我遇到最多的其实是路人甲与路人乙：几百人的大课，老师不认识我，我也不认识老师，下课各走各的。对双方而言，“打卡、下班”似乎已是固定模式。
我希望这门课是健身教练与健身学员的关系。教练不会替学员流汗，但会给出训练计划、及时纠正动作、在你偷懒时给你压力。我希望老师提出的任务有挑战性，让我们在实践中碰壁、反思、改进，而不是直接给答案；我也会带着目标来上课，主动练习、主动提问，对自己负责。
如果老师布置的作业对我来说有些困难，我会选C：向老师和同学请教，花更多时间，把作业全部完成。 具体做法是：先自己尝试解决（我有耐心，也习惯一个人先把问题啃下来），实在卡住超过一定时间，就整理好自己试过的方法和卡住的具体位置，带着明确的问题去请教老师或同学——请教不是"要答案"，而是请对方指出我思路里哪里断了。
c）引用、参考和抄袭、剽窃的区别
读了邹欣老师的文章，我的理解是：在别人工作的基础上继续开发、引用文献、参考资料，是正常且值得鼓励的学术和工程实践——学术论文本来就建立在前人研究之上，软件也总要基于别人的框架和模块。它和抄袭、剽窃的核心区别在于三点：
I.是否注明来源：引用了别人的观点、代码、文字，就要明确标注出处（写博客至少附上原文链接）；
II.是否经过自己的思考与加工：引用是为了支撑自己的论证，而不是整段照搬冒充原创；
III.是否符合使用许可：用别人的开源代码要遵守它的开源协议（如GPL、MIT），不能拿来就用不吭声。
邹欣老师在文章里举了一个很讽刺的例子：很多学生写"软件工程课总结"，连十几年前要求"Windows NT、Pentium 133以上"的配置说明都原样照抄——这种连自己都没读懂的复制，就是典型的抄袭。
关于这门课的底线和学校的规定，我会承诺：所有引用标注来源，使用开源代码遵守协议，课程核心代码独立完成，也不把自己的作业代码给他人抄袭。

（3）未来
几年后我可以选择学术研究、软件项目、公务员、出国深造等不同的路，每一条路的努力方向都不一样。我的打算是：本科毕业后继续深造，攻读硕士研究生，硕士毕业后进入企业做技术工作（方向偏向大数据/后端）。所以我现在做的每一件事，都在为"能申请上理想的硕士项目、并且读研期间跟得上"这个目标服务：
I.稳住学业成绩。 无论走哪条读研的路，成绩都是第一道门槛。大三正是专业课拉开差距的时候，我要求自己每门课不只要"过"，还要真正学懂，把绩点保持在班级前列。
II.尽早积累科研、项目和竞赛经历。 读研申请看的不是"我上过什么课"，而是"我做过什么"。我计划大三主动联系老师进实验室或参加大学生创新创业项目；把课程大作业做成能演示、能讲清楚的完整项目放到 GitHub；有机会就参加算法类、软件类竞赛，锻炼实战能力。
III.把专业基础打牢。 数学、数据结构与算法、专业课，是研究生阶段学习的共同地基。现在每多花一点时间弄懂一个概念，将来读研就少一分吃力。
IV.坚持写技术博客。 把做过的项目、读过的论文、踩过的坑都记录下来。写博客既是逼自己把知识想清楚，也是在积累将来申请或复试时能拿得出手的个人材料。
说到底，"深造再工作"是一条更长的路，但硕士不是终点，而是中间站。我希望读研阶段能把工程能力和研究能力都练出来，毕业后带着更强的竞争力进企业。而现在的每一节课、每一行代码、每一篇博客，都是在为几年后攒选择权。
（4）本课程计划
I.对这门课的期待和打算
我读了老师推荐的几篇教学文章，对"好课程应该长什么样"有了更具体的想象：
一篇留学前辈的日记让我看到美国大学课堂的特点：重视学生参与、制度设计细致，学生学业压力普遍很大，这和国内常见的"老师讲、学生听"很不一样；
一位国内学长总结他的软工实践课：学会了Git/GitHub协作、用Markdown写博客、做需求分析、把大目标拆成小任务，也体会到"先做核心功能"和"先完成再完美、用迭代改进"；
邹欣老师转发的UCSD软件工程课实录最让我向往：整门课模拟一家公司，8人一组各有角色（项目经理、架构师、QA……），每周开"客户会议"展示进展、交time card、互相peer review。老师第一堂课就说："You can't learn it unless you actually do it."——软件工程不是听会的，是做会的。
所以我对这门课的期待是：以真实的团队项目为核心，过程化地走完需求→设计→实现→测试→交付的全流程，而不是期末交一个大作业了事。我打算这样度过：跟紧每周任务节奏，主动在团队里认领角色；从第一周就用 Git/GitHub 管理代码；每次作业、每篇博客都当作一次"迭代"，先完成再打磨；遇到问题主动问，不复盘不放过。
II.关于当助教
读了《助教之路》我了解到，现代实践课程任务密集，好的助教是课程持续运行的保障，当助教也能锻炼表达和组织能力。不过我这学期暂时不申请当助教——我觉得当助教的前提是把课程内容真正吃透，这学期我想先把项目、博客和课程本身学好，如果以后学有余力再考虑。
III.代码量现状与目标
我目前的代码量约2000 行，主要是：
-C语言：约1200行（课程作业和小项目，如链表、排序、课设等）
-Python：约800行（数据处理、爬虫等小练习）
想有资格入职一流的软件公司/互联网/人工智能公司，本科毕业前一般至少要有 1 万行以上代码的积累，而且不能只堆数量，还要有能拿得出手的完整项目。
从事高校教学科研工作，不能只拼行数，关键是能独立实现、复现研究中的原型和实验；通常也需要数千到上万行的积累，但更看重每一行背后的理解深度和代码的可复现性。
IV.时间投入与代码量计划
我打算平均每周在这门课上投入 12 小时（含上课时间）。
前两年我在编程上花的时间不算多，现在想认真拼一次，所以我选择D：比以前课要多很多，直到达到目标为止。 这门课是实践课，投入多少收获多少，我希望期末能拿出一个自己满意的项目，所以愿意多花时间。
我计划在本课程结束时，累计代码量达到5000行以上（本学期新增约3000行）；按15周计算，每周约完成200行，考试周可适当减少，但平均线不破。
V.WOOP
Wish（愿望）：到课程结束时，和团队一起完成一个功能完整、能演示、能讲清楚来龙去脉的软件项目；自己完整走一遍软件工程流程；本学期新增约3000行代码、发布至少8篇技术博客；技能表里最弱的"调试、性能分析"从1~2分提高到5分左右。
Outcome（最好的结果）： 期末展示时能自信地演示我们的项目，老师问到的每个设计决策我都能说出为什么；博客连成一条清晰的成长线；GitHub上有能写进简历的项目。回头看这学期熬的夜，会觉得都值了。
Obstacles（障碍）：
拖延：晚上总想"先打一局游戏/再看一集番"，结果拖到很晚才开始，质量也差；
-内向不敢问：遇到问题习惯自己硬磕，可能一磕就是一下午；
-基础不够扎实：Git、自动化测试这些工具还在现学；
-大三事情多：其他课程和未来规划的事容易分散精力；
-完美主义：总觉得博客或作业"还没准备好"，拖着不发。
最可能的失败因素： 不能长期自律 + 拖延。热情往往只有三分钟，学期中段最容易松懈。
Plan（"如果……就……"）：
-如果晚上想先打游戏/看番再写代码，就先把当天的代码或博客任务完成，再把娱乐当奖励；
-如果一个问题卡了超过1小时，就停下来，记下现象和自己试过的方法，带着具体问题去问同学或在课程群提问；
-如果觉得博客"没写好"不想发，就提醒自己"先完成再完美"，先发初版再迭代；
-如果某周任务多到想放弃，就把任务拆成"今天能完成的最小一步"，每天推进一点；
-如果连续几天松懈，就在周日回顾本周实际代码量，和计划对比，调整下周安排；
-如果又熬夜，就把软工任务固定到精力最好的时段，睡前不碰手机和游戏。

3.提有质量的问题
我快速翻阅了《构建之法》全书，先按老师提示跳过了暂时读不懂的章节，重点读了与自己经验相关的部分。下面是我读完后的5个问题。
Q1（第1章「概论」）：软件工程这套流程，从多大开始才"划算"？
书中强调软件工程是把系统的、有序的、可量化的一套方法应用到软件开发中，提倡计划、文档、复审这些活动。
我的问题是：我平时自己写 Python 小工具、爬虫，一两百行，一个人用，从不写文档、不写测试，跑通就行——如果给这种小东西也套上完整的软件工程流程，成本可能比写代码还高。那软件工程到底从多大的项目、多少人的团队开始才值得？书里似乎默认了"我们都在做大项目"，但没有明确给出这个"分水岭"在哪。
我查过一些讨论，有一种说法是"流程是为沟通服务的，一个人不需要和自己开会"。我的间接经验也支持这一点：上次我和同学合作一个小课设，两个人没提前约定接口，最后联调时互相改得很痛苦——人一多，没有流程确实会乱。但人少时流程又确实是负担。
我的困惑是：这个临界点到底由什么决定？是人数、代码量，还是项目要活多久？书里能不能给出一个学生能操作的判断标准？
Q2（第4章「两人合作」）：结对编程在"水平差距大"和"AI 时代"还成立吗？
书中介绍了结对编程：两个人一台电脑，一个当"驾驶员"敲代码，一个当"导航员"看代码、想问题，并且建议定期互换角色。
我有两个疑问。第一，我性格比较内向，习惯一个人安安静静写代码，结对会不会反而降低我的效率？第二，书中讨论结对时默认的是"两个水平相近的人"，但现实里水平差距大才是常态；而且现在很多代码是 AI 生成的，如果我的"搭档"是 AI，这种模式还成立吗？
我的经验是：我给别人讲清楚一道题时，自己对它的理解会明显加深，所以我相信"说出来"是有用的；但我也确实觉得独处时更专注。我查到的资料里，有研究说结对编程在复杂任务上效果更好，在简单任务上反而拖慢速度。
我的困惑是：书中说结对的好处建立在"双方水平相近、都认真参与"的假设上，那如果一方明显更强或更弱，结对该怎么组织才不至于变成"一个人写、一个人看"？
Q3（第6章「敏捷流程」）：敏捷说"可工作的软件高于文档"，那文档到底还要不要？
敏捷流程强调尽早交付可工作的软件、拥抱变化，而不是死守文档和计划。但书中其他章节（比如代码规范、测试）又明显要求留下各种文档和记录。
我的问题是：对课程这种 8 人团队、一学期 15 周左右的项目，在"完全不留文档"和"文档驱动开发"之间，到底该站在哪里？这个尺度由谁来定——PM、全体成员，还是老师？
我的间接经验来自一位学长的软工实践总结：他当 PM 时反复强调"需求一定要记录、接口说明一定要写清楚"，否则后面根本没法合作；但同时也说会议太多会拖慢进度。这说明文档不是越多越好，也不是越少越好。
我的困惑是：书里给了敏捷的原则，但没有给"文档写到什么程度算刚好"的可操作方法，学生团队很容易走极端——要么不写，要么为了交差写一堆没人看的文档。这个度怎么把握？
Q4（第8章「需求分析」）：没有真实用户的学生团队，怎么避免"自嗨"？
书中说用户说出来的需求不一定是真实需求，真正的需求往往被过时的假设和误解遮挡，需要去挖掘；还介绍了 NABCD 这样的分析方法。
我的问题是：对课程项目这种"自己给自己定题目"的团队，很容易做出一个自己觉得很酷、但根本没人用的东西。没有真实用户的时候，怎么判断一个需求是真需求，还是我们想象出来的"伪需求"？
我的经验来自游戏：我很喜欢玩《炉石传说》，它的卡牌平衡经常调整，靠的是海量玩家的对战数据，而不是设计师拍脑袋——这说明"需求/体验是否成立"最终要靠真实反馈来验证。而我以前做课程设计，基本是"做完就扔"，从没验证过有没有人真的会用。
我的困惑是：书中教的 NABCD、用户调研都默认存在真实用户。学生团队如果找不到真实用户（比如只能拿同学、老师当用户），这些方法还适用吗？有没有低成本验证"伪需求"的办法？
Q5（第17章「人、绩效和职业道德」）：老师让我们定"代码量目标"，但书中说代码行数不是好度量，矛盾吗？
我在书中读到，衡量工程师的工作不能简单看代码行数，行数多不代表质量高，甚至可能鼓励写出冗长、重复的代码。
但很有意思的是，本课程的作业恰恰要求我们制定"本课程结束完成多少代码量、每周完成多少行"的计划。这不是矛盾吗？
我的理解是：老师让我们定代码量，可能不是把它当绩效标准，而是当过程指标——逼我们养成持续编码的习惯，就像健身先保证训练次数。但我也担心，如果我真把"每周 200 行"当目标，可能会为了凑数写出很多重复代码。
我的困惑是：既然行数不适合当绩效度量，那它适不适合当学生阶段的"学习计划指标"？如果适合，该怎么定才不至于走偏？有没有比行数更好的过程指标（比如每周提交次数、解决的问题数、博客篇数）？
认真反馈
我选C：有问题就问，至少一学期提三个问题，认真按时填写反馈。
说明：我性格偏内向，以前习惯自己闷头解决，很少主动提问。这门课既然是"健身教练与学员"的关系，学员不反馈，教练就没法调整训练计划。所以我给自己定的底线是：这学期至少主动提三个问题（不限于课堂，也可以在博客评论、课程群里），每次课程反馈认真填写，不敷衍；如果状态好，我希望自己能做到D——平时有问题就及时反馈，而不是攒到学期末。
**4.前车之鉴 **
感想一：读《辜新星：时刻调整方向 找到人生的蓝海》——把ABCD分类法用起来
链接：https://book.douban.com/subject/4006425/discussion/22803733/
辜新星大一的时候是"社团狂"，每周光例会就有三个半，忙到高数期中不到 80 分才惊醒——瞎忙不等于努力。他后来从学长那里学到一个方法：把每天要做的事分成四类——A 紧迫且重要、B 重要不紧迫、C 紧迫不重要、D 不重要不紧迫，然后按顺序给每件事安排一段专属时间，在这段时间里只做这一件事。
这个方法简直是为我量身定做的。我在前面 WOOP 里写到自己最大的障碍是拖延：晚上总想"先打一局游戏、再看一集番"，结果重要的事拖到深夜。用 ABCD 这套来想，打游戏看番就是典型的"D：不重要不紧迫"，而我却总让它们插队；真正决定我成长的事——写博客、读文档、补 Git 和测试这些基础——全是"B：重要但不紧迫"，最容易被无限期推迟。
所以我打算从这周开始：每天晚上花五分钟把第二天的任务按 ABCD 列出来，给 B 类任务也排上固定时间（比如每晚先完成当天的代码/博客任务再娱乐），并且学他"时刻调整方向"的做法，每周日回顾一次，看看自己有没有又偏回"瞎忙"或者"拖延"的老路上去。
感想二：读《刘帅：在失望中寻找希望》——最怕的是"科班却没学懂"
链接：https://book.douban.com/subject/4006425/discussion/22803961/
这篇文章最戳我的一句话是标题里的那句自嘲："我是科班，却没学懂计算机。" 刘帅是正牌计算机专业出身，成绩一直排在前面、每学期拿奖学金，但他自己承认，那些年他只是"机械地听讲、机械地做作业"，从不主动思考"为什么要这样做"，结果数据结构这类需要大量动手的课，被他上成了一门"几乎不用写程序"的课。
我读的时候很心虚，因为我也经常有这种感觉：上课听懂了，作业照老师讲的路子也能做出来，但要是有人追问我一句"为什么这样设计？换个情况还成立吗？"，我就答不上来。我在技能自评里给自己的"调试"只打了2分，原因也一样——平时写代码只求"跑通"，从不去想它为什么错、怎么系统地定位，所以遇到bug只能靠猜。
刘帅后来在面试里吃了大亏：被问到"Lucene 的索引是怎么实现的""自动化测试框架怎么设计"，他全答不上来，因为从来只知其然而不知其所以然。这个教训我记下了：完成作业不等于学会，会做题也不等于理解。 我给自己定的对策是——这学期每做完一个功能模块，就追问自己三个"为什么"（为什么这么设计、有没有更好的方案、哪里可能出错），并且把"不懂就问"变成习惯，而不是像以前那样不好意思开口、自己硬磕一下午。

5.GitHub 仓库
这是我的GitHub同名仓库（README里有我的自我介绍）：这是我的仓库：https://github.com/DexJocelyn/DexJocelyn