软件工程第一周作业

软件工程第一周作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	第一周作业
这个作业的目标	介绍过去，现在和未来

一、自我介绍

大家好，我是陈安东，广东工业大学计算机科学与技术专业24级5班的学生。

我是怎么和计算机结缘的，主要是在高中时期，学校里有奇思科创社，会去打一些机器人比赛什么的，也在这个过程了解到了Python，还有信息课本里那些高大上的名词，给计算机添加了一份神秘感，让我有了了解它的冲动感。加上我喜欢打游戏，让我在填志愿的时候把计算机放在了第一栏。

我兴趣爱好比较广泛吧，除了打电动，我也喜欢运动，看小说，还喜欢吃饭睡觉。

二、现状、经验和计划

（1）专业选择、差距与技能现状

老实说，我选计算机专业的原因没那么高大上——就是觉得“写代码挺酷的”，加上打游戏的时候总好奇“这个效果是怎么实现的”。但真正进了大学之后才发现，觉得酷和真的能做是两码事。

距离一个合格的IT专业毕业生，我觉得自己差在哪？首先是工程化的思维方式——我目前写代码还是“能跑就行”的水平，很少考虑可维护性、扩展性、测试覆盖这些东西。其次是底层原理的理解——我会用框架，但框架底下怎么回事基本说不清楚。第三是项目经验——做过的东西大多是课设和练手项目，没有真正经历过“从需求到上线”的完整流程。

从技能调查表中，我选了6项对我现阶段最重要的技能：

技能	目前水平	课程结束目标
代码规范与可读性	3	6
需求分析与对齐	2	5
测试意识与覆盖	2	6
工程化构建能力	2	5
调试与问题定位	4	7
代码复用与模块化	3	6

我计划通过以下5项手段提升水平：

1. 坚持刷洛谷：每天至少1道题，保持手感的同时训练把思路翻译成代码的能力。
2. 阅读优秀开源项目：每周看一个开源项目的源码或文档，学习别人的代码组织和规范。
3. 认真对待每一次课程项目：不满足于“跑通”，而是追求“写得好”——包括注释、测试、文档。
4. 写技术博客：把学过的知识点写出来，能写清楚才算真的懂。
5. 主动做Code Review：找同学互相看代码，也把自己的代码给别人看——被挑刺才能进步。

（2）关于上课、师生关系与学术规范

为什么要来上课并且认真参与？

我看到那位学生的思考，里面有一句话特别戳我：“大学不是高中，没有人逼你学，但也没人替你学。”我来上课不是为了应付考勤，是因为课堂是最高效的信息过滤机制——老师把最关键的东西挑出来讲给你，比自己漫无目的地翻书快得多。认真参与则是为了让自己进入“心流”状态，不然人在教室心在窗外，坐一上午也是浪费时间。

师生关系与作业困难

我在大学里体验过好几种师生关系：有的像“陌生人”——一学期下来老师不认识你；有的像“餐厅与顾客”——我交钱了你就该给我服务。我最希望这门课是 “健身教练/健身学员”的关系——教练给你制定计划、指出问题，但最终练不练、练成什么样，取决于你自己。

如果作业对我来说有些困难，我会选择向老师和同学请教，花更多时间，把作业全部完成。不是因为我很厉害，恰恰相反——觉得难才说明在学新东西，如果所有作业都轻松完成，那这门课对我的价值就大打折扣了。

引用与抄袭的区别

在我看来，核心区别在于 “是否注明出处” 和 “是否产生新价值” 。引用文献、参考别人的代码，只要在文档里明确标出来源，就是在别人肩膀上继续建设；而抄袭是把别人的东西拿来当成自己的，不标注、不消化、不创造新东西。开源协议不是“随便用”的许可证，每个项目都有自己的协议要求，使用前必须看清楚。

（3）未来规划

我目前的规划是找工作，个人倾向于稳定一点的类型，现阶段就是不断提升自己的代码水平，勤加练习，争取能找到实习，丰富自己的简历。

本学期的规划：

• 课内：认真对待每一门专业课，尤其是数据库、Linux技术这些核心课程
• 课外：每周至少10小时自学（算法、框架、工具链）

（4）课程计划与代码量

我对这门课的期待很朴素：学完以后，接一个实习不会像小白一样手足无措。我希望通过这门课真正理解“工程”和“写代码”的区别。

关于代码量，我想先说一下我的理解。在2026年，AI辅助编程已经很普及了——Copilot、Cursor、Claude这些工具能帮你生成大量代码。如果把AI生成的所有字符都算作“我的代码量”，那是对自己的欺骗。真正算数的，是自己手打、自己调试、自己理解了的代码。

为了有资格入职一流的软件公司，我估计需要手打3000-4000行自己调试通过、经过Code Review的核心逻辑。从事高校教学科研工作的话，可能需要1000-2000行经过严密注释、符合学术规范的代码。

我打算平均每周花10-12小时在这门课上（含上课时间）。

WOOP计划：

• Wish（愿望） ：学期结束时，能独立完成一个结构清晰、有测试、有文档的小项目，并且敢把它写在简历上。
• Outcome（结果） ：如果实现了，我可以 confidently 说自己“会做工程”了，找实习的时候不会心虚。
• Obstacles（障碍） ：最大的障碍是懒惰和拖延——具体表现是“今天太累了先歇着”、“这题太难了先放着”，然后一放就是一周。
• Plan（计划） ：如果我想偷懒/拖延，那么我就先做5分钟——不管多不想做，先打开编辑器写5分钟。大多数时候，5分钟之后就停不下来了。

三、提有质量的问题

快速阅读《构建之法》后，我有以下5个问题：

问题一：第1章 “软件=程序+软件工程”——这个等式是否过于简化？

书中开篇提出“软件=程序+软件工程”，程序=数据结构+算法。这个公式简洁有力，但我存有疑问。

问题在于：程序与软件工程之间不是简单的“相加”关系，而是一种“化学反应” 。一个“非工程化”的程序，即便加上再完美的工程方法，也未必能变成高质量的软件；而一个从第一天就以工程化方式开发的程序，从一开始就不是“程序+软件工程”，而是“工程化的程序”。用加法公式来定义软件，是否会掩盖软件工程中那些无法量化的、依赖经验和判断的部分？

问题二：第3章 “分析麻痹”与“过早优化”的边界在哪里？

书中第3章列举了软件工程师的典型思维误区：分析麻痹、不分主次、过早优化、过早扩大化。其中“分析麻痹”是“想弄清所有细节之后才动手”，“过早优化”是“在局部问题上陷进去”。

我的困惑是：这两个误区之间的灰色地带太宽了。什么时候算是“充分分析”，什么时候已经滑向了“分析麻痹”？什么时候算是“合理设计”，什么时候变成了“过早优化”？书中给出了误区的定义，却没有给出明确的判断标准。大型系统的架构决策一旦在早期出错，后期重构的成本可能是毁灭性的——这时候前期分析多一点，到底是“充分”还是“麻痹”？

问题三：第4章 结对编程——在AI时代是否被高估？

书中第四章将结对编程描述为“一对程序员肩并肩、平等地、互补地进行开发工作”，认为能“提供更好的设计质量和代码质量”。

但在2026年，AI编程助手已经能提供即时的代码建议、错误检测和风格检查。人类领航员的价值在哪里？ 是发现AI发现不了的逻辑漏洞，还是提供AI无法提供的设计判断？当一个人借助AI工具可以在更短时间内完成同样质量的工作时，结对编程在效率上的劣势是否仍然值得？这一章节在AI时代是否需要大幅修订？

问题四：第6章 敏捷流程——对“弱团队”是否过于苛刻？

书中第六章指出：“如果你的团队很弱，那么强行把敏捷套在上面也没有用，也许还会适得其反。”

这句话逻辑上没问题，但问题在于：几乎所有团队在转向敏捷之前都是“弱团队” 。敏捷本身不就是一个帮助团队变强的方法论吗？如果“弱团队”不能用敏捷，那他们该用什么来变强？这就成了一个悖论——你需要先变强才能用敏捷，但不用敏捷又不知道怎么变强。

问题五：第2章 PSP——数据驱动的个人改进是否现实？

书中第二章介绍PSP（Personal Software Process），强调通过量化管理个人开发活动来实现持续改进。PSP的流程是：计划→设计→编码→测试→记录→总结。

我的疑问在于可执行性。书中承认PSP的几个局限：依赖工程师输入数据的时间代价、数据可能遗失或不准确。在现实中，一个忙碌的开发者面对紧张的交付压力，真的会坚持记录每一个缺陷、每一段时间分配吗？我自己尝试过类似的记录方法，前两周还能坚持，第三周就开始敷衍，第四周彻底放弃。更关键的是：在AI辅助编程时代，大量代码由AI生成，传统的PSP指标（如代码行数、缺陷数）是否还能准确反映个人能力的成长？

四、前车之鉴

读《一直在路上》——AI时代，“亲自敲一遍”还重要吗？

这篇文章最打动我的，是作者大一时的那个朴素举动——看到杂志说“要注重实践”后，就把《C++程序设计》书后的例题一个一个敲进电脑运行。在今天看来，这个行为似乎有些“笨拙”——有了AI，我们不再需要逐字逐句敲代码。但正因如此，这个细节在今天反而更值得警醒。

“敲一遍”的本质从来不是输入字符，而是让大脑跟手指一起走一遍逻辑。AI帮我们把代码写好了，但那个“跟着逻辑走一遍”的过程如果被跳过了，看起来效率提高了，实际上可能什么都没留下。我借助AI完善了不少小项目，但冷静下来问自己：如果关掉AI，我还能独立写出那些功能吗？答案并不乐观。

真正的学习，可能还是需要一些 “硬啃”的时刻——那些AI帮不上忙、必须靠自己理解才能跨过去的坎。

链接：一直在路上——记我从初中到本科近十年的学习成长历程

读《不要轻易在简历上写我热爱编程》——AI时代，“热爱”的门槛变高了还是变低了？

这篇文章最尖锐的观点是： “热爱”不是写在简历上的装饰品，而是需要用行动和时间来背书的。

读完我第一反应是心虚——我也说过自己“对编程感兴趣”，但我为这份“兴趣”付出过什么？坦白说，大部分时候没有。

但在AI时代，我一直在想一个问题：“热爱”的标准是否需要重新定义？ AI让入门门槛大幅降低——不需要背API、不需要记语法、遇到问题随时问。今天说“我热爱编程”的人，不需要像作者当年那样艰难。但换个角度想：当AI能帮你完成80%的工作时，你愿不愿意为了那剩下的20%去深挖、去调试、去理解底层原理？这可能才是AI时代“真正热爱”的试金石——不是因为你能用AI做多少事，而是你愿不愿意在AI做完之后，还花时间去弄懂它为什么这样做。

所以，前辈文章的核心精神在今天依然成立：“热爱”不是靠嘴说的，是靠行动证明的。只不过在AI时代，证明的方式变了——不再是你愿不愿意“吃苦”，而是你愿不愿意在AI已经给了答案之后，还去追问一句“为什么”。

链接：不要轻易在简历上写我热爱编程，我热爱学习

两篇读下来，最大的收获不是某个具体的知识点，而是一个警醒：说“我在学”很容易，真正“学进去”很难。接下来的课程里，我的目标很朴素：不让AI替我思考，只让AI替我执行我已经理解的任务。遇到AI写的代码，多问一句“这为什么能跑通”；遇到不懂的概念，不急着让AI解释，先自己翻文档试一遍。这可能比完成多少行代码、做完多少个项目更重要。

准备工作确认

• GitHub账号：已注册，ID为 Anton123-lang，仓库地址：https://github.com/Anton123-lang/Anton123-lang
• 博客园账号：已开通个人技术博客，博客名：不转的秋月，默认编辑器已切换为Markdown
• 加入班级博客：已加入「计科24级56班（广东工业大学-计算机学院）」班级博客

（GitHub仓库README截图与博客园后台Markdown编辑界面截图如下）