软件工程第一周作业

第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	第一周作业
这个作业的目标	了解课程习惯，探究个人成长路径，学习搭建自己的资料库。与老师交流，达成共识，努力提升自我

1. 介绍自己，建博客

大三计算机科学与技术在校生。
细想一下，除了当时冲击工作室，拼命写代码，其余时间的课程学习来看，在计算机上的能力并不显著。对于本专业，更多像是旁观者看着怎么运用，了解了底层的逻辑，还没有到达设计创造的能力，甚至有些专业知识因为没有运用也淡忘了。但，我还有其他闪光点和爱好，支撑我不断尝试、挑战、提升。
我能言善道，参加过大大小小的演讲、交谈类活动，也得到过相关的奖项。善于沟通交流，敢于表达自己，人际交往自然也十分融洽，简直E人降临。比较享受独处，偶尔会制作手账，记录好玩的事情或者无聊的发呆、胡思乱想。运动类的球项都接触过，算入门吧，因为贪玩，想尝试不同的规则玩法和团队协作。可能比较擅长排球，不过很久没打了。长期坚持舞蹈的练习吧，加入了社团，经常有些表演，虽然每周晚上要抽空去练习，但跟朋友一起不觉得疲惫，挺开心的。喜欢音乐，但是总找不准调，跟朋友唱K，朋友挺包容我的。大致就是比较喜欢尝试新事物，大一什么讲座啊活动啊都去看了看，比赛也有参加，挺有收获的，也得到了成长。

目前迫切希望找到自己的心属，不断冲击成长。

2. 现状、经验和计划

（1）技能调查

为什么选择计算机，是因为信息化发展的趋势，这个专业前景ok；而且我比较想要看看自己能从零基础走多远。离成为一个合格的 IT专业毕业生，在专业知识上，基础知识熟悉，但运用不太OK；在技能上，代码的运用不算熟练，训练量不够多，但比较熟练运用cursor辅助代码，运用AI工具还是可以的；在能力上，就是理解深度和熟练度不好，而且对于一个项目的目的和设计有时候会无从下手，调用知识的能力欠缺。

技能项	① 目前水平 (0-9)	② 目标水平 (0-9)	③ 提高手段
编程语言	4	7	看竞赛课程，刷洛谷力扣。尝试做小项目
软件实现	5	8	多去看代码，理解编写逻辑封装逻辑，尝试练习，多写注释
项目管理	3	7	多练习，复盘归纳经验
软件设计	3	7	阅读游戏设计项目的计划书 ，多观察思考设计
单元测试与调试能力	4	7	调试时先复现最小用例再动手，记录错误，归纳原因

（2）阅读心得

a) 你为何要来上课并且认真参与

Scalers的文章让我重新理解了上课的意义，我发现我曾经也有这样的思考。

认真听讲首先是一种需要刻意训练的“专注”能力，课堂正是最现成的训练场，如果因为课程“没用”或老师讲得“水”就放任自己走神，损失的其实是让自己“入定”的核心肌肉；与此同时，来上课本身就是在对抗人性中趋易避难的惰性，防止理解力和思考力在无人监督时悄悄下滑。我曾经能阅读长篇小说，并且专注度高。但是由于短视频的兴起，自己好像就丧失了长时间专注和静下来阅读反复思考推敲的能力。这一改变也让我意识到人的惰性带来的坏处，依赖科技，不再主动思考，专注度自然而然地下降。与其说课堂水，不如说我们逐渐丧失专注听课的能力，更何况，我们无法预判哪块知识会在某一天被调用，但可以确定的是，今天能认真对待每一堂课的人，明天才更有可能认真对待每一个项目、每一份工作。 因此，我选择来上课并认真参与，不是为了表演勤奋或取悦成绩，而是在为自己未来的专注度和学习能力、思考能力做一次次的健壮性加固。

b)师生关系

我比较倾向于健身教练 / 健身学员的关系。主动求知求学，提升自己，健身教练只能教导督促鼓励学员，无法逼迫学员进步。需要我们自身发挥主观能动性，改变自我，接受老师的建议要求，不断成长。
如果老师布置的作业对你来说有些困难， 我会向老师和同学请教，花更多时间，把作业全部完成。

c) 参考和抄袭、剽窃的区别

参考是有思考的站在前人肩膀上进行自己的新内容的创造提升，抄袭剽窃就是照搬他人成果，占为己有，没有个人思考和提升。参考是有标注出处的，提示阅读者，他人成果的告知。
在此次课程学习中，自然会阅读前人的资料和成果，一定要标注出处。在查看使用他人开源项目，遵守规则，不恶意篡改、不占为己有。同时，作业也不借给他人抄袭，自己的作业自行独立完成。

（3）未来规划

未来，我想要从事软件测试行业，或者考公进入编制。无论什么选择，学习课程，得到知识，提升学习能力都是关键。

相比于其他同学的优劣势

优势：敢于去尝试，去学习，专注提升自我，懂的复盘，有一定的项目经验；
劣势：代码量绝对值偏低，对应经验比较少，技能不突出。

（4）课程计划

对于课程，我比较期待：不只是“学知识”，而是“做项目”，体验真实的开发流程，不断提升代码和设计能力。

我打算怎样度过这门课：
课前：复习上一节课内容，大致看一下后续课程，提前了解老师的授课内容。
课中：训练“专注的肌肉”，记录重点和难点，方便课后复盘。
课后：当天整理笔记，每周投入课外时间用于阅读代码、写项目、做测试，目前正在规划学习和尝试做测试的相关项目。
项目：把课程项目当作“求职作品集”来做，写入自己的项目经历中，不断完善提升。

代码量：

语言	代码量（行）
C	~3,000
HTML/CSS/JS	~1,000

我计划平均每周拿出10~12小时（包含上课时间）用在这门课上。
我选择：D —— 比以前课要多很多，直到达到目标为止 来对待这门课。
代码量目标：课程项目+作业+自练=新增3,000行以上，每周应完成约300行有效代码（项目代码+测试用例）。

WOOP计划

步骤	内容
W — 愿望	①完成一个完整软件项目（≥2000行，测试覆盖率≥70%）；②养成“测试先行+规范编码”的肌肉记忆； ③总评成绩≥85分。
O — 结果	①GitHub上有拿得出手的项目作品；②能够展示真实的测试用例设计和Code Review记录；③成为能够设计创造的人。
O — 障碍	①静不下心：写10分钟代码刷5分钟手机；② 完美主义拖延：觉得没想清楚就一直不动手；③ 遇bug想逃：卡住30分钟就关电脑“明天再说”；④ 多课撞车：其他作业挤占本课时间。
P — 计划	把手机放远，深呼吸静下来，思考今日目标，开始动手做；先写一个完成基础功能的版本跑通再说；遇到bug，拿纸笔画流程图，或问同学老师，绝不留到第二天；进行合理时间规划，保证一个项目功能优化，绝不中断。

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

《构建之法》阅读随笔 —— 五个问题

Q1 对于一个还没有任何历史数据积累的学生，PSP 的记录成本是否会超过它带来的收益？

引用： 第2章 个人开发流程 PSP

引起提问的原文大意：作者提出工程师应该用PSP记录自己在计划、设计、编码、测试各阶段的实际耗时，并据此改进下一次的估计。

有观点认为PSP的价值主要来自长期数据积累后的趋势分析，短期单次数据意义不大；同时，人对时间的自我报告存在系统性偏差（普遍低估调试时间、高估编码时间）。
我的实践经验：我在C语言程序课程设计里试着记了多份数据和功能板块的改善点、完成度，结果发现自己估计两小时能写完的模块实际花了六小时，其中2小时在调试一个模糊搜索问题。这个数字让我焦虑，耗时但是效果不高。但我也发现，光是记下来功能缺陷、改善点这个动作本身就花掉了每天十几分钟。最后这项功能还是基础过关，记录下来，思考如何完善的实际耗时会比预期想的还要久。
我的困惑：作者似乎默认PSP是从第一天就该做的正确的事。我想问的是：对新手是否应该先用粗粒度记录（只分写代码，调试，查资料三类），等积累了一个月再细化？还是说粗粒度的记录会失去PSP的意义？

Q2 两个人共同产出一份代码，总产出效率是否真的高于两人分开写两份？书中引用的实验多以质量提升为指标，那效率这一侧呢？

第 4 章 结对编程

引起提问的原文大意：作者介绍结对编程中驾驶员与领航员的角色分工，认为不间断的复审能显著提升代码质量。

支持方引用结对编程在缺陷率上的改善数据；反对方则指出结对编程的收益与任务难度强相关 —— 对高难度任务收益明显，对简单、机械性任务则可能是浪费人力。另外长时间的结对会带来疲劳与人际摩擦。
我的实践经验：我和同学结对做实践报告时，前两小时体验很好，两个人互相有交流有思考，简单问题很快得到解决。但超过三小时后，我明显感觉到两人的注意力都在下滑，开始看手机、聊天，而且难题就留在那里，积极性不高，也不太愿意主动去做，后续快到截止日期，才又抓紧赶工完成。
我的困惑：书里对结对编程的介绍偏向正面。我想确认：作者对结对编程的推荐是否隐含了任务足够难、单次时长受控」些前提？如果这些前提不成立，结论是否要打折？

Q3 在一个成员每学期都在换的学生团队中，弱化文档是否会造成知识断层？

引用：第 6 章 敏捷流程

引起提问的原文大意：敏捷宣言主张可工作的软件、高于、详尽的文档。

敏捷方法普遍强调面对面沟通和团队自组织，其有效性依赖于团队成员的长期共处和共同上下文；在人员流动率高或分布式协作的场景下，业界通常会引入更多文档作为补充。
我的实践经验：我做计组实验为了赶进度几乎没写文档，完成很顺利，实验结果也对。但课后写报告的时候，就有点忘记怎么做的，具体遇到的问题和解决方法没有记录，结果下一次实验，相似的问题碰到了，要思考好久才能回想自己的解决方法。最后花了时间理清楚，而这足够完成一个小实验了。
我理解敏捷反对的是为了写文档而写文档，但我认为作者对文档的批评在学生团队这个场景下会误导人。因为学生团队恰好缺乏敏捷所依赖的那个前提（稳定的共同上下文），通畅做完之后，不清楚到底完成了什么，没完成什么，完成部分哪一些可以优化。如果让我选，我会坚持保留一份记录，记录自己的步骤和合作的内容，关键功能点等等。

Q4 大量刷题、背诵面试八股文算不算在积累技能？如果不算，为什么它在实际招聘中确实有效？

引用：第3章 个人能力的衡量与发展

引起提问的原文大意：作者提出技能的反面是解决问题，并区分了不同层次的问题 —— 低层次问题靠记忆与熟练即可解决，高层次才体现真正的技能。

一种说法是，模式识别是专家能力的重要组成部分，通过大量练习建立问题—解法的快速映射，本身就是专业能力的体现；另一种说法则强调，脱离真实场景的熟练只是应试技巧，无法迁移到陌生的工程问题。
我的实践经验：我刷过洛谷，确实感到看到类似题型反应更快了。但我也发现，一旦题目换了个壳（比如把算法题包装成一个实际应用的简化问题），我常常识别不出这就是我练过的那类问题，并且很难两者之间相互转化，这是否说明我的映射绑定的是题型表面特征，而不是问题本质。
我的困惑：作者把技能分层讲得很清楚，但没有给出如何判断自己处在哪一层的方法。我该怎么检验自己是在积累技能还是在积累应试熟练度？

Q5 书中关于创新的案例多来自资源充足的组织内部（大企业、成熟团队）。对于资源极度受限的个人或小团队，作者的路径是否仍然成立？

引用：第16章 创新的迷思

引起提问的原文大意：作者列举了关于创新的若干迷思，指出创新不是灵光一闪，而是长期积累与持续改进的结果，并讨论了创新者需要具备的素质。

有观点认为，资源约束反而是创新的催化剂 —— 受限条件下的创新往往表现为重新组合已有要素而非投入新资源；也有观点认为，缺少资源支撑的创新很难跨越从原型到规模化的鸿沟。
我的经验：共享单车当年火爆全国，不是积累，而是看到了人们的所需，提出的创新。虽然初代破产，相当于在行业创新路上积累了经验，最后得到新的经营模式，至今盈利。
我困惑的部分：我有点不完全赞同「创新需要长期积累」被解读为「必须先积累再创新」。我的经验是，对新手来说，先做出一个能解决自己问题的东西，比先读够理论更容易形成正反馈。积累和创新不是先后关系，而是可以互相驱动的。先发现了可以提升的创新点，所以想着要去创新改善，在改善中不断积累，最后成功创新

课程反馈选项：D
我选择 D：经常提问题，平时就经常给老师和助教提反馈。
我未来想做软件测试，而测试工程师的核心工作就是“发现问题、提出问题、推动改进”。我会持续在学习中发现问题、积累问题，勇敢提问。提问和反馈本身就是我需要刻意训练的“专业肌肉”。正如Scalers所说，“认真听讲是一种能力，能力就像肌肉一样需要训练”——提问也是。

4. 前车之鉴

1、https://book.douban.com/subject/4006425/discussion/22803733/

我也是如此刚进入大学，每天都很忙，但是不知道在忙碌什么，思考下来得到的成果也不多，不清楚时间消耗在哪里。后面也是听了讲座，得到了一个建议，跟作者相似的建议。

他很干脆地给了一个建议：做好短期时间规划。具体而言，要把每天把要做的事情分成A、B、C、D四类：
A——紧迫且重要；B——重要不紧迫；C——紧迫不重要；D——不重要不紧迫。
然后按顺序为每件事情安排一段专属的处理时间。关键的是，一定要在专属时间内专心致志地做好当前的事情，不受其他任务的干扰，这样才能提高效率。

于是，我也开始这样划分，但也发现了新的问题——执行时管不住自己。明明知道今天应该写代码（A类），却先刷了半小时B站（D类）；明明知道应该读书开始做作业（B类），却被一条微信通知拉去处理文件20分钟（C类）。辜新星学长的经验告诉我：不在于你知道多少方法，而在于你能不能“在专属时间内专心致志地做好当前的事情”。这也是他为什么强调“这是我从学长那儿获得的第一笔真正意义上的财富”——知道和做到之间，隔着一整个大学的距离。知道道理是不足够的，你还需要足够狠心，狠下来不要去想万一忘记D类任务等令人焦虑的内容，专注于重要的事情，碎片化时间利用去做D类的事情。
要做出一定的改变：
我每天早晨花5分钟写下当天的ABCD清单，并强制要求自己每天至少完成2项A类和1项B类，才能碰手机上的娱乐App。每周日复盘一次，看看ABCD的分布是否合理——如果C类和D类太多，说明我在逃避真正重要的事，让小事情占据时间，无法专注。做成一件大事情，就要每日专注在重点上，而不是因为小事情分心，导致重点事情没有时间和精力去完成。
同时，他后续的专注学习也值得思考。代码不仅仅是看懂，更是理解，更是自己动手去做。提前看书深度思考，进行知识储备，更是明确自己在做什么，自己能得到什么，而不是浮于表面的快乐获得。而且他会去请教老师，不会害怕自己的问题简单或者被老师为难，敢于提出自己的见解。老师是我们的引路人，而不是遥远的单纯的授课者，要学会主动找老师或前辈请教（不再怕“问题太蠢”），将“贵人指路”从概念变成行动。
鼓起勇气，迈出第一步，可能一开始成效无法显现，但整个过程的成长，这种成就感，自己也会为自己骄傲。

2、https://book.douban.com/subject/4006425/discussion/22802960/

文章中有这样一段话：

我带着三个理念进入了大学：第一是什么东西都可以自学，第二是慢即是快，笨笨地做一遍题是学习的捷径；第三是知识理想主义，知识就是力量，而读书学知识能够消除蒙昧，掌握改变世界的力量，所以是一件快乐的事情。

这段描述给我一种震撼，我还在迷茫阶段的时候，他就已经想好如何学习，如何改变自己、提升自己。
现在回想自己的学习经历，发现大一时，我觉得“什么东西都可以自学”意味着“不需要老师”。于是上课走神、不听讲，心想“反正回去看书也能懂”。结果正如徐宥在文章里描述的——大一时“上课根本不听讲，理由是‘书上的东西太简单了’”，本质上是一种极端自负掩饰下的极度自卑。课后，看着速成网课，觉得自己就能理解就能读懂，结果只是皮毛而已，时间长了知识就像流水一点也不曾留下痕迹。
第二是慢即是快，这一点在我们中华工匠上能察觉。但在快速发展生活下，我们追求高速，也很难慢下来雕琢，总是想找捷径，却又忘记了技能就像刻痕，不慢下来用力，是留不住的。只是自己自得，自己很厉害，其实到使用的阶段两眼一黑。

三是知识理想主义，知识就是力量，而读书学知识能够消除蒙昧，掌握改变世界的力量

这句话让我沉默了一下。不是因为我不认同，而是因为它戳中了我在某个时刻悄悄丢掉的东西。我不知道从什么时候开始，读书和学习变成了为了考试、绩点、找工作、不落后。这种功利的驱动力让我越学越焦虑——因为总有一个更功利的目标在前面，永远到不了终点。读书本来的快乐，是我高中看《飘》，看不懂，找解说的快来；是高中解答几何题，看教材详解答案，看懂的快乐。而上了大学，自由时间的掌控让我只看到了表面的快乐，却不愿意接触学习的深层次快乐。现在想来尤为羞愧，徐宥他享受的是知识本身，而不是知识的附属品。但对于我来讲，还无法做到如此纯粹，社会的竞争压力，让我们不得不考虑应试的冲分，刻板的回答，但我会往这个方向走，不断挖掘学习的快乐。
他说的这三个理念，缺一不可。只有敢于自学、甘于慢行、乐于求知三者兼备，才真正走在了有效学习的路上。

附：GitHub 仓库

探索无限成长可能。
我的仓库地址：https://github.com/ttr-rui/TTR-rui.git

附：博文编辑界面的截图