软件工程第一周作业

这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS
这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标 搭建博客与 GitHub 仓库；评估自身技术现状；制定软工学习计划与 WOOP 目标；阅读《构建之法》并提出思考；研读学长经验，理清考研与工程能力的关系。

一、介绍自己，建博客

我是 24 级计算机科学与技术专业的一名本科生。平时课余喜欢跑步、打点游戏，大部分时间都花在专业课和捣鼓代码上。

关于我自己：

  • 比较能坐得住：面对枯燥的算法推导或者一堆报错，我不太容易抓狂，能耐着性子查文档、一步步打断点排查。
  • 习惯记踩坑笔记：平时写小实验遇到 Bug 或者学完一个知识点，习惯在本地备忘录随手记上几句，省得下次掉进同一个坑里。

为什么现在开始写博客？
说实话，以前我觉得写博客都是技术大佬的事，自己水平有限，写出来也没人看。但看了老师推荐的文章后，我换了个角度想：写博客其实是给自己“照镜子”。平时看书或者抄了段代码跑通，总觉得自己全懂了；可真要自己用通俗的话写成文字讲给别人听时，才会发现哪里卡壳、哪里逻辑根本没走通。所以借着这门课，我打算把博客当成自己理清思路、记录真实踩坑经验的自留地。

二、现状、经验和计划

(1) 专业选择与自身差距

  • 为什么选了这个专业？
    说实话，高考填志愿时一方面是听了家里的建议，觉得计算机就业面广、实用性强；另一方面我自己也挺喜欢折腾电脑，总觉得敲几行代码就能驱动底层系统运转特神奇，就顺理成章选了计科。
  • 距离合格的 IT 毕业生还差在哪？
    我觉得最大的差距真不在于“期末考卷上能不能做对几道算法题”，而是完全缺乏正儿八经的大型项目实战经验。合格的工程师懂得怎么设计模块、怎么写出好维护且带测试的健壮代码，还能和团队顺畅协作；而我目前大部分时候还在写两三百行的课后小作业，代码积累、系统视野和工程规范都还差得挺远，这也是这学期最需要恶补的短板。

1. 现状与计划

参考技能评估表，结合我目前的能力以及以后想考研深造的需要，我挑选了 5 项技能进行了自我打分：

Skills 技能维度 课前评估 (0~9) 课后评估 (0~9) 现状分析与提升目标（衡量标准）
Programming: Comprehension
(对现有代码的理解分析)		 3 6 现状：看两三百行的单文件算法题或者课后小作业没问题，但文件一旦多起来、调用层级一深，就容易看懵，摸不清数据到底在各个文件之间是怎么流转的。
目标：能理清大作业各个模块是怎么连起来的，顺畅看懂队友提交的 PR 和开源库的基础逻辑，不再一头雾水。
Programming: Design
(架构设计，模块化设计，接口设计)		 2 5 现状：习惯面向过程顺着往下敲，变量和函数容易全塞在同一个文件里，改一个地方经常莫名其妙崩另一片。
目标：动手敲键盘前先用草稿纸画好分层和接口，尽量把每个功能拆清楚，别再把代码写成一团乱麻。
Programming: Implementation
(模块实现，编写代码)		 3 6 现状：基本语法虽然熟，但写代码全凭直觉，很少考虑边界情况，输入稍微奇怪一点就报错闪退。
目标：自己负责的模块把参数校验和异常兜底做扎实，少写“看着能跑、一测就崩”的代码，变量和函数命名也规范起来。
Programming: Test
(单元测试，代码覆盖率)		 1 5 现状：以前找 Bug 全靠在控制台疯狂 print，手动跑通一组数据就当大功告成，从来没写过正经的单测。
目标：学会使用主流测试框架（如 pytest 或 JUnit），给核心功能配上自动化测试用例，不再全凭人工肉眼碰运气。
Programming: Performance
(效能分析和改进)		 1 4 现状：平时做作业只要结果算对就万事大吉，完全没留心过这段代码吃了多少内存、跑了多久。
目标：学会用性能分析工具（Profiler）找出拖慢速度的代码瓶颈，学期里至少针对性做一次运行速度或内存占用的优化。
Personal Software Process
(个人软件过程: 估算、记录工作量)		 1 4 现状：预估时间全凭感觉，总觉得“两小时肯定搞定”，结果每次都拖到临近 DDL 通宵赶工。
目标：如实记清楚每个阶段到底花了几个小时，看看时间都磨蹭到哪了，把预估时间与实际耗时的偏差缩小到 30% 以内。

针对以上技能的提升计划（具体手段）：

  1. 老老实实走完一次工程全流程：不再为了交作业临时东拼西凑代码，严格从理清需求、定好接口开始，接着写代码、做测试，完整走完一遍真实开发流程。
  2. 逼自己把单元测试补齐：戒掉“代码能跑出结果就算完工”的毛病。这学期自己负责的核心功能必须配上测试用例，省得改一个小地方引发两三个新 Bug。
  3. 按规范走 Git 分支开发：改掉在主分支直接 commit 的坏习惯。按功能建分支开发，commit 信息写清楚改了什么，顺便体验一次正规的代码审查（PR Review）流程。
  4. 每周定期复盘自己的代码：每周日抽出半个多小时 review 自己这周提交的代码，挑出那些命名随意、又臭又长的烂函数改一改，顺手把踩坑经验记在备忘录或博客里。
  5. 记好时间账本，改掉拍脑袋预估：任务动手前先拆细预估工时，做完后对比实际花了多久，反思自己到底在哪些环节低估了难度，把“拍脑袋估工时”的毛病治一治。

2. 阅读心得

a) 读《你倒要我上课讲什么真够奇》的心得：
这篇文章说到我心坎里去了。大一大二很多时候上课，台下听着觉得老师讲得挺清楚、自己连连点头，可一回到宿舍打开编译器，大脑一片空白。文里说“听讲像肌肉训练一样”，被动听讲其实最轻松，但根本留不下真本事。软件工程尤其如此，光看不练就是假把式；课上溜号走神，课后往往要花好几倍的时间去到处找补。

b) 师生关系与面对困难：

  • 师生关系：我希望是健身教练与学员的关系。老师负责制定合理的训练计划、在我们动作变形时指出问题；而核心代码必须我自己敲、汗必须我自己流，不能指望老师把所有答案嚼碎了喂给我。
  • 面对困难的选择：我选 【C：向老师和同学请教，花更多时间，把作业全部做完】。
    我给自己定了个规矩：卡壳时先硬扛 30 分钟，查文档、搜报错、打断点；如果还是卡死，就整理好报错信息和已尝试过的思路去请教助教或同学，绝不把问题拖成死结。

c) 引用与盗窃的界限：
查阅优秀的开源库、参考别人的思路很正常，也是工程师必备的技能；但剽窃则是把别人的成果直接复制过来，抹掉出处假装是自己的原创。两者的分水岭在于：是否诚实注明了来源，是否真正消化并转化成了自己的代码。
在本课程中我保证做到：

  • 凡是借鉴、引用的代码和思路，都在注释或文档里写明出处。
  • 严格遵守使用的开源协议，不乱改乱用。
  • 核心逻辑自己独立完成，绝不当原样搬砖的“代码搬运工”。

3. 未来规划与选择

  • 未来的选择：我打算全力备考研，希望能考上一所好学校的计科或软件专硕，以后深入做一些底层系统或科研方向的工作。
  • 优劣势分析：
    • 优势：性格坐得住，肯下功夫啃厚书和数学推导，抗压心态还行，不容易因为一次考试没考好就陷入自我怀疑。
    • 劣势：目前工程代码量偏少（才 3000 行左右），平时写的全是一两百行的小算法题，没见过真正的大工程，缺少实际的团队协同开发经验。
  • 本学期的具体规划：
    1. 认真跟完软工团队项目，体验一次正规的软件全周期开发，补齐自己“只会做题、不会做工程”的短板，也能为以后的考研复试积累点实在的项目经历。
    2. 稳步积累代码量，本学期在软工项目里踏踏实实写完 3000 行规范代码。
    3. 平衡好专业课与软工大作业的节奏，用实践项目来印证课本里的操作系统、数据结构知识。

4. 本课程计划

  • 对课程的期待：我不希望这门课只是期末背背名词解释，而是希望能真正和队友一起，从零到一搭出一个能跑起来、有测试覆盖的小系统，看看正规的开发协作到底是怎么玩的。
  • 代码量统计：
    1. 目前累计代码量：约 3000 行。
    2. 目标代码量参考：达到扎实标准，至少需要 10000 行以上的有效积累。
    3. 每周投入时间：打算每周挤出 6~8 小时 在软工课的开发和文档上。
    4. 投入态度选择：【C：比以前的课程多一些，尽力达到目标】。
    5. 学期计划：本学期新增 3000 行规范代码，学期末总代码量达到 6000 行左右；每周大概写 200 行左右（重在模块质量和测试，不注水）。
  • WOOP 计划表：
    • Wish (愿望)：期末时能和团队一起把项目平稳上线，代码结构清晰，有像样的测试用例。
    • Outcome (最好结果)：消除对复杂工程的畏惧心理，以后在面对考研复试或科研面试时，能底气十足地讲清楚自己做过的模块和架构。
    • Obstacles (找寻障碍)：大二专业课任务重；考研前期的复习节奏容易和软工任务撞车；遇到棘手的 Bug 容易烦躁拖延。
    • 最可能的失败因素：遇到难啃的工程卡点想往后拖，导致任务堆积到最后几天仓促交差。
    • Plan (if/then 防拖延计划)：
      • If 某个功能或 Bug 调试超过 40 分钟毫无头绪，Then 马上离开座位去洗把脸走动几分钟，回来把问题现象和测试数据整理出来，去向队友或助教请教，绝不闷头死磕耗时间。
      • If 平时因为专业课作业多耽误了软工进度，Then 周末上午固定留出 3 小时整块时间集中补齐，守住每周 6~8 小时的最低投入底线。
  • 你想当助教吗？
    目前暂时不想当。老实说，我深知自己现在的代码量和工程底子都还比较薄，解决实际疑难杂症的经验也有限，去当助教多少有点底气不足。现阶段我更想踏踏实实当好一名学员，跟着课程把完整的工程流程踏踏实实啃下来，先把自己的基本功打扎实。

三、提有质量的问题，给认真的反馈

通读完邹欣老师的《构建之法》，结合我自己想考研的打算和现在的编程水平，有几个地方让我边读边琢磨，提出以下 5 个问题：

Q1: 软件工程追求“足够好”，但在学术研究里往往追求“极致最优”，作为学生该怎么平衡？

  • 出处与背景：第 1 章提到，软件工程的核心是结合时间与资源成本，做出“足够好（Good Enough）”的软件，而不是无休止地追求技术上的完美。
  • 我的困惑：我未来打算考研做研究，学术导向往往是看算法复杂度是不是最低、数学证明是不是最严谨；而工业界做工程，往往更看重代码健壮性、开发效率和好不好维护，甚至愿意牺牲一点效率换取可读性。作为还在读本科、两头都想兼顾的学生，我们在平时的课设里，到底是该优先追求学术级别的“最优算法”，还是按照工程规范“够用即可”？这两者的界限该怎么把握？

Q2: 结对编程中，如果两个人水平差距悬殊，该怎么避免变成“一个人包办”？

  • 出处与背景：第 4 章讲到结对编程，一人敲键盘（驾驶员），一人审查（领航员），并且定期互换。
  • 我的困惑：这个模式在水平差不多的成熟工程师里很好用。但在大二同学里，大家技术底子差得挺多——有的已经写过小项目，有的连基础语法还磕磕绊绊。实际操作里很可能会演变成：基础好的嫌解释起来费劲干脆自己全写了，基础弱的看不懂也跟不上，干坐着摸鱼。在学生团队里，有没有什么行之有效的办法，能既保护基础弱的同学的积极性，又不拖慢整体进度？

Q3: 敏捷开发鼓励拥抱变化，但新手团队怎么防止它退化成“完全不设计的随心所欲”？

  • 出处与背景：第 6 章和第 8 章推崇敏捷开发和快速迭代，尽早发布原型再根据反馈修改。
  • 我的困惑：很多同学做课设很容易打着“敏捷”的幌子不做前期设计，甚至连接口都没定好就上手，想到哪写到哪。结果后期需求稍微一变，之前的代码全成了一团乱麻，改起来比重写还费劲。对于时间紧、经验少的学生队伍，前期到底该投入多大精力去做架构和接口设计，才能既保留敏捷的灵活性，又不至于后期代码崩盘？

Q4: 学生项目技术选型时，该怎么看待“盲目追新”和“用成熟老技术”的矛盾？

  • 出处与背景：第 16 章关于创新的迷思中提到，技术的创新者不一定是市场上的赢家，选技术要权衡成熟度和替换成本。
  • 我的困惑：我们选大作业技术栈时，很容易被社区热点吸引，觉得用最新出的框架、小众的技术才算“跟上时代”，简历也好看。但实际做起来往往发现网上教程少、踩坑没人解答，最后差点交不上差。在有限的学期周期内，我们到底该稳妥地用老而成熟的技术保证完成度，还是应该冒险挑战新技术来提升自己？

Q5: 在没有工资约束的学生团队里，如何客观评价每个人的真实贡献，还不伤同学感情？

  • 出处与背景：第 17 章探讨了团队里对人员贡献和绩效的评估。
  • 我的困惑：在公司里有绩效和升职加薪管着，但在学校都是同班同学。如果单纯按 GitHub 代码行数算，很容易变成有人故意多写废话代码或者拆 Commit 刷量；如果是互评打分，大家又往往碍于面子全打满分，搞得干活多的同学心理不平衡。在纯自治的学生小组里，有什么客观、靠数据说话的办法来公正评估每个人的贡献？
  • 对教学反馈的态度选择：
    我选择 【C：有问题就问，至少一学期提三个问题，认真按时填写反馈】。
    理由：遇到听不懂或有争议的地方及时向老师、助教反馈，对自己负责，也能让课堂越来越好。应付打分没有任何意义，真诚沟通才会有实质收获。

四、前车之鉴

1. https://book.douban.com/subject/4006425/discussion/22803961/

读完刘帅学长从清华考研一路拼到亚马逊的经历，最戳中我的是他对“机械记忆”与“真正思考”的反思。

他在本科时为了拿奖学金，把大量时间花在背题型、应付考试上，虽然成绩单很漂亮，但一碰到没见过的复杂问题立刻不知所措。直到后来在清华听课，他才发现优秀的工程师和学者从来不会去死记套路，而是反复琢磨“这个算法为什么这么设计、前人踩过什么坑”。

这一点真是给我敲了个警钟。我平时备战专业课，有时也会偷懒去死背模板题，只要跑出答案就觉得学会了。但正如学长所说，死记硬背能在短时间内应付期末考试，可代价是丧失了举一反三和解决复杂系统问题的能力。学长工作三年后辞职考研、强迫自己逼问底层原理的经历提醒我：考研备考绝不能搞成应试刷题，必须把每一道题背后的计算机底层机制想透，学会独立思考才是长远的立身之本。

2. https://book.douban.com/subject/4006425/discussion/22803733/

辜新星学长的长文非常接地气。看到他说自己刚进北大时高数期中考不到 80 分、感到极度迷茫时，我特别有共鸣——面对周围优秀的同学，谁都有过落差和焦虑。

学长给出的破局方法对我启发最大的是 ABCD 四象限时间管理法。平时在大学里，我们经常被各种临时的杂事、随堂小测试牵着鼻子走（紧急的事）；而真正决定我们几年后核心竞争力的——比如深入读懂一本底层经典、老老实实写一个规范的工程项目、踏实复习核心专业课（B 类：重要但不紧急）——却总是被习惯性往后推。

另外，学长提到想要技术过硬，必须“多写长篇的大代码，从底层自底向上把经典著作啃透”。这也坚定了我本学期对待软工课的态度：不能把大作业当成水学分的负担，而要把它当成自己第一次写“长篇大代码”的实战演练，按照重要不紧急的标准认真对待，把工程基础打牢。

五、要求

1. 博客后台编辑页面截图

image

2. GitHub 地址与主页截图

posted @ 2026-09-05 23:29  QvQ1112  阅读(7)  评论(0)    收藏  举报