软件工程第一周作业

第一周作业

一、准备工作

这个作业属于哪个课程	软件工程
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标	练习如何写博客、谈谈现状与未来规划、学习与使用GitHub

二、正文

1、自我介绍

大家好，我是来自广东工业大学计算机学院的一名本科生，本学期我开启博客园随笔记录之旅，核心目的是系统学习博客撰写、格式规范等基础技能。我深知撰写一篇优质博客需要花费大量时间，但长期坚持能极大提升我的知识总结能力和专业表达能力，让零散的知识点形成完整的知识体系，因此我愿意长期坚持，静待成长蜕变。

我的爱好是打游戏、看小说、跑步、游泳、唱歌等等。尤其是唱歌，哪怕知道自己唱的很难听，但我还是会在人少的地方嚎两嗓子，或者在路上低声歌唱。

我觉得我的优势是愿意花时间去自学、去思考，也善于复盘总结。我相信不管是现在还是未来，自学能力都是非常重要的。

2、现状、经验和计划

（1）为什么选择这个专业？

本身对计算机不排斥，现在又是互联网时代，所以就选了这门专业。

技能调查表

技能	当前水平	目标水平	提升计划
对编程整体理解	3	6	多去接触完整的项目
团队协作	2	6	积极参与小组作业、沟通磨合协作方式
软件工程流程认知	3	6	精读《构建之法》、梳理软件开发全流程、参考优质博客案例、总结流程实操要点
代码复审/代码规范/代码质量	2	5	独立解决程序报错、记录报错原因与解决方案、借鉴优秀代码调试思路
自主学习能力	4	7	每日预留自学时间、定期复盘学习漏洞、制定阶段性学习目标、坚持长期输出总结

（2）阅读心得

a）为何来上课并认真参与

大学课堂不只是听讲记笔记，老师会搭建完整知识框架，点明易错点；在课堂上、同学提问可以带来多元思考，弥补自学的盲区。认真上课参与，是充分利用大学资源，为自身专业能力打基础，并不是单纯为了获得分数。

b）师生关系

在大学学习中，我体验的是被动式师生关系：老师单向授课、学生被动听讲，师生互动较少，学生遇到问题很少主动请教。

我希望本门课程建立教练式、互助式师生关系，正如课程提到的健身教练模式：老师是专业的指导者，为我们梳理知识、纠正误区、解决难题；学生是主动学习者、提问者，主动思考、积极提问、认真落实任务。

面对老师布置的困难作业，我的选择是C选项：向老师和同学请教，花时间去思考并解决问题。

c）参考借鉴与抄袭剽窃的区别

参考借鉴是在尊重原创、标注来源的前提下，学习他人的思路、方法、成果，结合自身思考进行优化、创新和延伸，是站在巨人的肩膀上提升自我，属于合法合规、积极正向的学习行为。

抄袭剽窃是直接照搬他人文字、代码、成果，不标注来源、不进行思考修改，冒充自己的原创成果，是侵占他人知识产权的学术不端行为。

允许合理参考资料，但必须融入个人思考、原创输出，严格标注参考来源。

（3）未来发展选择

先考研升学。毕业后优先选择互联网企业从事后端开发、程序研发相关工作，长期深耕技术领域。

• 个人优势：

  • 1、学习态度端正，自律性强，愿意为专业学习投入大量时间
  • 2、文字总结能力较好，擅长复盘梳理

• 个人劣势：

  • 1、专业基础薄弱，代码积累量少，实操经验不足
  • 2、缺乏团队项目开发经验
  • 3、技术视野较窄，对行业前沿技术、企业开发规范了解较少。

• 本学期专项规划：

  • 夯实基础，吃透知识点；主动刷题练手，提升代码实操能力。

（4）本门课程学习计划与目标

1.课程规划与期待

我期待本门课程能够兼顾理论与实践，帮助我们建立完整的软件工程思维，摆脱“只会理论、不会实操”的学习困境。
在课程学习中，我会全程主动投入，不摆烂、不敷衍、不侥幸。

2. 代码量现状与目标

目前个人掌握C语言，累计有效代码量约3000行。
查阅行业标准可知：入职一流互联网、人工智能软件公司，本科阶段有效代码量需达到3-5万行；若从事高校教学科研工作，需具备扎实的代码功底、项目研发能力和科研实践积累，代码量需2万行以上。

3. 时间投入与提升选择

我计划每周投入12小时用于本门课程学习，包含课堂上课、课后作业、代码练习、复盘总结全部时间。

针对过往存在时间浪费、基础薄弱的问题，我的选择是D选项：比以前课要多很多，直到达到目标为止。正视自身短板，主动加倍投入时间，弥补前期学习漏洞。

4. 学期代码量规划

本学期共16周，计划课程结束后累计新增8000行有效代码量，每周平均完成500行代码练习，涵盖课堂实验、课后刷题、小型项目实操、作业代码优化。

（5）基于WOOP方法的课程目标规划

1. Wish（愿望）

本学期熟练掌握软件工程核心理论，具备基础的软件开发、测试、协作能力；累计完成8000行有效代码，坚持每周博客复盘；课程成绩达到优良，彻底摆脱基础薄弱的困境，建立系统的工程思维。

2. Outcome（结果）

目标达成后，我将不再是只会背诵理论的初学者，能够独立完成简单软件项目开发、代码调试、文档撰写；积累完整的课程学习成果与博客作品集；专业能力远超入学水平，具备初级IT岗位的基础能力，对未来职业发展更加自信、清晰。

3. Obstacles（障碍）

内部障碍：自律性不足，偶尔出现拖延、摸鱼心态；遇到复杂代码报错容易浮躁、心态焦虑；基础薄弱，学习进度偶尔跟不上课堂节奏；容易碎片化玩手机，打断学习状态。
外部障碍：课余事务较多，容易挤占专业学习时间；优质学习资源繁杂，筛选有效内容耗时。

核心失败因素：学习拖延，遇到难题容易逃避，无法长期保持稳定的学习节奏。很多时候立下学习目标，但因为拖延导致每日任务堆积，最后敷衍完成，无法达到预期学习效果。

4. Plan（风险防范计划，If-Then法则）

• 如果出现拖延、不想写代码、的情况，那么立刻放下手机，坐在书桌前，先完成10分钟基础任务，用微行动打破惰性。
• 如果遇到代码报错、知识点听不懂产生焦虑心态，那么暂停急躁情绪，逐句排查问题、查阅教材和资料，30分钟无法解决就及时请教老师同学，不逃避难题。
• 如果课余事务挤占学习时间，那么提前一天规划时间，优先保障课程核心任务完成，利用碎片时间补齐剩余任务。
  - 如果学习时忍不住玩手机，那么提前将手机调至静音、放置视线外，完成阶段性学习任务后再短暂休息。

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

（1）《构建之法》全书5个深度疑问

问题1：

关于软件工程的目标：创造“足够好”的软件

我看了一段文字： 软件工程的核心目标是在时间、成本、人力的约束条件下，创造“足够好”的软件，而非追求完美的软件。

我有这个问题： 书中强调软件不需要绝对完美，适配场景、满足需求即为“足够好”。但在人工智能、金融、医疗等高危领域，软件漏洞会直接引发安全事故、财产损失甚至人身风险，为何教材仍统一倡导“足够好”而非“极致严谨”？

参考依据： 查阅行业资料可知，医疗软件、金融交易系统、自动驾驶程序对代码零漏洞、高稳定性要求极高，不允许“适度瑕疵”。普通民用软件可追求性价比下的足够好，但高危软件的容错率极低。

核心困惑： 软件工程“足够好”的标准是否存在场景局限性？教材未区分行业场景统一立论，是否不够严谨？

问题2：

关于软件团队的各类开发模式

我看了一段文字： 软件团队包含主治医生模式、明星模式、团队模式等，不同模式适配不同规模的开发项目，各有优劣。

我有这个问题： 书中提到明星模式依靠核心技术人员主导项目，效率高但团队稳定性差。在高校课程小组项目中，多数团队都是“一人主导、多人划水”的伪明星模式，这种模式短期能完成作业，但无法锻炼全员能力，为何高校软件工程课程仍普遍采用自由组队、自主分工的模式，不规避低效的团队模式？

参考依据： 多数往届学生博客反馈，小组作业常出现少数人包办、多数人躺平的情况，团队协作能力两极分化，违背软件工程团队培养的初衷。

核心困惑： 高校教学场景下，如何平衡项目完成效率与全员能力培养？教材未针对学生团队场景给出适配方案，参考性有限。

问题3：

关于敏捷开发总结

我看了一段文字： 敏捷开发以快速迭代、响应需求变化、持续交付为核心优势，适配大多数互联网软件项目。

我有这个问题： 书中极力推崇敏捷开发的灵活性，但敏捷开发依赖团队高度自律、频繁沟通、精准分工。对于零基础、经验不足的学生团队，盲目使用敏捷开发容易出现迭代混乱、需求频繁变动、项目失控的问题，为何课程优先推荐学生使用敏捷开发模式？

参考依据： 很多学生项目复盘显示，新手团队使用敏捷开发，会因为每日例会流于形式、迭代目标不清晰，导致项目进度远不如传统瀑布模式稳定。

核心困惑： 敏捷开发的适配门槛是什么？教材未区分新手团队与专业团队的差异，是否会误导初学者盲目套用模式？

问题4：

关于软件测试核心定义

我看了一段文字： 软件测试的核心目的是发现软件中的隐藏Bug，保障软件质量，测试是软件开发的核心必备环节。

我有这个问题： 书中强调测试不可或缺，但很多小型个人项目、简易工具程序，代码量少、逻辑简单，几乎不存在隐藏Bug，手动测试反而浪费大量时间。是否所有软件项目都必须设置完整的测试流程？小型极简项目是否可以简化甚至省略测试环节？

参考依据： 互联网小型开源极简工具，大多由开发者自主调试完成，无专门测试流程，依然可以稳定投入使用。

核心困惑： 软件测试的必要性是否根据项目规模、应用场景动态调整？教材一味强调测试的重要性，未给出差异化执行标准。

问题5：

关于软件创新的界定

我看了一段文字： 软件创新包含功能创新、技术创新、模式创新，只要在原有软件基础上完成优化、改动，即可视为创新。

我有这个问题： 书中对软件创新的界定过于宽泛，学生课程项目中简单修改功能、优化界面、调整代码逻辑，是否真的属于有效创新？行业内认可的软件创新需要具备实用性、突破性，微小改动是否存在“伪创新”？

参考依据： 企业项目创新、学术创新均要求具备实质性突破，无价值的微小优化不被认定为创新成果。

核心困惑： 教材对学生软件创新的界定标准是否过于宽松？容易导致学生混淆优化与创新的区别，缺乏创新核心认知。

（2）认真反馈

我的选择是C：有问题就问，至少一学期提三个问题， 认真按时填写反馈。

4、前车之鉴

文章链接： https://book.douban.com/subject/4006425/discussion/22803733/

感悟：
回顾自身大学学习，最大的问题就是时间管理混乱。以往我常常优先处理刷手机、无意义闲聊等D类事务，忽视学习、复盘、代码练习等B类重要不紧迫事务，导致任务堆积、学习效率极低。

结合自身规划，我决定从本学期开始，严格践行四象限管理法：将软件工程学习、代码练习、博客撰写列为A、B类核心事务，优先保障完成；减少无效娱乐、无意义琐事的时间投入。每日睡前梳理次日任务，每周复盘时间使用情况，彻底告别拖延内耗，把碎片化时间转化为专业积累。

文章链接： https://book.douban.com/subject/4006425/discussion/22803961/

感悟：
这篇文章直击很多计算机科班学生的痛点：身处科班专业，有优质的师资、课程、平台资源，但只会被动听课、死记理论，没有真正学懂计算机，实操能力远不如自学的非科班学生。

这正是我目前最真实的状态。作为科班学生，我拥有完整的课程体系和学习资源，但前两年一直流于表面学习，上课听懂就满足，课后不练习、不复盘、不实操，导致理论和实操严重脱节，看似是科班学生，实则基础薄弱、代码能力欠缺。

文章中前人的经历给了我极大的警醒：科班身份从来不是优势，实战能力、工程积累才是IT行业的核心竞争力。

本学期我彻底摒弃科班优越感，放下侥幸心态，开始夯实基础。不再满足于听懂课程，而是追求动手实现、吃透逻辑、积累经验，用代码量、项目经验、实战能力证明自己，弥补前两年的学习短板。

三、要求

博客园后台截图

GitHub截图

链接：https://github.com/xing540/xing540