[l.1] 个人作业：阅读与提问

1：关于“PM是否应当具备一定的技术能力”

​ 本书第九章界定了PM的各种任务，负责沟通客户，组织团队。

​ 程序员和项目经理之间的矛盾一直是互联网行业中经常被讨论的话题。在现实工作中，项目经理通常不直接参与核心开发，对具体代码实现了解有限，因此有时会提出不太合理的需求，或者对项目周期做出不准确的预估。

​ 针对这一问题，常有人提出一种看似理想的解决方案：让PM具备一定的软件开发能力，甚至参与部分编码工作，以减少需求理解偏差和时间评估失误。从直觉上看，这似乎可以缓解程序员与PM之间的矛盾。

​ 但仔细想，这种方案未必能够真正解决问题。首先，即使是直接参与开发的一线程序员，在需求评估和开发周期预测上也经常出现偏差，因此要求PM在有限精力下准确判断技术复杂度，其实同样困难。其次，同时具备优秀沟通能力、敏锐市场洞察力以及扎实开发能力的人才本身就十分稀缺，如果把这些能力都集中到PM这一角色上，现实中往往很难实现。

​ 我们是不是可以认为，相比单纯提高PM的技术背景，我们更应该去探索一种更加有效的协作机制，使需求决策、技术评估和项目规划能够在团队内部更合理地分工与协作，从而减少这一长期存在的角色矛盾。

2：AI时代下软件工程师的技能点是否已经变化

​ 本书的第三章中给出了一个观点：

​ 诚然，对于一个计算机从业者来说，熟练掌握自己工作中主要的技术栈是必须的，但是如今AI的发展，让更多的专项程序员有了“通才”的能力：比如一个熟练SpringBoot技术栈的程序员可以仅仅通过学习java过程中学习到的计算机基础知识和语言功底，在AI的帮助下快速迭代出一个可用的gin后端项目甚至前端移动端的项目，其中简单的语言等低层次问题仅仅需要简单学习即可解决。

​ 这时我们是不是可以认为，在AI时代，那些低层次问题是否显得更加微薄；对于我们开发者来说，简单的语言学习和锻炼只是掌握高层次想法的手段而非聚焦于具体的业务本身，而我们只需要掌握几项核心的专精底层知识和快速学习上手项目的能力。我们可以想象一个场景，对于业务中较为少见的AI难以解决的如jvm底层问题，可以由专攻java的程序员解决，而对于常见的crud等工作，则是每个开发者都能快速胜任的任务。

3：敏捷开发和软件行业是否完全适配

​ 书的第六章对敏捷开发（Agile）进行了较为系统的介绍，并在一定程度上将其视为适应当代软件工程快速迭代需求的重要开发方法。然而，从近年来互联网行业的大型事故频发的情况来看，敏捷开发是否能够在复杂的商业环境中稳定发挥作用，仍值得进一步讨论，我们能否找到一个更适合互联网行业的开发模式。

​ 追溯敏捷开发的思想来源，可以发现其循环迭代的理念与20世纪中期提出的PDCA循环具有明显的相似性。然而，PDCA最初主要面向的是传统工业生产体系。在传统工业中，生产流程通常具有明确而稳定的计划，并依赖高度机械化的流水线，同时稳定的工业标准让测试十分容易。

​ 相比之下，软件工程的特点则显得更加复杂。首先，软件需求变更成为常态。其次，软件开发高度依赖程序员劳动，其编码时间都具有较大的不确定性。在理论上，敏捷开发通过短周期迭代和持续反馈来应对这些不确定性，但在实际项目中，需求变更频繁、任务常态延期，测试难以覆盖，PDCA四个字母没有一个能够有效执行。

​ 此外，敏捷开发中强调的每日立会在实践中也可能逐渐形式化。例如，当一名开发者报告“昨天完成了某项任务”“今天计划继续某项功能开发”时，其他开发者更多只会觉得“这和我有什么关系”，在说“遇到了某段代码的问题”时，其他开发者也只会觉得“这块代码我又不熟，难道指望我来帮你解决吗”。我们更应该鼓励同事间有问题随时找对应的人交流，而让所有人每天浪费30分钟“罚站”。

​ 有人可能会说：“这是因为敏捷开发的内容没有落实到位，执行不到位不代表方法有问题。”但是，我们得考虑到企业领导的项目必然有KPI等绩效机制和惩罚机制。敏捷开发提供了一个非常理想的团队合作方式，但是它真的适用于企业吗？当软件出现问题，最后是需求不合理，还是程序员能力不过关，还是任务分配不合理，这些问题在快速进行的敏捷开发中如何找到责任人？更何况如果敏捷开发这么理想，为什么执行中却往往不到位，是否是这样一个基于管理，过于理想的开发模式本身就不合理呢？

4：AI时代下，我们应该如何在快速迭代和可拓展性中取舍

​ 本书的3.2章中把过早扩大化/泛化视为技术的常见误区，这是没有问题的。然而，在AI技术可能进一步发展的背景下，开发人员适度进行“提前的抽象或泛化设计”，是否会变得更有意义，或许值得重新思考。

​ 在软件工程实践中，行业往往把快速迭代和快速产出视为核心目标，这确实能够帮助产品尽快进入市场并获得反馈。但与此同时，这种开发节奏也可能在一定程度上限制软件在长期发展中的潜力。例如，为了追求短期效率而忽视系统结构的可扩展性，可能会在未来带来较高的重构成本。

​ 尤其是在AI技术快速发展的情况下，代码生成和开发效率可能会进一步提高，“快速产出”本身将不再像过去那样困难。在这种背景下，一个清晰、可扩展且具有长期可持续性的系统架构反而可能变得更加重要。因此，相比完全避免“过早泛化”，或许更值得讨论的问题是：在什么程度上进行适度的前瞻性设计，才能在保持开发效率的同时，为系统未来的发展留下足够空间。

5：当软件工程越来越多地走进传统行业，传统的发布方式是否应当更新

​ 本书的第15讲系统地讲述了在软件工程行业，项目的发布过程。

​ 在传统的软件行业中，由于软件天然具有容易出现 bug，同时修复成本低的特点，项目通常会经历 alpha、beta、RC 等多个测试版本阶段。在正式版本发布之后，也常常会通过类似 2.1.2、2.1.5 fix 这样的补丁版本来持续修复问题。

​ 这种发布模式在互联网软件中已经被广泛接受。然而，它在很大程度上也依赖于企业自身的测试自觉性：测试流程往往缺乏统一标准，执行质量也参差不齐。因此，互联网行业时常会出现由于某些细小错误而引发的大规模事故，例如Cloudflare曾经发生过的多次服务故障，甚至一度影响到相当大范围的互联网服务。

​ 但随着软件工程逐渐深入到更多传统行业，例如智能汽车、医疗设备等领域，情况正在发生变化。在这些行业中，一个看似微小的软件缺陷都有可能带来严重后果，甚至直接关系到人的生命安全。相比之下，这类风险显然远比单纯的互联网服务中断更为严峻。

​ 因此，当软件系统开始承担越来越多关键基础设施功能时，我们是否仍然可以沿用过去那种“出现问题再发布补丁修复”的思维来进行软件工程实践？在这些高风险领域中，软件发布流程是否应该引入更严格的测试标准、审查机制甚至行业监管？这一点或许值得软件工程领域进一步思考。