软件工程第一周作业
第一周作业——随笔一篇
| 这个作业属于哪个课程 | 首页 - 计科24级56班 - 广东工业大学 - 班级博客 - 博客园 |
|---|---|
| 这个作业要求在哪里 | 第一周作业 - 作业 - 计科24级56班 - 班级博客 - 博客园 |
| 这个作业的目标 | 写一篇随笔博客 |
自我介绍
大家好，我是24级计算机科学与技术5班的车俊贤，我个人比较喜欢看网文，我在初一的时候开始接触网文一直阅读到现在，已经能够读一会就判断这网文是否值得读下去了（笑）。我还考了一个素描四级。我小时候什么也不懂，在小区的画室学了9年少儿画，然后开始接触素描和速写，学了大概三年左右，画了很多速写和素描，我们老师就提议我们去考级然后我就稀里糊涂的去了。
现状、经验和计划
其实我选择这个专业的原因我也不是很清楚。小时候上信息技术课觉得scratch这个东西好好玩，到初中上了半个暑假的课学习c++,然后我参加了我们学校和微信联合举办的微信小程序夏令营，自己当时纯纯小白一个，当时微信小程序的语言是跟javascript相近但在细节上不同的语言，我抱着本javascript大全看吐了也没写几行代码，当时工作人员在我们平板上下载了他们部门自主研发的傻瓜式程序，可以把微信小程序的东西像scratch一样拖到画布上搞，然后我也稀里糊涂的自己搞了一个小程序出来。之后我参加了学校的编程社，我们每天就是用python里面的turtle和pygame做一些小玩意，剩下时间就是“上网”时间——其实就是打游戏。可能就是这些经历影响我选择这个专业。距离一个合格的IT专业毕业生，我认为我还差一些相对应的知识乃至就业完成项目的全程经验，我的代码能力其实挺蹩脚的，我大概能看懂代码的作用，但让我写有点勉强自己了，好在我不会盲信ai的内容，而是提出要求让ai贯彻我的意志，或者让ai不停问我我到底想做一个怎么样的项目来提升准确率。从技能调查表当中我抽取了5个对于我目前情况而言比较重要的技能，如下表所示：
| 技能 | 目前水平 | 课程结束后达到的水平 |
|---|---|---|
| 需求对齐和代码健康度 | 2 | 6 |
| 手动掌控力和底层原理 | 2 | 6 |
| 验证深度和测试覆盖 | 3 | 6 |
| 工程复现性和构建完整度 | 2 | 6 |
| 自动化进化闭环与数据飞轮 | 3 | 6 |
我目前计划通过这5项手段提高水平：
1、坚持刷一点洛谷和力扣的题目提高基础的码力
2、看其他大佬的仓库，学习他们的一些规范
3、努力学习学校的专业知识，打好坚实的基础
4、积极学习其他人写的博客，从中提高这五项技能对应的能力
5、主动转变自己的思维，将课本上的理论知识和工程实践的做法相互印证提高对知识的理解效果
我认为来上课是为了让学生在经过老师的引导后形成自己的观点和知识体系，并为学生提供更多的机会来跟老师印证自己所学知识是否与正确道路有偏差，而认真参与则是让学生能更好的进入心流状态，更加顺利的跟随老师的引导建立知识体系。我在大学课程体会到了一厢情愿实则恶心到学生的所谓的“树苗”和“园丁”关系，“陌生人”关系，“好哥们”关系和“餐厅”和“顾客”关系，我希望这节课是健身教练 / 健身学员的关系。我认为作业无所谓困难程度，只要布置了就要完成，我会尽力请教老师同学和ai来完成作业，毕竟老师布置作业一般都会是根据他对我们整体情况的预估来布置的，如果感到难了恰恰是一个学习的机会（比如现在）。我认为在生活当中引用文献等行径与抄袭剽窃的核心区别在于“是否注明出处”和“是否产生新价值”。引用文献和参考资料一般都要在你自己的readme.md和论文的引用部分当中标出来，在引用文献，参考别人的资料，在别人工作的基础上继续开发时要看他在自己作品里面的开源协议。与此同时，必须要根据别人的成果有自己原创的内容和一些创新的点，不然这就好比你卖酒换了个瓶子就卖出去了。
我认为我今天的努力是为将来提供坚定的知识基础和良好的工程规范，我目前有两个想法：一个是考研，另一个是想成为一个llm应用工程师。相较于其他同学而言，我的优势是我心思比较细腻，可以考虑到更多东西根据实际情况更好做规划，我参加的比赛和项目也帮助我了解产品和培养自己的工程能力；劣势在于我的一些基础比如数学很差，这会很影响我的考研规划，还有一点就是我参加的比赛和项目还是不够多太单薄了，我实验室的师兄们似乎也有自己的想法不愿意带我，我可能得自己多找外快多积累经验。我的规划是学好课内知识的同时提高自己的竞争力，比如学习一些进阶知识和跟其他人组团打比赛，同时准备考研内容。
我目前想在这门课上进一步完善工程能力，我希望我学完这节课出来接实习不会像一个小白一样手足无措。我期待这节课能带我多做几个项目积累更多经验，或者说让我学习到工作后需要达到的工程规范和相关经验。我打算努力达成老师要求，以一种认真审慎的态度去学习。我不打算当助教。对于代码量，我在回答具体数字之前，我想先修正一下“代码量”这个指标。在2026年的今天，借助AI（Copilot/ChatGPT/Claude），我确实能在几小时内搭出一个功能完整的项目框架。如果我把AI生成的所有字符都算作“我的代码量”，那我可能已经有好几万行了，但这是对自己的欺骗。实际上我目前自己真正手打的代码量是c/c++1300行,java100行，python500行。在这个指标下我认为有资格入职一流的软件公司/互联网/人工智能公司，需要手打代码量在3000到4000自己亲自调试通过、且经过Code Review的核心逻辑，从事高校教学科研工作可能需要通常 1000~2000行 经过严密注释、符合学术规范的代码，毕竟高校科研对应的论文注重你复现论文和创新内容的表现。我想要在本课程结束时完成3000行代码，每周大概是180行到200行。一旦我完成这个结果，我可以说我已经充分具备了参与实习的勇气，我最可能的放弃因素应该是懒惰和焦虑，对于这一点我认为要松紧结合，需要及时注意心理状态及时放松。
提有质量的问题, 给认真的反馈
读完《构建之法》后的五个问题：
一、第1章“软件=程序+软件工程”——这个公式是否过于简化？
书中开篇提出“软件=程序+软件工程”，将软件工程定义为“把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程”。这个公式简洁有力，但我对此存有疑问。问题在于：这个等式将“程序”和“软件工程”视为两个可以简单相加的独立变量，暗示只要有了程序，再加上软件工程，就能得到软件。但现实中，程序与软件工程之间并非线性叠加关系，而是一种“化学反应”——工程化的过程会反过来重塑程序的架构、设计和实现方式，甚至可能推翻原有的程序基础。换句话说，一个“非工程化”的程序，即便加上再完美的工程方法，也未必能变成高质量的软件；而一个从第一天就以工程化方式开发的程序，从一开始就不是“程序+软件工程”，而是“工程化的程序”。此外，作者在第一章中也提到软件具有复杂性、不可见性、易变性、服从性、非连续性等特殊性质。既然软件本身如此复杂，用一个简单的加法公式来定义它，是否会掩盖软件工程中那些无法量化的、依赖经验和判断的部分？
二、第3章“软件工程师的思维误区”——“分析麻痹”与“过早优化”之间的边界在哪里？
书中第3章列举了软件工程师的几种典型思维误区：分析麻痹、不分主次想解决所有依赖问题、过早优化、过早扩大化/泛化。其中，“分析麻痹”被描述为“想弄清所有细节之后才动手”，“过早优化”则是“既然软件是‘软’的，就过早地进行优化”。我的困惑是：这两个误区之间的灰色地带太宽了。什么时候算是“充分分析”，什么时候已经滑向了“分析麻痹”？什么时候算是“合理设计”，什么时候已经变成了“过早优化”？书中给出了误区的定义，却没有给出明确的判断标准。以实际开发为例：一个复杂系统的架构设计，需要多少前期分析才算合理？如果严格按照书中“做中学”的理念，也许应该快速启动、边做边改。但大型系统的架构决策一旦在早期出错，后期重构的成本可能是毁灭性的。
三、第4章“结对编程”——在AI时代，结对编程的价值是否被高估？
书中第四章详细介绍了结对编程，将其描述为“一对程序员肩并肩、平等地、互补地进行开发工作”，并认为结对编程“能提供更好的设计质量和代码质量”。我不反对结对编程的价值，但在2026年AI辅助编程已经高度普及的背景下，我对书中结对编程的论述产生了疑问。首先，结对编程的核心机制之一是“实时代码复审”——驾驶员写代码，领航员在旁边审查。但今天AI编程助手（如Copilot、Cursor、Claude等）已经能够提供即时的代码建议、错误检测和风格检查。AI的“审查”速度远超人类，覆盖面也更广。在这种背景下，人类领航员的价值究竟在哪里？是发现AI发现不了的逻辑漏洞？还是提供AI无法提供的设计层面的判断？其次，书中提到“驾驶员和领航员不断轮换角色，不要连续工作超过一小时”。这种高频的角色切换对人的精力和专注力要求极高。而在AI辅助下，一个人借助AI工具可以在更短时间内完成同样质量的工作。那么，结对编程在效率上的劣势是否仍然值得？书中对结对编程的论述写于AI普及之前，这一章节在AI时代是否需要大幅修订？
四、第6章“敏捷流程”——敏捷是否对“弱团队”过于苛刻？
书中第六章介绍了敏捷流程，指出敏捷的核心不是盲目加快速度，而是一套价值观和方法论的集合。书中也坦率地指出了敏捷的弊端：过度追求迭代速度易忽视代码质量、需求频繁变更易导致架构混乱、对团队沟通能力要求极高。但最让我在意的是书中一句看似轻描淡写的话：“如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反”。这句话逻辑上没问题，但问题在于：几乎所有团队在转向敏捷之前都是“弱团队” 。敏捷本身不就是一个帮助团队变强的方法论吗？如果“弱团队”不能用敏捷，那他们该用什么来变强？这就成了一个悖论——你需要先变强才能用敏捷，但不用敏捷又不知道怎么变强。
五、第2章“个人开发流程（PSP）”——数据驱动的个人改进是否现实？
书中第二章介绍了PSP（Personal Software Process），强调通过量化管理个人开发活动——包括时间记录、缺陷统计、任务拆分等——来实现持续改进。PSP的基本流程是：计划→设计→编码→测试→记录→总结。我的疑问不在于PSP的理念，而在于它的可执行性。书中自己也承认了PSP的几个局限：依赖于工程师输入数据的时间代价、数据可能遗失或不准确、可能会出现一些数据不利于工程师本人的情况。此外，PSP记录的是“工程师如何实现需求的效率”，而不是“顾客对产品的满意度”，工程师有可能很高效地开发出一个用户不喜欢的软件。在现实中，一个忙碌的开发者面对紧张的交付压力，真的会坚持记录每一个缺陷、每一段时间分配吗？我自己在项目中尝试过类似的记录方法，前两周还能坚持，第三周就开始遗忘和敷衍，第四周彻底放弃。书中提到“PSP的定位是每一位开发人员”，但这个定位是否过于理想化？更关键的是：在AI辅助编程时代，代码的产出方式发生了根本变化——大量代码由AI生成，开发者更多扮演“审核者”和“调优者”的角色。传统的PSP指标（如代码行数、缺陷数）是否还能准确反映个人能力的成长？如果不能，PSP是否需要一套针对AI时代的全新指标体系？
为了改进教学，收集资料，老师在教学过程中会要求学生填写对课程的反馈， 我会有问题就问，至少一学期提三个问题， 认真按时填写反馈。
前车之鉴
读《一直在路上》令我想到一个问题：AI时代，“亲自敲一遍”还重要吗？这篇文章最打动我的，是作者大一时的那个朴素举动——看到杂志说“要注重实践”后，就把《C++程序设计》书后的例题一个一个敲进电脑运行。在今天看来，这个行为似乎有些“笨拙”——有了AI，我们不再需要逐字逐句敲代码，直接复制粘贴或者让AI生成就行了。但正因如此，这个细节在今天反而更值得警醒。“敲一遍”的本质从来不是输入字符，而是让大脑跟手指一起走一遍逻辑。 AI帮我们把代码写好了，但那个“跟着逻辑走一遍”的过程如果被跳过了，看起来效率提高了，实际上可能什么都没留下。我借助AI完善了很多小项目，但冷静下来问自己：如果关掉AI，我还能独立写出那些功能吗？答案并不乐观。作者还提到，他大二硬啃侯捷的《深入浅出MFC》，虽然没完全看懂，但至少明白了框架的重要性。这个经历让我想到，在AI时代，我们更容易产生“看懂了”的幻觉——AI给了答案，我们快速扫一遍，觉得“嗯，有道理”，然后关掉窗口，什么都没记住。真正的学习，可能还是需要一些“硬啃”的时刻——那些AI帮不上忙、必须靠自己理解才能跨过去的坎。
读《不要轻易在简历上写我热爱编程》则令我思考AI时代，“热爱”的门槛变高了还是变低了？这篇文章最尖锐的观点是：“热爱”不是写在简历上的装饰品，而是需要用行动和时间来背书的。作者用一系列亲身经历定义了什么叫真正的热爱——啃两年没电脑可用的手册、熬通宵用Google搜索、从零自学一个技术方案撑起百万日活。读完我第一反应是心虚：我也说过自己“对编程感兴趣”，但我为这份“兴趣”付出过什么？作者那种“愿意为它牺牲周末、啃英文文档、熬通宵解决问题”的劲头，我有吗？坦白说，大部分时候没有。但我也在想：在AI时代，“热爱”的标准是否需要重新定义？AI让入门门槛大幅降低——不需要背API、不需要记语法、遇到问题随时问。今天说“我热爱编程”的人，不需要像作者当年那样“生看两年手册没碰过电脑”。从这个角度看，好像“热爱”更容易了。但换个角度想：当AI能帮你完成80%的工作时，你愿不愿意为了那剩下的20%去深挖、去调试、去理解底层原理？ 当AI给出的答案能用但你不完全理解时，你愿不愿意停下来把原理搞清楚再继续？这可能才是AI时代“真正热爱”的试金石——不是因为你能用AI做多少事，而是你愿不愿意在AI做完之后，还花时间去弄懂它为什么这样做。所以，前辈文章的核心精神在今天依然成立：“热爱”不是靠嘴说的，是靠行动证明的。 只不过在AI时代，证明的方式变了——不再是你愿不愿意“吃苦”，而是你愿不愿意在AI已经给了答案之后，还去追问一句“为什么”。
两篇读下来，最大的收获不是某个具体的知识点，而是一个警醒：说“我在学”很容易，真正“学进去”很难。 我借助AI完成了不少东西，但其中有多少是“真的长在我脑子里了”，需要诚实地面对。接下来的课程里，我的目标很朴素：不让AI替我思考，只让AI替我执行我已经理解的任务。 遇到AI写的代码，多问一句“这为什么能跑通”；遇到不懂的概念，不急着让AI解释，先自己翻文档试一遍。这可能比完成多少行代码、做完多少个项目更重要。
链接：
《一直在路上》：https://www.cnblogs.com/xiaozhi_5638/p/4485805.html
我已按课程要求，在 GitHub 上创建了与 ID 一致的仓库：
https://github.com/dredgeship/dredgeship
浙公网安备 33010602011771号