第一周

这个作业属于哪个课程 https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS
这个作业要求在哪里 https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692
这个作业的目标 熟悉博客园、GitHub 两个平台的基本使用;掌握 Markdown 写作技术随笔;系统复盘自己的学习现状并制定本课程学习计划;带着问题阅读《构建之法》并输出独立思考;阅读前辈经验教训,避开成长弯路,养成以输出倒逼输入的学习习惯。

一、介绍自己,建博客

我是计算机科学与技术专业大三的学生,平时主要学习Java后端方向的内容。
写博客确实很花时间,排版、组织语言、贴代码都要反复打磨。但我自己的体会是:很多内容只是看时觉得自己懂了,真正动手写出来才发现理解得不到位,很多细节经不起推敲。写博客相当于逼着自己把"隐性理解"变成"显性表达",这个过程中漏掉的知识点会被自动找出来。长期坚持还能留下完整的学习轨迹,将来复盘、求职时都是现成的素材。我也理解有些同学觉得"写博客浪费时间、不如多敲代码"——如果只是把书抄一遍,确实意义不大;但如果是自己的思考与踩坑记录,写,本身就是一种高效的复习。
说说我的一点小优势:乐于扩展,在将时间放在解决一些难题的同时,也能学习到更多的知识。
对待课程作业我给自己定了一条底线:作业不是为了应付老师,而是锻炼工程实践能力的手段。我会独立完成、不抄袭、不敷衍,认真对待每一部分,参考他人资料时一定注明来源。

二、现状、经验和计划

(1)专业选择、现状与技能提升计划

为什么选择这个专业: 顺应信息化的时代潮流,热心于代码设计,以解决实际问题。
与合格 IT 毕业生的差距: 我目前的短板主要有:完整的项目实战经历很少;需求分析、单元测试、项目迭代等软件工程能力薄弱;Git 团队协作与风格协同比较灾难;距离"能直接上手企业级开发"还有明显差距。
技能自评与提升计划(评分标准:0–9 分,5 分代表能通过企业面试,9 分代表世界一流水平;我从技能调查表中选取了 7 项对我最重要的技能):

技能项 当前水平 课程结束目标 提升手段
Java代码实现能力 4 6 1. 完成课程全部编程作业;2. 独立写一个小型练手项目;3. 阅读开源项目源码并做笔记;4. 把学习内容整理成博客输出;5. 与同学结对互相 Code Review;6. 问题优先查官方文档。
程序调试与排错能力 3 6 1. 做项目时认真阅读报错日志;2. 把踩过的 Bug 分类记录成博客;3. 熟练使用调试器断点排查;4. 主动帮同学排查问题;5. 每次排错后复盘排查思路;6. 学习阅读开源项目的 Bug 修复记录。
Git / GitHub 版本控制 2 7 1. 课程作业全部用 Git 管理;2. 练习分支、合并、解决冲突;3. 给自己的项目写 README 并托管到 GitHub;4. 阅读 Git 官方文档;5. 尝试给开源项目提 issue;6. 和同学模拟团队协作提交。
需求分析能力 2 5 1. 小组作业主动参与需求梳理;2. 学习写简单的需求文档;3. 分析真实项目的需求案例;4. 练习把模糊需求拆成可实现的小功能;5. 看开源项目的 issue 理解用户诉求;6. 小组内互相评审需求。
单元测试能力 2 5 1. 学习 JUnit 等单元测试框架;2. 给自己写的代码补单元测试;3. 阅读开源项目的测试代码;4. 学习设计有效测试用例;5. 课程作业主动加入测试环节;6. 把测试踩坑点写进博客。
技术文档撰写能力 3 6 1. 给每个项目写清晰 README;2. 坚持每周写技术博客;3. 参考优秀开源项目文档结构;4. 小组作业练习写接口文档;5. 请同学帮忙审阅文档;6. 学习 Markdown 与中文排版规范。
团队协作与项目管理 2 6 1. 积极参加课程小组项目;2. 学习任务拆分与分工;3. 练习代码评审流程;4. 熟练使用团队协作工具;5. 主动与组员沟通对齐进度;6. 项目结束后复盘协作得失。

(2)阅读心得

a) 为什么要来上课并认真参与。 读完那篇学生的思考及评论区后,我最大的感触是:大学是人生中少有的、精力最旺盛且能全职投入学习的整块时间,等进入职场,很难再有这样的环境。软件工程这门课不是靠背概念能学好的,它高度依赖动手实践,而实践恰恰是我最薄弱的部分。课程要求写博客、做小组项目、读经典书,正好覆盖我的短板,所以我不打算用"混"的态度对待它。
b) 师生关系与困难作业的处理。 我上大学以来主要经历的是"老师单向讲授、学生被动接收"的模式,课下交流很少。我理想中的师生关系是"教练与学员"式的双向互动:老师给出框架和方向,指出问题;学生主动思考、提问和实践,双方共同推进。如果这门课的作业对我而言有困难,我的选择是:向老师和同学请教,花更多时间,把作业全部完成。** 作业难恰恰说明它的训练价值高。我会把大任务拆成小模块,逐个攻破;自己先尽力查资料,再带着具体问题请教老师和同学,绝不直接放弃或敷衍。有难度才能暴露知识盲区,这本身就是学习的一部分。
c) 参考引用与抄袭、剽窃的区别。 三者的界限在于"是否尊重原创并加入自己的劳动":

  • 合理引用:参考别人的代码、博客、思路时,明确标注来源,并在其基础上加入自己的理解、设计与二次开发。这是学习和行业里完全正常的行为;
  • 抄袭:直接复制他人的文字或代码而不标注来源,没有自己的思考与改造;
  • 剽窃:性质更严重,直接把别人的成果冒充成自己的,用于交作业、评奖等获取利益。
    我查阅了学校的相关规定:抄袭作业会判零分甚至记过处分。在本课程中我会遵守原创原则:作业独立完成,参考网上资料或代码时明确标注来源,绝不把别人的成果当作自己的提交。

(3)未来发展选择、优劣势与学期规划

我未来的主攻方向是互联网后端开发。结合前人的经历,技术这条路没有捷径,本科阶段打牢基础、积累代码量和项目经验,是后面走得稳的前提。
我的优势: ①有一定编程基础,方向明确;②能沉下心做长期积累,有复盘习惯;③遇到问题愿意先自己查资料解决。
我的劣势: ①项目实战经验少,工程化知识储备不足;②对大型软件架构理解很浅;③团队协作经验欠缺。
本学期规划: ①保质保量完成课程全部作业,坚持博客输出;②动手完成一个小型练手项目;③ 在Git/GitHub学习风格适应;④积极参与小组项目,练习需求拆解与协作;⑤每周复盘薄弱点并及时补齐。

(4)课程计划、代码量与 WOOP 规划

我对这门课的期待是:不只记住概念,而是真正理解企业软件开发的完整流程,掌握版本控制、测试、写文档这些工程能力,建立"从需求到交付"的整体思维。课上我会认真思考、主动提问,课后保证足够的实践时间;这学期暂时不打算当助教,先把自己的基础打牢。
当前代码量: Java 约 2800 行、C 约 1200 行、Python 约 500 行,合计约 4500 行)。
行业参考: 想进入一流的软件/互联网/AI 公司,学生阶段积累上万行有效实践代码并具备完整项目经历会比较有竞争力;高校教学科研方向则不硬性看重行数,更看重代码质量、底层原理功底与实验复现能力。
时间投入: 我计划每周投入约 12 小时在这门课上(含上课时间)。过去两年我确实有浪费时间的经历,现在想认真补齐短板,所以对应选择 D:比以前课要多很多,直到达到目标为止。 本学期计划新增有效代码量约 5000 行,折算下来每周需要新增约 400 行。
WOOP 规划:(学习他人的优秀规划)

  • Wish(愿望): 课程结束时,我能掌握软件工程的基本流程,熟练用 Git 做团队协作,完成课程小组项目,并沉淀一批自己的技术博客,有效代码量达到约 9500 行。
  • Outcome(结果): 我能独立完成一个小型后端项目的开发与部署,看得懂简单的开源项目,具备参与团队开发的基本能力;博客可以当作学习作品集,为之后找实习做准备,彻底跳出"只会写 Demo"的阶段。
  • Obstacles(障碍): 内部障碍主要是拖延、调试久了心态烦躁、容易刷手机分心;外部障碍是其他课程会挤占时间、部分工程概念自学门槛高。最可能导致我失败的因素是拖延——任务一直堆到截止日前才匆忙赶工,质量大打折扣。克服思路:把大任务拆成每天能完成的小份,提前排期。
  • Plan(if-then 预案):
    1. 如果写代码时忍不住想刷手机,那么把手机放到另一个房间;
    2. 如果调试很久找不到头绪、心态烦躁,那么先停下,记录已排查的线索,再找同学或助教讨论,不硬耗;
    3. 如果发现任务开始堆积,那么立刻拆出子任务清单,每天完成一小部分,绝不拖到截止日;
    4. 如果本周时间被其他课挤占,那么周末留出整块时间补课程任务,保证每周代码量目标;
    5. 如果学完容易遗忘,那么每周日固定花 1 小时复盘本周知识点与踩坑记录。

三、读《构建之法》:五个问题与课程反馈

带着问题读书是效率很高的学习方式。快速通读全书后,我整理了 5 个问题:
问题 1:第 1 章《概论》——软件工程“足够好”的标准界定
引用原文:【软件工程师的目标不是创造完美的软件,而是在现有约束条件下,做出“足够好”的软件,平衡质量、成本、时间与用户需求。】
我的问题:书中强调软件工程追求“足够好”而非完美,但这个标准十分模糊,在时间、成本、需求多重约束冲突时,该如何精准界定“足够好”的边界,优先取舍核心目标?
参考依据与经验:以往编写课程代码时,我总追求代码极致优雅、功能全面完善,耗费大量时间打磨细节,却经常导致项目交付延期,忽略了软件核心功能的落地优先级。
我的困惑:书中仅提出“足够好”的工程理念,却没有给出具体的判断标准,学生开发项目、企业商用项目的“足够好”判定条件是否一致,该如何落地应用?

问题 2:第 2 章《个人技术和流程》——PSP 个人流程的新手适配价值
引用原文:【PSP 个人软件过程可以帮助开发者量化个人开发效率,精准预估工时,发现自身开发短板,持续优化个人编程能力。】
我的问题:PSP 核心是精准预估工时、记录开发数据,但新手开发者编码、调试经验不足,工时预估偏差极大,坚持记录繁琐的流程数据,是否反而会增加开发负担、降低效率?
参考依据与经验:我日常写代码时常低估调试和排错时间,仅凭主观判断规划开发时长,导致频繁出现工期延误、任务堆积的问题,无法精准把控开发节奏。
我的困惑:PSP 更适配成熟开发者,对于小规模课程作业和新手练习,是否需要完整执行全套流程,有没有简化适配的落地方式?

问题 3:第 4 章《两人合作》——结对编程的适用边界
引用原文:【结对编程由两名开发者共同完成编码工作,一人编写代码,一人即时审查,能够有效减少代码缺陷,统一开发思路,实现互相学习提升。】
我的问题:书中推崇结对编程的协作优势,但现实中开发者技术水平、沟通节奏差距较大,容易出现强者带教、弱者旁观的情况,反而降低开发效率,什么样的任务和搭档才适合结对编程?
参考依据与经验:小组作业协作开发时,我发现两人技术差距、性格差异会严重影响协作效率,简单功能开发中,单人独立编写、后续互相复审的模式,比结对编程效率更高。
我的困惑:书中重点阐述了结对编程的优势和执行方法,对其适用场景、禁忌场景着墨较少,学生团队该如何快速判断当前任务是否需要结对编程?

问题 4:第 5 章《团队和流程》——软件团队模式的选型逻辑
引用原文:【不同的软件团队模式适配不同的项目场景,没有绝对最优的团队模式,团队组织形式需要匹配项目开发需求。】
我的问题:书中介绍了明星团队、主治医师团队、社区团队等多种模式,各类模式各有优劣,是否存在通用的团队选型标准,能否适配绝大多数软件开发项目?
参考依据与经验:我曾认为全员技术大牛的明星团队是最优配置,但实际小组开发中发现,核心人员过度包揽工作,会导致团队其他人参与度低,项目容错率极低,核心人员缺位就会停滞。
我的困惑:学生课程项目需求简单、人员固定,无需复杂团队架构,各类专业团队模式在小型学生项目中,是否具备实际参考和应用价值?

问题 5:第 6 章《敏捷流程》——敏捷迭代的范围管控平衡
引用原文:【敏捷开发摒弃僵化的固定规划,拥抱需求变化,通过短周期迭代、持续交付,快速响应用户需求调整产品功能。】
我的问题:敏捷核心是拥抱变化、灵活迭代,但无节制接纳新增需求,容易导致项目范围失控、迭代任务泛滥,该如何平衡敏捷的灵活性和项目的可控性?
参考依据与经验:团队迭代开发中,我们曾盲目套用敏捷模式,开发中途频繁新增用户需求、修改功能逻辑,导致迭代任务混乱,项目反复返工,无法按时交付。
我的困惑:书中强调敏捷适配多变的市场需求,但没有明确需求变更的边界,学生项目迭代中,哪些需求变更可以接纳,哪些必须拒绝?

四、前车之鉴:三篇前人文章感想

文章 1:https://book.douban.com/subject/4006425/discussion/22803733/
内容:把任务分为 ABCD 四类 ——A 紧迫且重要;B 重要不紧迫;C 紧迫不重要;D 不重要不紧迫。
感想:过去处理事务时,我总优先应付各种突如其来的紧急事情,常常挤压掉那些对长期成长关键、却没有截止压力的事,例如算法练习、研读技术资料、复盘学习笔记。这类 B 类任务短期看不出影响,可长久搁置就会造成能力上的短板。读完这部分内容,我计划每日梳理待办事项,对任务划分优先级,主动为重要但不紧急的学习任务预留固定时段,避免被零碎的紧急事务消耗掉全部时间精力。
文章 2:https://book.douban.com/subject/4006425/discussion/22803961/
内容:科班学生却感觉自己没有真正学懂计算机。
感想:这点和我自身的学习体验高度契合。课堂上听讲解觉得思路都明白,可落到实际编码就问题百出。计算机学科不能只依赖听课记忆,实操才是掌握知识的关键。不能停留在 “看得懂” 的层面,要逼迫自己独立实现代码,调试报错、排查问题。后续学习中,我会减少单纯看书听课的比重,多动手实操,把理论知识通过实践真正内化。
文章 3:https://book.douban.com/subject/4006425/discussion/22802960/
内容:记录思维快照,时常回头自省。
感想:我十分认可记录思考过程的做法。学习过程中冒出的疑问、思考思路,如果不做留存,过段时间就彻底淡忘。我准备在整理学习笔记、输出博客的时候,不光记录最终结论,同步写下思考卡点、试错过程与当时的理解,定期回头翻阅复盘,直观看到自己思维模式的改变,看清自身的进步与依旧存在的不足。

附录:GitHub相关说明

地址:https://github.com/CageHuang1220/CageHuang1220/blob/main/README.md
截图:
66a8ddf1e271a70cfbfea55d0bc4f941

posted @ 2026-09-09 23:04  cagehuang  阅读(17)  评论(0)    收藏  举报