构建之路，始于足下 —— 我的软件工程学习启航篇

构建之路，始于足下 —— 我的软件工程学习启航篇
作者：严文浩
一、初识严文浩：我的闪光点与博客初心
大家好，我是严文浩。
建立这个博客，是我软件工程学习旅程中的第一个正式脚印。在此之前，我写过一些零散的笔记，也曾在本地保存过不少代码片段，但从未系统地练习过如何将自己的思考、代码和学习过程整理成一篇符合格式的博客文章。正如老师所说，写博客很花时间，但它强迫我们把模糊的理解转化为清晰的表达，这种"费曼学习法"式的输出，是单纯看书或刷题无法替代的。我打算坚持一个学期，看看效果。如果哪位同学对我文中的观点有不同看法，非常欢迎反驳和讨论——思想的碰撞本身就是学习的一部分。
关于我自己，我想分享一个课本之外的闪光点：记忆力与信息整合能力。从小我就对地图、历史年表和各类知识图谱有着浓厚的兴趣。高中时，我花了一个暑假（约两个月）系统梳理了中国历代王朝的政治制度变迁，不仅记住了大量史实，还能用自己的逻辑把它们串联成因果链。这种能力迁移到计算机学习中，表现为我对知识框架和体系结构的敏感——我不满足于"这段代码能跑"，更想知道它为什么能跑，在整个系统中处于什么位置。
当然，上课交作业要有底线。我的底线是：绝不抄袭，按时提交，写不出来就写"写不出来"的思考过程。诚实面对自己的不足，比交一份漂亮的抄袭作业更有价值。
二、现状、经验与计划
（1）为什么选择这个专业？我的技能现状
选择软件工程，并非一时冲动。高二时，我偶然接触到了Python，用两周时间跟着网课写出了一个能自动回复简单消息的QQ机器人。虽然代码写得一团糟，全是复制粘贴，但当我看到程序真的在运行时，那种"创造"的喜悦让我确定了自己想走的路。我希望通过系统的学习，从"能让代码跑起来"进化到"能设计出跑得好、跑得稳的系统"。
对照合格的IT专业毕业生标准，我清醒地认识到自己还有不少差距。以下是我从技能调查表中选取的6项关键技能，以及我的现状与目标：
表格
技能项 当前水平 (0-9) 课程结束目标 (0-9) 提高手段
编程能力 (Python/C/Java) 5 7 每周完成3道算法题，参与课程团队项目，阅读优质开源项目代码
数据结构与算法 4 7 系统学习《算法导论》重点章节，LeetCode周赛，手写代码实现核心数据结构
软件工程/团队协作 3 6 在课程项目中担任具体角色，实践Git分支管理、代码评审
版本控制 (Git) 3 6 所有课程作业均用Git管理，学习rebase、cherry-pick等进阶操作
代码调试与测试 4 7 学习使用调试工具，为每个功能模块编写单元测试，养成TDD习惯
英语技术阅读 5 7 每周精读一篇Stack Overflow高票回答或GitHub官方文档
（2）阅读心得：上课、师生关系与学术诚信
a) 为何要来上课并且认真参与？
我曾一度认为，大学课程靠自学就够了，上课只是走形式。但读了那位同学的思考后，我意识到：上课的价值不在于"获取信息"，而在于"获取信息的方式"。同样的一个设计模式，自己看书可能需要半天才能理解其应用场景，而老师用十分钟的一个真实案例就能点透。更重要的是，课堂上的提问、同学的质疑、即时的讨论，这些都是单向的视频学习无法提供的"必要困难"。认真参与，本质上是在购买一种"被挑战"的机会。
b) 我期待的师生关系
在大学前两年，我体验过两种师生关系：一种是"讲师与学生"——老师念PPT，学生记笔记，考完试相忘于江湖；另一种是"教练与学员"——老师布置有挑战性的任务，在关键时刻给予反馈，学生则在实践中不断试错。
对于这门软件工程课，我毫不犹豫地希望是后者——健身教练与健身学员的关系。老师不是知识的搬运工，而是训练的设计者和成果的验收者。如果作业对我来说有些困难，我的选择是 C：向老师和同学请教，花更多时间，把作业全部完成。选A是自欺欺人，选B是逃避责任，选D是自我设限。只有C，才能真正带来能力的增长。
c) 引用、参考与抄袭的界限
在工作中引用文献、参考他人代码，与抄袭剽窃的根本区别在于"是否贡献了新的智力劳动"以及"是否诚实标注来源"。如果我阅读了一篇论文，理解了其核心思想，并在此基础上提出了自己的改进算法，同时明确引用了原文，这是学术继承。但如果我把别人的代码复制过来，改个变量名就声称是自己写的，或者把别人的观点用自己的话复述一遍却不注明出处，这就是剽窃。
在这门课中，我会严格遵守：凡引用必标注，凡参考必说明，代码提交中明确区分"自己写的"和"参考的"。
（3）我的未来选择与本学期规划
几年后，我希望能进入一流的软件公司或互联网/人工智能公司，从事核心产品的研发工作。对照前人的经历，我意识到这条路需要扎实的工程能力、持续的学习习惯和健康的身心。
优势：我有较强的自学意愿，对技术有 genuine 的热情；逻辑思维能力较好，擅长把复杂问题拆解。
劣势：代码量积累不足，缺乏大型项目经验；有时过于追求完美导致拖延。
针对这一选择，我的本学期规划是：
夯实基础：数据结构、算法、操作系统基础不牢，地动山摇。
增加代码量：从现在的"玩具项目"走向"有用户、有测试、有文档"的完整项目。
培养工程习惯：代码规范、版本控制、单元测试，这些"软技能"和写代码同等重要。
（4）这门课，我打算怎么学？
参考美国本科、国内软件工程本科以及美国大学软件专业的教学安排，我对这门课的期待是：它不应该只是教我怎么写代码，而应该教我如何在团队中、在有限的时间内、在变化的需求下，交付高质量的软件。
关于助教：如果有机会，我非常想当助教。教是最好的学，解答别人的问题能暴露自己理解的盲区。
我的代码量现状：
Python：约 3,000 行（主要是课程作业和小脚本）
C/C++：约 2,000 行（数据结构课程实践）
Java：约 1,000 行（面向对象课程）
总计：约 6,000 行
据我了解，要入职一流的软件公司/互联网/人工智能公司，累计代码量可能需要达到 5万-10万行，并且其中要有相当比例是生产级别的代码，而非一次性作业。从事高校教学科研工作，则更需要扎实的理论深度和独立研究能力，代码量要求相对灵活，但质量要求更高。
时间投入：我计划平均每周拿出 18-20 小时 用在这门课上（包括上课时间）。
关于时间投入的选择，我选 D：比以前课要多很多，直到达到目标为止。前两年我确实在某些课程上投入不足，现在既然明确了方向，就没有理由继续混日子。
代码量目标：我计划在本课程结束时，累计完成 10,000 行 高质量代码（从现在的6,000行增加到10,000行，本学期新增约4,000行），即每周约250行。这里的"行"指的是经过思考、测试、评审的有效代码，而非为了凑数硬拆的语句。
WOOP 计划：
第一步：Wish（愿望）
在本课程中，我希望能够掌握完整的软件工程流程，能够在一个4-6人的团队中独立负责一个核心模块的设计、实现与测试，最终交付一个可运行的、有实际用户价值的项目。
第二步：Outcome（结果）
如果愿望实现，最好的结果是：我不仅拿到了优秀的课程成绩，更重要的是，我简历上多了一个能讲清楚架构、能展示代码、能演示运行的项目。在团队展示时，我能自信地解释我模块的设计决策，回答老师和同学的质疑。这种成就感将是我继续深入学习的强大动力。
第三步：Obstacles（障碍）
回顾过去的经验，以下障碍最可能阻止我实现愿望：
内部障碍：拖延症（总想"明天再开始写"）、遇到困难容易逃避（卡在一个bug上就想刷手机）、完美主义（因为怕写不好而迟迟不动笔）。
外部障碍：其他课程作业冲突、团队沟通不畅、需求变更导致返工。
最可能的失败因素：拖延导致的"最后一公里"放弃。很多项目开头很热闹，中期遇到难题，后期因为时间不够而草草收尾。我最大的敌人不是智商，而是"明天再说"。
第四步：Plan（风险防范计划）
如果 我在程序没写完时想刷手机，那么 我就站起来离开电脑，到走廊走一圈，喝杯水，回来后先写25分钟（番茄钟），再休息5分钟。
如果 我遇到一个bug超过30分钟没解决，那么 我就先记录问题，向同学或助教请教，而不是一个人死磕。
如果 周末有其他课程作业和软工作业冲突，那么 我在周五晚上就制定好周末的时间分配表，优先保证软工团队的集体开发时间。
如果 我发现自己因为怕写不好而拖延，那么 我就先写"最烂的一版"，把功能跑通，再迭代优化。
三、读《构建之法》后的五个问题
在课程要求下，我快速阅读了邹欣老师的《构建之法——现代软件工程》全书。以下是我提出的五个问题，它们或源于困惑，或源于不同经验的反思：
问题1：结对编程在水平差异大的学生群体中如何有效实施？（第4章 两人合作）
书中第4章大力推崇结对编程（Pair Programming），认为其能显著提高代码质量、促进知识传递。但在我的观察中，高校教学场景下的结对往往面临一个现实问题：两位同学的时间安排、编程水平、甚至学习态度差异巨大。如果一方是"老司机"，另一方是"小白"，强者可能因频繁解释而失去耐心，弱者则因跟不上节奏而焦虑，最终变成"一人写，一人看"，甚至"一人写，一人玩手机"。
我查阅了一些资料，有研究指出结对编程的效果高度依赖于"匹配度"和"文化适应性"（Williams et al., 2000）。那么，在课程设计中，老师是否应该先通过一个小型"试结对"项目来评估匹配度？或者，是否应该允许"非对称结对"——比如让水平较高的同学承担更多架构设计，而新手负责测试和文档，以此实现渐进式学习？书中强调了结对的好处，但对于"结对失败"的预防和补救措施，我希望能看到更多针对教学场景的具体建议。
问题2：敏捷宣言中的"可工作的软件胜过详尽的文档"是否适用于学生项目？（第6章 敏捷流程）
第6章介绍敏捷流程时，引用了敏捷宣言中的价值观："Working software over comprehensive documentation"。这在工业界无疑是正确的——快速迭代、响应变化。但在学生项目中，我注意到一个悖论：学生项目往往缺乏文档，导致后续维护和交接极其困难。工业界的敏捷有成熟的DevOps工具链和知识沉淀机制（如Wiki、Confluence），而学生项目通常只有代码仓库，且团队成员每学期都在换。
我的困惑是：如果我们在课程项目中过度强调"可工作的软件"而轻视文档，是否会培养学生"只写代码不写字"的习惯？在学生阶段，写文档（需求文档、设计文档、API文档）本身就是一种重要的训练。书中能否给出一个适用于教学场景的"轻量级文档"清单——既不至于让学生陷入文档泥潭，又能保证项目知识的可传承性？
问题3：PSP（个人软件流程）对创造性设计活动的度量是否过于机械？（第2章 个人技术和流程）
第2章详细介绍了PSP，要求开发者精确记录在每个阶段（计划、设计、编码、测试、复审）所花费的时间。我尝试实践了一周，发现在架构设计和算法构思阶段，时间记录变得异常困难。创造性工作往往不是线性的：你可能在洗澡时想到一个方案，在走路时推翻它，在编码时突然顿悟。强行把这段时间切割成"设计30分钟，编码2小时"，不仅操作困难，还可能打断心流（Flow）。
我查了一些关于PSP的批评，有学者指出PSP更适合重复性、模块化的开发任务，对探索性、研究性的工作适应性较差（Cockburn & Williams, 2001）。那么，对于课程中那些需要"从零设计一个系统"的项目，是否应该允许一种更灵活的PSP变体？例如，只记录"深度工作时段"的起止，而不强制区分设计还是编码？或者，PSP的核心价值究竟是"精确的时间数据"还是"对自身效率的觉察"？如果是后者，那么记录方式是否可以更人性化？
问题4：关于"创新"章节的叙事是否过于乐观，忽视了市场验证的重要性？（第16章 IT行业的创新）
第16章讲述了IT行业的创新故事，充满了激情与颠覆。但作为一个关注科技新闻的学生，我注意到书中对创新成功的案例着墨较多，而对创新失败的剖析相对不足。Google Glass是技术上的创新，但市场并不买账；许多开源项目技术卓越，却因为没有商业模式而难以为继。
我的问题是：对于软件工程专业的学生，我们更应该培养的是"技术创新能力"还是"市场验证能力"？书中提到"创新者都是大赢家"，但现实是"一将功成万骨枯"。在课程项目中，我们是否有机制来训练"判断一个功能是否值得做"的能力，而不仅仅是"如何把功能做好"？例如，能否在需求分析阶段引入更严格的"用户价值验证"环节，而不是默认"只要实现了就是成功"？
问题5：代码量作为能力衡量指标的效度问题（第3章 软件工程师的成长）
第3章提到代码量与工程师能力的相关性。我承认，没有足够的代码量，手感确实培养不出来。但我也观察到，GitHub上许多优秀的开源项目（如Redis、SQLite）核心代码量并不大，但其设计之精巧、质量之高令人叹服。相反，有些项目代码量巨大，却充斥着复制粘贴和冗余逻辑。
我的反对意见是：在不区分代码质量、复杂度、复用程度的前提下，单纯比较代码量，可能会导向错误的努力方向。如果学生为了"刷量"而把三行能写完的代码拆成十行，或者拒绝使用成熟的库而重复造轮子，这与软件工程"高效、复用"的精神是相悖的。书中能否进一步阐述，在统计代码量时，如何区分"有效代码量"和"垃圾代码量"？或者，除了代码量，是否应该有更综合的指标（如代码审查通过率、单元测试覆盖率、重构次数）来衡量一个工程师的成长？
四、前车之鉴：阅读前辈博客的感想
在课程推荐的博客列表中，我重点阅读了几位前辈的经验分享。以下是我对其中三篇文章的具体感想（文章链接请参见课程主页推荐列表）：
感想1：关于师生关系的重新定义
我阅读了邹欣老师的博客文章《师生关系：健身教练与健身学员》（参考链接： http://www.cnblogs.com/xinz/p/6660698.html ）。这篇文章彻底颠覆了我对大学课堂的期待。
过去，我总觉得"我交了学费，老师就有义务让我听懂"，这是一种典型的"餐馆与食客"心态。但邹老师用健身教练的比喻点醒了我：教练可以提供科学的训练计划和及时的反馈，但肌肉必须你自己长。老师布置有挑战性的作业，不是"为难"学生，而是"训练"学生。如果训练没有重量，肌肉永远不会增长。这让我反思自己过去对待困难作业的态度——我是否太习惯于待在舒适区了？
这篇文章也让我理解了为什么课程要求如此严格。不是老师不想让我们轻松，而是轻松的学习路径通向的是平庸。我决心在这门课中，主动承担重量，把每一次困难作业都当作一次"增肌训练"。
感想2：关于"做中学"的实践智慧
我阅读了一篇学长分享的软工课程回顾博客（文章记录了其从最初抱怨作业量太大，到最后收获满满的完整心路历程，详见课程推荐阅读列表）。其中有一句话让我印象深刻："不要等完全学会了再做，因为软件工程你永远学不完全；边做边学，边错边改，这才是正道。"
这与我过去的学习习惯形成了鲜明对比。我以前总想把所有知识点都"预习"完再开始动手，结果往往是：预习到一半就失去了兴趣，或者发现实际问题和理论差距很大。学长的经历告诉我，软件工程是一门实践的科学，代码写出来那一刻的理解，比看书十遍都深。我计划在本学期中，把"动手"的优先级提到"完全理解"之前——先做出来，再理解为什么这样做。
感想3：关于学术诚信的底线
我还阅读了一篇关于高校抄袭案例处理的文章（课程推荐列表中关于学术诚信的专题文章）。文中详细列举了各种"看似无害"的学术不端行为：复制同学的代码改个变量名、从网上下载代码不加引用、把别人的博客观点用自己的话重说却不注明出处。文章指出，很多学生的抄袭并非出于恶意，而是出于对"什么是抄袭"的模糊认识。
这让我高度警觉。在编程领域，"参考"和"抄袭"的界限有时确实很模糊——毕竟很多算法实现是标准的。但文章给了我一个清晰的判断标准：如果你删除了引用来源，你的作品是否还能独立成立？如果不能，那就是抄袭。 我把它作为自己的底线原则，并会在每一篇博客、每一次代码提交中严格执行。
以上就是我的第一篇博客。路漫漫其修远兮，我希望这个博客能记录下我从一个"会写代码的学生"成长为"会工程化解决问题的软件工程师"的全过程。欢迎交流，欢迎拍砖。
严文浩
2026年9月