随笔一则
| 软件工程 | https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/15692 |
| 这个作业的目标 | <熟练配置博客园、GitHub 账号，掌握 Markdown、Git 和高质量提问方法；完成自我介绍、专业能力评估与本学期学习规划，使用 WOOP 制定学习方案；阅读《构建之法》提出 5 个深度问题，阅读前辈博客总结经验；分清引用与抄袭，建立持续反馈的软件工程学习思维> |
自我介绍
这是创建博客后的第一则随笔，我先来简单做个自我介绍。我是一名来自广东工业大学计算机科学与技术专业的学生，除了专业知识外，我想说说自己的优势技能。在体育方面，我比较擅长篮球，主要打的是分卫的位置。同时，我的记忆力比较好，因此我的英语能力还算不错，这也离不开持之以恒的积累。关于写博客花时间但很有意义这个观点，我是持保留意见的的，在我看来，写博客无非是记录自己的所思所想，并分享给网上的人，这是有一定意义的，一是起到自我总结的作用，二是通过别人的评论也能收获经验，然而，就目前的网络环境来看，我认为没有太大意义，善于总结的人没有必要再花时间写博客，而且除非你公布了很新奇有意义的发现，否则他人的评论也大部分是无营养的，甚至可能左右自己的判断。
现状、经验和计划
专业选择
主要是基于互联网的时代走向选择了这个专业，而且计算机与其他各行各业的融合程度也很好，但就目前AI的冲击来看，软件这块或许不是一个好的选择。要成为一名合格的IT专业毕业生，我认为我主要缺少的是逻辑能力和编程能力，如何针对问题给出解决思路，在解决思路基础上如何用更为简单的代码进行实现。
技能调查表中对我重要的技能：验证深度与测试覆盖，工程复现性与构建完整度，智能体编排与工具使用，手动掌控力与底层原理，云原生部署与资源优化。目前水平：4，课程结束水平：6，提高水平手段：学习AI智能体开发相关知识，学习面试考点与技巧，完成个人项目的开发并理解业务逻辑，优化项目的代码实现，了解代码的底层原理。
心得
我来上课并且认真参与的原因：虽然现在大学教材和实际工作场景的有所脱节，但是教材以及老师传授的核心素养是在工作中学习不到的，这种基础的东西不可或缺。
我在大学中体验到的师生关系：老师是健身教练，学生是学员，学生希望自己有所提升，老师提供资源，我希望这门课同样如此，如果老师布置的作业对我来说困难，我会先向AI和其他同学求助，尽量先理解如何实现，如果实在理解不了，我会记忆这种方法。
在工作中我们引用他人文献资料进行开发是合法的，因为有明确标注，保护了他人的知识产权，而抄袭和剽窃则是没有明确标注引用，是不合法的。
为将来的准备
目前是在学习java后端的相关知识，但是考虑AI的冲击应该会往AI这一块转向融合，同时也尝试考公务员，希望能权衡好就业和考公这两者，留足充分时间学习。
我认为我的选择比较有底气，如果考公考不上还能走就业这条路。我给自己本学期的规划是继续巩固后端这个方向，往AI靠拢，考公也要开始积极备考。
在这门课的计划
看老师讲解课程内容会做好几个项目，希望自己锻炼业务能力，积累真实项目经验。我对这个课程的期待是老师能够指导我们完成独创性而非烂大街的项目，这样对学习理解会更有帮助。我打算认真度过这个课程。我不想当助教。我的代码量，c：10000，java：10000。为了入职，需要50000以上，从事高校教学科研工作10000足够。我打算花在这门课上的时间：比以前课要多很多，直到达到目标为止。
提有质量的问题, 给认真的反馈
问题1
章节：第 2 章 个人技术和流程，2.3 单元测试
引用文字：单元测试是程序员写的代码，用来测试自己写的功能，单元测试必须在写功能代码之前写（TDD，测试驱动开发）。
我的问题：在学生课程项目场景下，强制要求 TDD 先写测试再写业务代码，会不会带来过高的前期成本，反而降低小型项目开发效率？
资料与经验：
TDD 适合需求稳定、接口明确、长期维护的工业级项目。但课程大作业经常存在需求迭代、需求临时变更、需求边界模糊的情况。我做课程设计时，需求经常中途微调，如果先写单元测试，一旦接口改动，所有测试代码全部要重写，额外工作量很大。很多企业内部也不是所有模块都严格 TDD，只有核心底层模块采用 TDD，上层业务代码更多是写完功能后补单元测试。
我的困惑：书中似乎把 TDD 作为推荐标准实践，但没有区分项目规模、需求稳定性。对于短期、需求易变的学生项目，是否必须严格遵守 “先写测试，再写代码”？TDD 的适用边界在哪里？
问题2
章节：第 5 章 团队和流程，5.4 团队的模式（明星团队、交响乐队、爵士乐团队等）
引用文字：交响乐队模式适合大型、需求稳定、分工明确的软件项目；爵士乐团队适合需求不确定、需要持续探索创新的项目。
我的问题：在高校课程团队项目（4~6 人学生小组）中，学生既没有多年协作经验，技术水平参差不齐，爵士乐团队模式真的可落地吗？
资料与经验：
爵士乐团队强调自主沟通、即兴协作、没有严格固定分工。企业里的敏捷小团队，成员一般都具备成熟开发能力。但学生组队经常出现：部分同学基础薄弱、代码能力差距大，即兴式自由分工容易出现任务推诿、代码风格混乱、没有统一接口规范，最后经常变成少数人包揽全部工作。
我的困惑：书中直接将爵士乐团队作为可选团队模型，但忽略了团队成员能力差异这个前置条件。如果团队成员水平差距大，爵士乐模式反而容易造成项目失控，这种情况下是不是交响乐队（明确分工）更合适？
问题3
章节：第 8 章 需求，8.3 用户调研
引用文字：软件开发者要直接接触真实用户，观察用户使用场景，不能只靠自己脑补用户需求。
我的问题：学生课程项目几乎没有真实付费用户，很难找到足量真实用户参与调研，这种情况下，用户调研是不是流于形式？
资料与经验：
工业项目有真实用户群体，可以访谈、问卷、实地观察。课程项目一般是做一个 Demo 系统，目标用户大多只是同班同学。样本量小、用户没有真实使用动机，填写问卷也比较随意。很多小组做的用户调研只是随便发几份问卷凑材料，并没有真正挖掘痛点。
我的困惑：当无法获取真实用户场景时，书中这套用户调研方法论该如何调整？学生项目是否可以简化用户调研方式，或者用原型快速验证替代传统访谈调研？
问题4
章节：第 11 章 软件测试，11.5 回归测试
引用文字： 回归测试保证修改代码、修复 bug 后，原有功能不会被破坏；每次提交代码都应当运行回归测试。
我的问题：小型项目代码量不大，手动测试很快就能完成，是否仍然必须搭建自动化回归测试框架？
资料与经验：
自动化回归测试需要编写脚本、维护测试用例、配置 CI 环境，有一定学习成本。一个几千行的课程项目，每次改动后手动走一遍核心流程只需要几分钟。如果花大量时间搭建自动化回归框架，投入产出比较低。很多小型个人开源项目也不会配置全套自动化回归。
我的困惑：书中倾向自动化回归是必备实践，但没有说明项目规模阈值。如何判断项目什么时候值得投入精力搭建自动化回归测试？
问题5
章节：第 16 章 创新，16.2 创新的时机
引用文字：创新不是凭空想一个很酷的点子，创新来自用户痛点，在现有产品基础上持续改进。
我反对这一观点的片面性。
作者观点：创新源于真实用户痛点，是渐进式改进。
我的观点：除了基于现有用户痛点的渐进式创新，颠覆性创新一开始没有现成用户、甚至不存在对应的用户痛点。
资料与案例：早期计算机、互联网、大模型刚诞生的时候，普通用户根本不存在对应的使用需求，不存在 “现有产品痛点”。颠覆性创新是创造新场景、创造新需求，而不是单纯优化已有产品。
理由：书中重点讲软件产品的增量迭代创新，但是低估了颠覆性创新。渐进式创新适合软件维护迭代，但很多划时代产品，并不是解决已有用户痛点，而是创造了全新的用户场景。所以创新不只有从现有痛点改进这一条路径。
认真反馈
经常提问题， 平时就经常给老师和助教提反馈。
前车之鉴
感想一：读《.net 程序员工作两年总结》
文章链接：https://news.cnblogs.com/n/531362/
这篇文章讲述一名机械专科毕业生，从工厂流水线辞职，参加培训班转行.NET 程序员的真实经历。他一开始被培训班 “三个月学成高薪就业” 宣传吸引，线上视频自学，卡在委托、多态、索引器这些面向对象难点，长时间原地打转；培训阶段没有真正理解底层，只会模仿视频写代码，漏掉分号都要耗费很久排查；工作两年面试被大量底层、数据库、框架原理题拷问，才意识到自己很多知识只是会用，没有吃透原理。
读完最大的启发：速成培训只能教会 “怎么写”，很难教会 “为什么这么写”。很多同学包括我，很容易陷入 “跟着视频敲完代码 = 学会了” 的误区。视频照抄可以跑出结果，但遇到报错、需求改动就束手无策。文中作者在培训班大量时间只是模仿，对this、委托、多态只知其语法，不懂背后逻辑，学习效率低下。
给我的警示：
- 不要迷信短期速成。无论是网课、培训班，模仿之后必须独立脱离教程重写，遇到难点不能只记语法，要追问底层原理；
- 工作 / 面试考察的不是你做过多少 demo，而是遇到问题排查、理解底层机制的能力。文中两年工作经验的程序员，面试被大量追问索引原理、GC、集群、数据库索引，很多问题就是考验底层理解，而不是写业务 CRUD；
- 转行也好、科班也好，都会经历大量 “卡壳” 的黑暗期，遇到学不懂是常态，不要自我否定。但是不能只靠死磕视频，要多维度查阅资料、动手调试。
同时我也意识到，科班并不天然代表优势，如果只是上课抄作业，不去深究原理，也会落入和培训班同学一样的困境。
感想二：读 vczh《进入 2012 -- 回顾我走过的编程之路》
文章链接：https://www.cnblogs.com/geniusvczh/archive/2011/12/16/2290808.html
vczh（陈梓瀚），高中就自主写游戏引擎、脚本解释器，大学期间持续造轮子，做脚本语言、编译器，后来进入微软实习、正式入职，再调动到微软亚洲研究院。他提到一个很关键的学习方法论：不断去做那种 “刚好能做出来，但是再难一点点就做不出来” 的任务，持续给自己设置拉伸区的挑战，而不是反复做已经完全熟练的习题。
很多学生学习停留在 “完成课内作业”，作业难度刚好是自己舒适区，做完就不再拓展。而 vczh 高中就写 RPG 游戏、手写脚本引擎，不断挑战超出课本的难题。实习期间，他在微软接触单元测试、Scrum 敏捷开发、结对编程，明白了好代码不在于技巧多炫酷，而在于可以多人长期维护、便于修改需求变更，这一点和《构建之法》软件工程的思想高度契合。
反思我自己的现状：很多时候我只完成课程要求，做完作业就结束，很少主动给自己设置超出课程的挑战。比如学完数据结构，只完成课后习题，没有尝试手写简易容器、解析器这类项目。
收获：
- 学习编程不能只停留在完成作业，要主动找 “踮脚才够得到” 的任务，持续走出舒适区；
- 项目不在于数量，而在于深度。一个深入钻研的轮子，远好过一堆复制粘贴的 demo；
- 软件工程实践（单元测试、版本控制、架构抵御需求变更）不是工作之后才需要学，学生阶段就可以去实践。
感想三：读酷壳陈皓《对程序员职业的一些建议》
文章链接：http://coolshell.cn/articles/4561.html
陈皓结合自己在国企、外企多年经历，讨论程序员的职业选择、热情与能力的区别。他区分了 “兴趣” 和 “热爱”：兴趣可以驱动你入门，但真正的热爱，会驱使你在业余时间依旧主动钻研；同时热情不等于能力，热情之外，还要有独立钻研、解决问题的硬实力。他提醒应届生，不要只盯着薪资待遇，能力和经历才是根本，薪资只是能力的附属品；同时第一份工作会深刻塑造你的工作习惯，但并不决定人的一生，人依然可以靠努力弥补起点的差距。
文中一个观点令我印象很深：技术本身只是工具，真正重要的是用技术去解决什么问题。很多同学（包括我）容易陷入技术崇拜，热衷于追逐新潮框架，却忽略这个技术要解决什么现实问题。同时他也提到，如果缺乏热情，仅仅看重 IT 行业高薪，这条路会走得很痛苦。
联系我作为大三计算机本科生的处境：
- 我需要时常自省：我对编程是单纯觉得就业前景好，还是真正愿意主动钻研、遇到 bug 愿意沉下心排查；
- 做技术选择、做项目的时候，优先思考要解决的问题，而不是盲目堆砌时髦技术；
- 不要焦虑短期的薪资、别人的进度，把重点放在内功积累：计算机基础、解决问题、工程实践，长期来看这些才是核心竞争力。
编辑界面的截图：
仓库截图：
浙公网安备 33010602011771号