软件工程第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	第一周作业
这个作业的目标	完成个人博客开篇随笔，认识自我、梳理专业现状与学习计划，阅读《构建之法》提出思考问题，借鉴前人学习经验，掌握博客、Markdown、GitHub 基础使用

一、自我介绍
大家好，我是一名广东工业大学计算机专业的本科生。
我的闪光点：具备不错的逻辑思维能力，遇到 bug 愿意耐心排查调试；平时喜欢自主查阅技术文档，遇到不懂的技术点会主动搜索整理笔记；同时有较好的自学能力，能够通过网课、文档快速上手新工具。
写博客对于来说是一次锻炼书面语和审视自身的机会。在整理文字的过程里，我可以复盘自己过往的经历，看清自己的长处与不足。接下来我会通过博客园这个平台来不断精进自身能力。

二、现状、经验和计划

1. 我选择 IT 专业，一方面源于我本身对计算机技术的兴趣，信息技术渗透各行各业，拥有很强的创造力，可以通过代码、程序解决现实里的各类实际问题；另一方面看到数字化时代发展大势，IT 专业拥有广阔的发展空间。同时我也明白 IT 行业更新迭代速度快，需要持续学习，大学正是夯实基础的黄金时期，因此我选择本专业，希望系统掌握计算机相关知识，成长为一名合格的 IT 从业者。
   对照课程给出的技能调查表，我选取了5项核心技能，评估当前水平，并明确对应提升手段：

技能名称	①当前水平	②课程结束目标水平	③提升手段
程序理解（阅读、分析、调试已有代码）	3	6	1. 阅读开源项目源码，梳理代码逻辑；2. 多做 debug 练习，分析报错根源；3. 阅读别人项目，写代码阅读笔记
架构与模块化设计	2	5	1. 学习设计模式基础理论；2. 写小项目时主动做模块拆分、接口设计；3. 参考成熟项目的架构案例模仿练习
单元测试、代码覆盖率	2	5	1. 学习单元测试框架用法；2. 写业务代码同步编写单元测试；3. 练习使用工具查看代码覆盖率，补齐测试用例
代码复审与代码质量	3	6	1. 学习代码编写规范；2. 写完代码自我复盘审查；3. 参与同学之间代码互查，学习优秀代码写法
项目管理（任务规划、优先级）	3	6	1. 做项目前做任务拆解、时间预估；2. 练习给任务划分优先级；3. 使用项目管理工具管理个人开发任务
团队协作（协同开发、沟通说服）	3	6	1. 参与小组课程项目，练习分工配合；2. 学习 Git 团队协作流程；3. 主动表达方案，倾听接纳同伴意见

（2）心得：

a) 为何要来上课并且认真参与
我来上课，不只是为了拿到学分、顺利完成学业拿到毕业证，更重要的是主动学习专业知识、锻炼自己的思考能力。博客里提到认真听讲是一种能力，大学课堂不是简单接收知识点，而是跟着老师梳理思路，纠正自己 “原生态” 的碎片化思考模式，搭建专业知识体系。课堂也是锻炼专注力的地方，不能因为觉得老师讲得一般、课程看似没用就放弃听课，眼界和格局会限制我们对课程价值的判断。

b) 师生关系与作业态度
现实大学的师生关系大多是松散的：老师讲课，课后交流机会不多，很多时候学习全靠自己主动。我希望这门课是平等双向沟通的师生关系：老师可以布置合理任务，学生敢于提出疑问、说出自己学习的难处；老师愿意答疑指导，学生也要主动投入学习，不是被动等着灌输知识。
如果作业对我来说比较困难，我会选C：先自己反复思考，查阅资料，遇到卡点主动找老师、同学请教，多分配时间，尽力完整完成作业。不会直接摆烂放弃，也不会直接告状，更不会只做刚好及格的最低限度。遇到实在无法攻克的部分，也会主动向老师说明自己的卡点，寻求指导，而不是直接抄袭糊弄作业。

c) 参考借鉴与抄袭的区别
1.引用 / 合理参考借鉴：学习、工作里参考别人文献、资料、代码，站在别人成果之上继续开发，是正常的学习科研行为。明确标注来源，说明哪部分来自他人成果，尊重原作者，只借鉴思路或者公开资源，自己完成核心的思考与创造。写文档标明文献出处；使用别人代码时遵守开源协议，注明引用仓库、原作者。
2.抄袭、剽窃：直接照搬别人文字、文档、代码，不标注来源，把别人的劳动成果直接冒充成自己完成的内容。大段复制文字、原样拷贝代码，不做说明，当作自己作业上交，不管原内容是否公开，都属于抄袭剽窃。

(3) 未来方向、优劣势与本学期规划
几年后我选择从事Java 后端开发方向，走软件开发的职业路线。后端开发负责服务器、接口、数据库、业务逻辑开发，是互联网项目里很核心的岗位。
1.自身优势
对编程逻辑比较感兴趣，愿意花时间敲代码，能沉下心调试 bug；
了解基础 Java 语法，有简单的代码编写基础，愿意主动查阅技术文档；
做事耐心，后端开发需要严谨处理数据，我对待任务比较细心。
2、自身劣势
项目实战经验少，还没有完整做过大型后端项目；
框架掌握薄弱，Spring、MyBatis 等主流框架还不熟练；
计算机底层基础薄弱，数据库、计算机网络知识掌握不够扎实。
3、本学期规划（为 Java 后端做准备）
夯实 Java 基础：吃透 Java 核心语法、集合、多线程、面向对象，多写练习题，整理错题笔记；
学习主流框架：入门 SpringBoot，跟着教程动手做小型实战项目，比如简单的图书管理系统；
补齐底层知识：学习 MySQL 数据库，练习建表、SQL 增删改查，学习计算机网络基础；
积累项目经验：把写好的代码上传到 Gitee，积累自己的代码作品集；
练习解决问题能力：遇到报错先自主查资料调试，提升排错能力；
定期复盘：每周总结学到的技术点，查漏补缺。

(4) 这门课的计划
课程期待：参考国内外软件工程专业培养，不只是学习语法，要掌握工程化思维，学会写规范、可维护的代码，掌握项目开发流程，学会调试、协作开发。希望课程既有理论，又有大量动手实践。
打算怎样度过课程：课前简单预习，课上紧跟思路；课后不局限完成作业要求，主动拓展练习；遇到问题先独立调试，再请教同学老师；定期复盘代码。
助教意愿：暂时不申请助教，优先把自身基础打扎实；后续能力提升后愿意尝试。
代码量情况
目前代码量：Python 约 1200 行，C 语言约 800 行，合计约 2000 行。
入职一流互联网 / AI 公司：一般需要累计1 万行以上有效项目代码（不含复制粘贴，是自己编写调试的业务、项目代码）。
高校教学科研：除代码能力外，更看重论文科研成果；代码上需要熟练完成实验、算法原型，代码量 5000 行以上，重点是科研思维。
每周投入时间
每周投入6 小时（包含上课）。
选择：D：比以前课要多很多，直到达到目标为止。
课程结束目标代码量：累计新增 2000 行有效代码。
每周完成代码量：每周完成 200 行新增有效代码。
WOOP 计划

• W (Wish) 愿望
  • 这门课程结束后，熟练掌握软件开发工程方法，完成课程作业 + 2 个小型实践项目，代码量达标，能够独立完成中小型程序开发，课程取得良好成绩。
• O (Outcome) 最好结果
  • 能够独立设计、实现小软件项目，看懂别人的工程代码，写出来的代码规范清晰，调试 bug 效率大幅提升；简历上可以写上自己的项目，为后续实习求职打下扎实基础，收获实实在在工程能力，不再只会写简单练习题。
• O (Obstacles) 障碍
  • 内部障碍：容易拖延，写代码遇到难 bug 就烦躁，忍不住刷手机分心；惰性，总想 “明天再写”；遇到复杂知识点畏难。
  • 外部障碍：其他课程任务挤占时间；网上碎片化信息干扰，查资料容易跑偏浪费时间。
  • 最可能失败因素：拖延，遇到难题就搁置任务，总把编程作业往后堆，最后赶工敷衍完成，代码质量差，达不到练习效果。
  • 克服思路：不把任务堆到截止日前一晚，拆分任务，每天完成一小部分，不等到最后突击。
    P (Plan) if‑then 风险预案
  • 如果写代码时忍不住刷手机分心，那么立刻把手机放到另一个房间，设置 25 分钟专注计时器，只专注写代码，计时器结束再休息。
  • 如果遇到 bug 调试很久没有头绪，心态烦躁想放弃，那么先暂停 10 分钟，喝水走动，整理问题思路，把报错信息记录下来，再重新排查；实在不行就整理问题向同学老师求助，不直接搁置任务。
  • 如果别的课程作业很多，挤压这门课时间，那么我每天保证至少 1 小时敲代码，优先保证最小进度，不直接完全停掉编程练习。
  • 如果发现自己想要把作业拖到截止日前才做，那么我就给自己设置提前 2 天的自我截止时间，到点必须完成基础版本，不允许往后拖延。

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

问题一：单元测试是否必须由代码作者本人完成？

• 对应章节：第 2 章 2.1.2 单元测试

• 书中原文：单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更合适的人。

我有这个问题：在多人协作的大型项目中，如果开发者业务繁忙、工期紧张，把单元测试交给专门测试人员编写，是否完全不可取？
我查阅资料看到，一部分企业会安排独立测试工程师补充单元测试；也有行业观点认为，作者写单元测试优势是理解业务逻辑，但缺点是容易陷入思维盲区，和写代码犯同样逻辑错误。

结合我的课程小组项目实践：我们小组曾经让写业务功能的同学写单元测试，出现过 “只测正常输入，忽略边界异常” 的问题；后来交给另一位同学补充测试，发现了 3 处隐藏 bug。

我的困惑：书中强调单元测试必须作者写，但是现实项目里存在分工测试的做法。那什么场景下可以交给他人写单元测试？他人编写单元测试，如何避免不理解代码内部逻辑的缺陷？

问题二：结对编程一定能提升开发效率吗？

• 对应章节：第 4 章 4.5.2 结对编程
• 书中原文：结对编程的好处：减少错误、知识分享、互相督促，驱动者负责写代码，导航者负责思考审视，整体产出质量高于单人开发。
  我有这个问题：结对编程有没有明显不适用的场景？两个人能力差距很大的时候，结对编程会不会反而降低效率？

查阅资料：很多互联网团队并不会全程结对编程，只在核心模块、复杂 bug 调试场景短期结对。
我的实践经验：小组作业尝试结对编程，当两个人水平差距大时，能力强的同学全程主导，另一位同学跟不上节奏，出现摸鱼现象，整体开发速度反而不如分开写再做代码复审。长时间结对也会造成两个人精神疲惫。

我的困惑：书中更多阐述结对编程的优点，但是对它的代价、适用边界讲得较少。结对编程适合什么样任务、什么样团队？能力差距明显的组员之间，如何开展有效的结对编程？

问题三：敏捷开发欢迎需求变更，如何防止需求无休止改动？

• 对应章节：第 6 章 6.1 敏捷流程简介
• 书中原文：敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。尽早、持续交付有价值软件。
  我有这个问题：如果一味接纳用户的需求变更，会不会造成项目范围不断膨胀，迭代永远完不成？

查阅资料：敏捷开发有 “产品待办列表、迭代边界” 机制，每个迭代周期内不随意修改本迭代计划；但是很多小团队实践敏捷时，没有严格执行这套约束。

我的小组项目经验：做课程项目模拟敏捷迭代，用户不断提出新想法，迭代中途频繁改需求，我们不断修改代码，原定功能迟迟无法完成。

我的困惑：敏捷鼓励拥抱变化，但是现实中用户需求经常随意变动。那该如何平衡 “接纳需求变化” 和 “控制项目范围”，哪些需求变化该拒绝，哪些需求应该接纳？

问题四：创新一定需要大量技术突破吗？

• 对应章节：第 16 章 16.1 创新的迷思
• 书中原文：迷思一：创新就是要搞出惊天动地、前所未有的发明创造；很多成功创新来自现有技术重新组合、改进用户体验。
  我有这个问题：如果没有底层技术创新，只做体验、模式上的改良创新，产品护城河会不会很弱，很容易被对手复制模仿？

查阅案例：很多应用产品只是整合现有技术，做出更好交互，很快被竞品复刻；但也有产品依靠运营、生态优势站稳市场。

我的思考：书中说创新不等于全新技术发明，组合创新也很重要。但我的疑问：单纯组合、体验改良类型的创新，如何建立壁垒，避免被竞争对手快速抄走？什么样的组合创新才是真正难以复制的？

问题五：“萝卜快了不洗泥” 的工程师，该如何客观评价？

• 对应章节：第 17 章 17.2 绩效评估
• 书中原文：萝卜型工程师开发速度快，但是代码质量粗糙，留下技术债务；白菜工程师慢但是代码质量高。团队不能一味偏爱萝卜，也不能全盘否定萝卜。
  我有这个问题：在紧急上线的项目节点，萝卜型工程师快速交付，帮项目渡过危机，但留下大量技术债务。绩效评估的时候，该如何权衡短期产出和长期技术债务？

查阅资料：行业里技术债务会带来后续维护成本，但是紧急业务场景下快速上线也有巨大商业价值。

我的困惑：书中讲了两类工程师的特点，但没有给出可落地评判标准。绩效打分时，如何量化 “快速交付的价值” 和 “技术债务带来的隐患”？团队应当如何引导萝卜型工程师，平衡速度和代码质量？

认真反馈题：老师为改进教学收集课程反馈，你会怎么做？
答案：D：经常提问题，平时就经常给老师和助教提反馈
理由：如同软件工程中持续反馈迭代的思想，课程学习也是一个迭代过程。有疑问、建议及时反馈，既可以解决自己的困惑，也可以帮助老师优化教学内容，而不是等到催促才被动填写反馈。

四、前车之鉴
阅读了前辈们的经验分享，我收获很多，挑选三篇分享我的感想：

1.阅读文章 A：https://book.douban.com/subject/4006425/discussion/22803733/

辜新星：时刻调整方向 找到人生的蓝海

文章介绍了 ABCD 四象限时间管理法：A 紧迫且重要、B 重要不紧迫、C 紧迫不重要、D 不重要不紧迫。读完我深有感触，我过去常常优先处理 A 类紧急任务，却忽略了 B 类重要但不紧急的事，比如系统学习计算机底层知识、做项目练习。B 类事情关乎长期能力提升，却因为没有截止日期总被拖延，等到考试、找实习的时候才发现基础薄弱。我打算尝试这套方法，把打基础、写代码练习这类长期学习任务放到 B 象限，每天留出固定时间完成，而不是总被临时紧急事情牵着走，避免 “忙忙碌碌却没有成长” 的困境。

2.阅读文章 B：https://book.douban.com/subject/4006425/discussion/22803961/

刘帅：在失望中寻找希望

这篇讨论的主题是 “明明是计算机科班，却感觉自己没有学懂计算机”。这和我现在的处境高度契合：课堂上听课能听懂，考试也可以拿到不错分数，但真正动手写项目、解决实际问题的时候就手足无措。大学课堂偏向理论知识，课本教会我们原理，但是工程实践能力需要靠自己课外主动练习。不能因为自己是科班学生就抱有优越感，课堂只是打下地基，真正的掌握要靠自己多敲代码、做小项目、主动实践。如果只满足于完成课堂作业，毕业之后依旧会暴露能力短板，我要警惕这种 “假学会” 的状态，多动手实操，打通理论和实践之间的鸿沟。

3.阅读文章 C：https://book.douban.com/subject/4006425/discussion/22802960/

徐宥：掉进读书的兔子洞

文章提倡把自己胡思乱想的想法记录下来，做成思维快照，时常回看自省，对比过去和现在的自己。在学习计算机的过程中，我经常陷入内耗，经常纠结 “我是不是不适合学编程”“这个知识点总学不会怎么办”，很多想法盘旋在脑子里，越想越焦虑。把想法写下来之后，可以分清哪些是客观困难，哪些只是自己的情绪内耗。定期翻看笔记，能够看到自己思维的变化，看到曾经困惑自己的问题已经被解决，能给自己带来正向反馈。记录想法也是复盘的一种方式，帮助我看清自己学习路上的问题，调整学习节奏，减少精神内耗，更专注于实实在在的学习本身。

总结：三篇文章分别从时间规划、科班学习误区、自我复盘三个角度给我启发。前人踩过的这些坑提醒我，计算机学习不只靠课堂听课，更需要做好时间管理、主动动手实践、时常复盘自省，避开 “看起来努力，实际收获很小” 的陷阱。