软件工程第一周作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class78-Grade2024-CS/homework/15710
这个作业的目标	本作业旨在引导我们阅读《构建之法》并提出高质量思辨问题，树立学术诚信意识；思考职业方向，利用 WOOP 制定量化学习规划；理解教练式师生关系，主动提问反馈，培养软件工程工程思维与自我管理能力。

1. 介绍自己，建博客

我是广东工业大学计算机学院24级的学生，专业是计算机科学与技术。爱好是学习代码，热爱学习，喜欢新鲜的事物。

2. 现状、经验和计划

（1）最初填报志愿时，我对计算机行业了解不多，只是听说编程可以用代码创造软件、解决现实问题。在接触基础编程之后，我发现自己喜欢动手实践、通过调试把想法变成可运行程序，同时 IT 行业知识更新快，持续学习就能不断成长，因此选择了本专业。随着学习深入，我逐渐体会到软件开发不只是写代码，还包含系统设计、项目协作等内容，更加认可这个专业。

我选取 7 项核心能力进行量化规划（0–9 分，5 分可通过一般企业面试，9 分为世界一流水平）。

核心技能	当前水平	课程结束目标	提升手段
Programming: Comprehension 程序理解（阅读、分析、Debug）	2	6	阅读开源项目源码；刻意练习看代码画调用流程图；独立复现 bug，一步步断点调试，总结错误根源
Programming: Design 架构与模块化、接口设计	1	7	学习设计原则（开闭原则、单一职责）；从小项目练习模块拆分；画架构图、接口文档；阅读成熟项目的模块划分思路
Requirement 需求分析	1	6	练习梳理用户场景，区分 “用户想要什么” 和 “真正需要什么”；撰写需求文档，拆解功能点；多站在使用者角度思考，提前识别需求漏洞。
Basic Design Principles & Patterns 设计原则与设计模式	2	6	逐个学习常用模式（单例、MVC 等）；不要死记，结合业务场景理解适用条件；在自己项目中适度实践，避免滥用模式
Personal Software Process：源码管理（Git/GitHub）	1	6	所有练习项目使用 Git；掌握 commit 规范、分支管理、冲突解决；在 GitHub 托管项目，练习 Pull Request。
Ability to Learn 自主学习能力	2	6	遇到问题优先自主查阅文档、英文资料；定期给自己定技术学习小目标；写博客总结学习收获，建立自己的知识体系

（2）阅读博客心得

a) 关于《大学生上课为什么一定要认真听讲》阅读感悟

Scalers 认为上课认真听讲是一种需要刻意训练的能力，不能以老师讲课水平低、课程没有用为借口放弃听课，要训练自己从课堂中提取信息、保持专注的能力。而 CookieLau 的博文提出了不同视角：现实里老师授课质量参差不齐，认真听讲不是唯一获取知识的途径，在课堂上自主学习同样是锻炼专注力的方式，不能把 “听讲” 教条化。

读完两篇文章我认识到：专注是核心，形式是次要。如果老师授课质量高，就紧跟课堂节奏梳理知识体系；如果课堂内容收获有限，也不能摆烂混时间，可以利用课堂时间自主学习，但绝不允许放任自己养成涣散、走神的坏习惯。不管是听课还是自学，要锻炼自己长时间集中注意力，拒绝 “原生态” 无训练的思考模式。

b) 师生关系、作业困难的处理

邹欣老师在讲义中列举多种畸形师生关系：顾客‑食客、老板‑雇员、保姆‑幼儿、哥们、路人、狱警‑犯人，理想模式是健身教练与学员：老师作为教练给出训练任务、指出问题，学员主动流汗付出，学习成长的主体永远是学生自己。

我在大学体验过「路人式」师生关系：老师上完课就离开，课下很难接触交流；也体验过类似教练式的关系，老师会布置有挑战性任务，同时提供答疑、反馈，督促我们动手实践。
我希望这门课是教练‑学员式师生关系：老师给出明确任务标准，及时给予作业点评反馈；我们作为学生主动投入实践，遇到困难主动沟通，而不是等着老师把知识嚼碎喂给我们。

如果老师布置的作业对我有些困难，我选择 E（其他）+C：
首先自己仔细审题，查阅教材、网络资料，拆解任务，尝试独立完成；遇到实在无法解决的卡点，整理好自己已经尝试过的思路，带着问题向老师、同学请教，投入更多时间迭代调试，尽全力完成作业。不会直接摆烂放弃，也不会只求及格草草了事，更不会抱怨作业难度。

c) 参考资料、二次开发与抄袭剽窃的区别

合理引用、基于别人成果二次开发和抄袭剽窃有明确界限：

1. 合理引用 / 二次开发：明确标注来源，尊重原作者版权。写文档时写明参考的文章、博客链接；写代码时，使用开源库、第三方组件，清楚哪些是自己写的，哪些是引用的开源代码，不把别人的成果冒充为自己原创，借鉴只是作为辅助，核心逻辑、业务实现由自己完成。
2. 抄袭剽窃：直接复制他人文档、代码，删掉原出处，全部冒充自己的劳动成果；大作业直接照搬别人完整项目，自己没有理解、没有修改、没有思考。

课程要求：写博客、项目文档，凡是借鉴别人的观点，附上原文链接；代码中使用开源模块，在文档说明使用了哪些开源组件，禁止复制别人完整作业直接提交。学校对于抄袭作业一般会判定作业零分，情节严重会记过处分，我会严格遵守学术规范。

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

结合前面读过的程序员成长博客，我未来的目标是成为工业界后端软件开发工程师，走工程实践路线，毕业后进入互联网软件企业工作。

优势：我有一定编程实践经验，愿意动手做项目；认同程序员需要持续自学，遇到问题愿意主动查资料解决；可以阅读简单英文技术资料；明白基础很重要，愿意花时间打磨底层基础，而不是只追求花哨框架。
劣势：大型项目经验少，没有完整团队项目实战经历；操作系统、计算机网络底层知识掌握浮于表面；工程思维薄弱，对需求分析、测试、版本管理、项目迭代的实践经验不足；代码质量、模块化设计有待提高。

本学期规划

1. 夯实计算机基础，复习操作系统、计算机网络相关知识点；
2. 认真完成软件工程课程全部个人、结对、团队项目，完整走完软件生命周期；
3. 坚持写技术博客，记录项目踩坑与总结；
4. 熟练掌握 Git/GitHub 团队协作流程；
5. 课余做一个小型完整后端实践项目，积累可展示的作品。

（4）本课程计划、WOOP 规划

阅读 UCSD、北航软件工程相关博客，软件工程不是背名词概念，而是“做中学”，重点是完整经历真实项目：需求分析、设计、编码、测试、迭代、团队协作，而不是期末交一份大作业就结束。
我期待这门课不只学习理论，能够体验真实团队分工，练习 PM、开发、测试等不同角色；获得老师、助教及时的反馈，学会迭代开发，拒绝一次性 “交作业式” 项目。

当前代码量

• C/C++：约 1200 行
• Python：约 1500 行
• Java：约 800 行
  合计有效代码约 3500 行

参考：入职一流互联网公司，本科阶段一般建议积累一万行以上有效项目代码（练习 demo 不计入，优先是有业务逻辑的项目代码）；高校科研教学岗位，更加看重论文科研成果，代码侧重算法、实验原型，对总代码行数要求相对低，但对代码严谨、可复现要求很高。

我打算平均每周拿出12个小时用在这门课上，我打算时间比以前课要多很多，直到达到目标为止。
课程结束希望新增3000 行有效项目代码；分摊每周大约完成 300 行有效代码。

WOOP 规划

Wish（愿望）
学好软件工程，完整完成个人、结对、团队项目；掌握需求分析、模块化设计、测试、Git 团队协作；产出高质量博客与可展示的项目作品，建立工程思维，向合格的软件开发者靠拢。

Outcome（最好结果）
课程结束，我不再只会写孤立小 demo，可以参与团队项目；懂得从用户角度思考需求，会做迭代开发；GitHub 有完整的课程项目仓库，博客沉淀多篇实践总结；项目可以作为求职作品集，个人工程能力得到明显提升。

Obstacles（障碍）

1. 内部障碍：自律不足，容易拖延作业，临近截止日期才赶工；遇到 bug 容易心态烦躁，不愿静下心调试；基础薄弱，部分任务理解慢，畏难想逃避。
2. 外部障碍：其他专业课学业压力挤压时间；团队协作时，队友进度不一致带来项目阻滞。

最可能失败因素：拖延，总把任务堆到截止日前突击，导致代码粗糙、博客敷衍，学习浮于表面。
克服思路：拒绝临时赶工，任务拆解到每周，定期检查进度，尽量提前完成，不卡点提交。

Plan（If‑Then 应对方案）

1. 如果发现自己拖延，不想动手写代码写博客，那就先做 20 分钟最小任务，哪怕只写几十行代码或者写一小段博客，启动之后再继续往下做；
2. 如果调试 bug 烦躁不想继续，就暂停，休息 15 分钟，重新梳理复现步骤，打印日志缩小问题范围，实在卡住就整理问题向同学助教求助，不要死磕摆烂；
3. 如果其他课程任务挤压时间，优先把软件工程任务拆分成小块，每天挤出 1‑2 小时，而不是直接放弃，拒绝 “等到有空再做”；
4. 如果团队项目队友进度不一致，就提前开会对齐任务，明确每个人每周交付物，及时沟通风险，遇到矛盾就对事不对人沟通解决。

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

《构建之法》阅读随笔（含5个高质量问题）

问题1
章节：第2章 个人技术和流程，2.3 单元测试
引用原文：“单元测试必须由程序员自己写，程序员在写产品代码的同时，也要写单元测试。”
我的问题：在工期紧张的小型项目中，如果业务需求频繁变更，一边写业务代码一边维护单元测试会消耗大量时间，此时强制要求程序员手写单元测试，会不会反而拖累项目交付速度？
支撑资料：我做课程小项目时有这样的经验，需求一改，大量单元测试代码就要同步修改，甚至出现“改测试比改业务代码还麻烦”的情况。很多小型创业团队在早期原型阶段，并不会写完整单元测试，优先保证功能跑通。
困惑：书中将单元测试作为程序员必备流程，但是没有清晰划分场景边界。单元测试是否存在适用场景？小项目、原型开发是否可以酌情降低单元测试标准，而不是一刀切强制要求？

问题2
章节：第6章 敏捷流程，6.2 敏捷的原则
引用原文：“敏捷开发欢迎需求的变化，即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。”
我的问题：如果客户在开发后期频繁提出颠覆性需求变更，完全推翻前期设计，敏捷开发该如何控制变更成本？
支撑资料：我看过不少团队案例，客户在迭代末期大幅修改核心业务逻辑，直接导致之前大量代码作废，项目延期、工作量翻倍。
困惑：书中强调拥抱变化，但是对于无边界的需求变更缺少约束方案。一味接纳后期重大需求改动，会不会让敏捷变成“无限改需求”，失去项目管控能力？敏捷要怎么区分“有价值的需求变更”和随意的需求改动？

问题3
章节：第9章 项目管理，9.3 估计和计划
引用原文：“项目估算不能只靠负责人拍脑袋，需要多名成员共同估算，基于历史数据来预估工作量。”
我的问题：学生团队几乎没有真实项目历史数据，大家缺少工程经验，每个人对任务难度判断差异很大，这种情况下，多人估算出来的工期，可信度高吗？
个人经验：课程小组作业做任务估算时，同学普遍低估开发难度，大家预估的时间总和远小于实际需要的时间，最后还是会延期。我们没有过往项目的历史数据作为参考。
困惑：书中的估算方法依托于成熟团队的历史项目数据，对于零基础学生团队，有没有更适配的工作量估算方式？如果缺少历史数据，多人共同估算是否只是形式？

问题4
章节：第16章 创新，16.2 创新的时机
引用原文：“创新不是凭空而来，大多是在现有产品基础上持续改进、渐进式创新；颠覆性创新很少，并且风险极高。”
我的问题：在学校课程项目这种练习场景，我们是否应该主动尝试颠覆性创新？还是只适合做渐进式改进？
参考资料：很多课程大作业鼓励“做出有创意的作品”，打分看重创新亮点。但颠覆性想法往往复杂度极高，学生能力有限，大概率做不完。
困惑：书中提醒颠覆性创新风险巨大，不推荐轻易尝试。但是课程作业鼓励创新，这两者存在矛盾。学生项目里，我们该如何平衡创新想法与项目落地可行性？

问题5
章节：第17章 人、绩效和职业道德，17.4 职业道德
引用原文：软件工程师不能故意开发有漏洞、危害用户安全的软件；不能伪造数据，隐瞒产品缺陷。
我的问题：当企业业务目标和软件职业道德冲突时，比如公司要求尽快上线，明知道软件存在非致命安全漏洞，但管理层决定先上线、后续补丁修复，程序员该如何选择？
案例：很多互联网产品会带着已知低风险漏洞上线，计划后续迭代修复。如果程序员坚持不允许上线，可能会影响项目绩效，甚至面临职场压力。
困惑：书中给出了职业道德准则，但是没有讨论程序员在企业环境里的现实困境。程序员是否有权力阻止带缺陷的产品上线？个人应该如何平衡岗位职责、公司业绩与软件职业道德？

提问与课程反馈选择题
既然是健身/教练的师生关系，老师收集课程反馈，你会怎么做？
答案选D：经常提问题，平时就经常给老师和助教提反馈
理由：这门课类似教练带学员，学习不是单向接收知识。遇到不懂的知识点、作业卡点我会主动提问；课程有体验上的问题，也会及时向老师、助教反馈，帮助老师调整教学，同时也能让自己及时纠正学习误区，实现双向沟通。

4. 前车之鉴

1）
https://www.cnblogs.com/xiaozhi_5638/p/4485805.html

这篇程序员成长自述令人深受触动。作者出身鄂东乡村，求学阶段严重偏科、受应试教育束缚，高考考入普通二本，却凭借极强的自学能力逆袭。大学期间，他摒弃死记硬背，坚持理论结合实践，深耕编程基础，主动自学新技术、参加竞赛与实习，积累扎实功底。毕业后顺势创业，稳步深耕技术行业。文章也给出珍贵启示：IT 行业成长的核心是扎实基础、持续自学、深耕英语、拓宽技术眼界，真正拉开差距的从来不是天赋，而是持续自律的学习态度与踏实深耕的初心。

2）http://blog.csdn.net/haoel/article/details/1688104

读完陈皓的成长经历与职业感悟，我深受启发。他放弃安稳的银行国企工作，挣脱舒适圈深耕技术赛道，用亲身经历印证了清晰的职业规划对程序员的重要性。他将职业规划比作软件工程的观点令我印象深刻，人生发展如同项目开发，唯有明确核心需求，才能稳步落地、迭代成长。同时，他给出的成长建议十分中肯，程序员成长不能只钻技术硬技能，更要沉淀沟通、思维等软实力。前五年重在积累沉淀，摒弃浮躁功利，深耕基础、持续复盘，才能实现从量变到质变的突破，走出适合自己的技术之路。

3）http://mp.weixin.qq.com/s?__biz=MjM5MjUwNzIyMA==&mid=2649940459&idx=1&sn=2d58b0f711ad48a84fdeb5a846ac27a0&chksm=bea375d089d4fcc68856dd3c0453145ece2a934a8082dbc7beb615651fc4a183059020da4573#rd

读完这篇文字，我对 “热爱编程” 有了全新理解。作者用一个个真实故事告诉我们：热爱不是一句随口说出的口号，而是长期孤独、持续付出的行动。前辈们在缺少电脑、资料匮乏的年代啃手册、啃外文文档，克服重重困难坚持自学；也有人出身普通，靠着一股韧劲转行成为程序员。很多年轻人嘴上喊热爱，遇到困难却习惯性寻找现成教程、找借口退缩。真正的热爱，是主动突破限制，自己去查找资料、攻坚克难。热爱不可轻许，需要日复一日的坚持与行动来证明。

我的github链接：
https://github.com/dinnernumber1/dinnernumber1