说在前面暖暖场 #

这是我发的第一篇博客，是为了“应付”“现代软件工程”这门课的作业而写的。

随便唠唠 #

实话实说，”现代软件工程“这么门的课堂是我上完了所有我选的课之后，感觉到最符合我预期的。我最开始选择这门课的时候，就是抱着希望可以学到一些经验的、方法的、工程的而不是“理论”的东西。邹欣老师的”做中学“让我明白了很多，让我从GitHub上的down变成了clone，从能用，做到了会用。也是”现代软件工程“这门课，让我写下自己的第一篇博客，因此我由衷的感谢这门课的授课老师——邹欣老师，不论是在课上还是课下都让我收获了很多的东西，也希望我尊敬的邹老师期末的时候也能给我高分。🐶

关于《构建之法》 #

虽然邹老师为我留下了很多时间去细品他的佳作，但说实话我的确没有拿出很多时间去精读这本书，只是草草地通读了一遍。我并不是一个热爱去写书评的人，看技术类的书籍也不过是为了找到一些解决问题的方法，因此提出的问题可能会比较拙略与浅薄，当然也有”应付“作业的嫌疑，还是希望邹老师海涵。接下来我也会按照作业的要求提出五个问题，并且简单聊聊我的看法。

第一次作业 #

“做中学”放在教学场景下是否合适？ #

上下文来源 #

在第一版前言中，邹老师提到他总结的”在16周内让同学们通过‘做中学（Learning by Doing）’掌握使用的软件工程技术的教学计划“，我感到十分认同。但是对于正常的学习计划，”两级分化“问题就是一个常见的现象，课程后期出现"头部学生冲刺/底部学生搁浅"的并行断层在我看来，对底部学生来说是一个致命的问题，而”做中学“加剧了这种现象。以我为例，我从12岁接触编程，刚开始学的是VB，随后为了课程需要以及单片机学习了C语言，在之后使用PLC学会了梯形图编程，Python爆火后又学习了Python。在这期间断断续续为了一些需求也学过Go语言和R语言。对于现在的我来说，能做到独立编程的语言也就只有梯形图和Python，前者是比赛需要，后者是项目需要。我的经历深刻的诠释了”做中学“，对于Python来说，我也不能保证可以什么程序都写得出来，做着项目，遇到了问题，把它解决了才能学到一些”实实在在“的知识。因此我对邹老师说的”做中学“感到非常的认同。

但是问题来了，前文也说了，上了邹老师的课，我才开始慢慢摸索Git流程，在此过程中难免遇到问题，不仅仅是与Git相关，也可能是其他的技术性问题。在此过程中的”信心与进度同步下滑“是非常致命了，能坚持下来，一是Git流程的确不是特别难以理解的事情，二是对我来说可能遇到一些技术瓶颈已经习以为常。但这个现象也引起了我的思考。

我的思考 #

如果把这门课比作一条16周的跑道，“做中学”听起来像是对所有人同时发令：预备——跑！

现实却是，有人脚踩专业跑鞋，有人穿着拖鞋，还有人刚找到起跑线。基础差距在开学就凝固成统计意义上的“两极”，再往后，头部同学只会越跑越轻，底部同学只会越跑越沉。

我感觉问题不在“做中学”本身，而在默认所有人都已完成热身。断层根源是"统一节奏"假设：教学日历对所有同学都是一样的，默认所有人已完成热身。头部同学把课程任务当跳板，快速进入学习工程实例；底部同学连续触发failed build，信心与进度双下滑，形成"信心缺口→不敢提交→得不到反馈→更不敢提交"的死结。因此我发出了疑问做中学”放在教学场景下是否合适？

我感觉教学的终点不应该统一，更应该关注学生在这个过程中提升了多少。当然，对于一个成熟的工程师“做中学”无疑是最好的学习方式。

专与精是否对立？ #

上下文来源 #

第三章，”专与精的关系“提到了两个例子”街头卖艺的单人乐队“与”只研习某一乐器的乐手“，用来类比全栈和专精工程师。看到两个反问句“你愿意花钱听哪种演奏呢?“”你会让他走上单人乐队的道路么?”，我觉得邹老师的意思是希望团队合作，做个专精的人。但是读到后面，又有一些不一样的想法。邹老师在后文又搬出“交响乐队”的比喻：作曲家一个人能把所有声部写齐，演出时却绝不会让小提琴手去敲大鼓。我这才咂摸出他的潜台词——“全栈”是设计阶段的鸟瞰图，“专精”是交付阶段的施工图；前者防接口爆炸，后者保性能爆表。于是“你愿意听哪种演奏”其实是在问：你是想要一张总谱，还是想要一段能让人起鸡皮疙瘩的solo？

我的思考 #

我认为专与精是技能演进的两个阶段，逻辑顺序上先广后深，先通过“全栈”式实践建立系统视角，再聚焦于单一模块持续投入，形成高壁垒的专业能力。广度确保接口理解、协作语言和风险控制，深度带来性能、可靠性和不可替代性；前者防止孤岛式开发，后者避免浮于表面。教学场景里把周期划分为“横向贯通+纵向深耕+交叉验证”三段，可在时间维度上兼顾二者：前期全员走完需求-开发-测试-上线全流程，中期自选模块指标化冲刺，后期强制集成与回溯，使深度成果被系统检验，也让广度知识有落地支点。二者循环放大，构成可持续的成长路径。

代码规范是否会限制程序员的创造力？ #

上下文来源 #

第四章，开头的第一节提到了代码的规范，这也是我上这门课想要学习的主要东西，但是这也使得我想起我在写代码时，希望去规范自己的代码，总是拖慢我的进度，越规范越卡顿。但是读到了后边“代码复审”时，的确“规范是给读代码的人看的，而那个人大概率是三个月后的你自己。”

我的思考 #

规范不是镣铐，而是“把个人灵感转译成他人可感知的信号协议”；没有协议，再精彩的脑洞也传不到下一棒。规范与创造力不是零和，而是“采样精度”与“信号带宽”的关系。

早期写原型，我允许自己用“非法”变量名、Tab 混空格，让思维以最大带宽喷涌；一旦算法跑通，立即进入“重采样”阶段：把变量语义化、拆函数、补断言，把高频噪声折进低通滤波器——这时候规范反而像 24-bit 的 ADC，把原来粗糙的模拟信号升格成可复用、可迭代的数字资产。没有这一步，下一次灵感只能重新从噪声里刨信号，边际成本反而更高。

敏捷的尽头是“敏捷免疫”？ #

上下文来源 #

第六章章末，邹老师用“便衣警察”的比喻回应“名分”的问题：便衣警察本来高效低调，一旦被要求统一穿制服、挂警徽，就失去灵活穿巷的优势。这里不是给敏捷发“名分”，而是提醒——别把敏捷这身“便衣”升级成“制服”，否则它就丧失混在人群里随时变向的能力。

我的思考 #

敏捷的尽头不是更多敏捷，而是不再需要谈敏捷。

当组织把站会、故事点、Sprint 写进制度并打上考核钢印，任何偏离都被视为“违规”，流程就产生了自我保护的抗体。打破它的唯一办法是制度化地自我拆台：定期让团队脱离 Scrum，用任何方法只要交付可工作的软件，并把数据与留守组并排公开；若结果更好，就继续剥离仪式，直到“敏捷”回归形容词，成为可随时穿脱的工作习惯，而非固定制服。

伦理责任：底线还是天花板？ #

上下文来源 #

17.8节提到职业道德，书中给出IEEE/ACM《软件工程师职业道德规范和标准》把“公众利益”写进原则 1，并在原则 3 给出 15 条细则：从“让用户了解重大折衷”到“只按被授权方式使用数据”，再到“维护数据完整性”。对于我来说，科研期间听到最多的也是工程师的伦理和道德，这引起了我的思考。

我的思考 #

伦理责任对软件工程师而言，既是约束，也是护栏；它限制了一时的技术冲动，却换来更长久的公众信任。没有它，代码可能沦为效率的帮凶；只有把它写进需求、写进测试、写进每一次上线决策，才能让“造福社会”从愿景变成可验证的事实。规范与自由并非零和，前者划定底线，后者才有安全的空间去创新；在底线之上追求极致，才是职业尊严的真正来源。

小结 #

读的很仓促，最后两个问题也是匆匆扫过书后从脑子里临时蹦出来的，简单的讨论一下。