[I.1] 个人作业：阅读和提问

《构建之法》阅读提问与思考

项目	内容
这个作业属于哪个课程	课程社区链接
这个作业的要求在哪里	作业要求链接
我在这个课程的目标是	掌握现代软件工程方法论，提升团队协作和工程化能力
这个作业在哪个具体方面帮助我实现目标	通过批判性阅读培养技术洞察力，理解理论到实践的转化挑战

---

问题一：敏捷开发是否过度理想化？

章节依据：第2章 个人技术与流程
原文引用：

"结对编程让两个人共同承担责任...几乎所有的结对编程实践者都享受这个过程"

我的观察：

• GitHub 2022开发者报告显示，78%的开发者更倾向独立编码
• 现实中常见异步协作模式（如PR评审）取代实时结对
• 技术社区争议：如《Pair Programming is Not a Panacea》指出效率损失问题

困惑：
教材强调结对编程的普适优势，但实践中面临：

1. 认知负荷差异导致的效率瓶颈
2. 远程工作场景的实时协作障碍
3. 个性冲突对生产力的影响
   核心疑问：敏捷方法论是否需要根据团队规模/领域特性降级实施？

---

问题二：技术债量化是否存在可行性陷阱？

章节依据：第8章 需求分析
原文观点：

"技术债务需要定期偿还...否则利息会越来越高"

实践矛盾：

• Martin Fowler在《Technical Debt Quadrant》中区分故意/无意识债务
• 实际项目常出现：
  • 业务压力下被迫累积债务（如电商大促前）
  • 缺乏统一度量标准（代码复杂度≠债务价值）

反对理由：
将技术债类比金融债务存在本质差异：

1. 债务价值随时间非线性变化（某些债务可能自然消亡）
2. 缺乏利息计算公式（如：10K行烂代码的维护成本如何预测？）
   质疑：是否应建立技术债的熵增模型而非金融模型？

---

问题三：创新者的窘境在软件领域是否失效？

章节依据：第16章 IT行业的创新
案例对比：

教材案例	现代案例
诺基亚功能机衰落	云原生颠覆传统架构
瀑布模型被敏捷取代	Serverless重构开发范式

新现象：

• AWS Lambda（2014）在6年内获百万用户，颠覆应用部署模式
• 开源社区创新速度超越企业研发（如Kubernetes源自Google内部项目捐赠）

思考：
教材描述的创新周期（5-10年）在AI时代压缩至18个月（参考：GPT模型迭代速度）。核心矛盾：当技术创新呈现指数级增长时，书中提到的创新管理方法论是否需要根本性重构？

---

问题四：代码审查的自动化边界在哪里？

章节依据：第4章 两人合作
原文建议：

"代码复审能发现80%以上的错误"

技术演进：

• AI代码工具现状：
  • GitHub Copilot (2021) 自动补全代码
  • SonarQube 实现静态分析自动化
  • Meta研发Getafix自动修复BUG

经验冲突：
在参与Apache项目时发现：

1. 人工审查更擅长发现架构缺陷（如循环依赖）
2. 自动化工具对业务逻辑误判率高
   关键提问：当AI审查覆盖率>70%时，教材推荐的审查流程是否需要重新定义“人的价值”？

---

问题五：软件估算的本质是科学还是玄学？

章节依据：第7章 项目管理
方法论争议：
教材推荐：功能点估算、COCOMO模型
现实困境：

• 2023 Standish Group报告显示68%项目仍超期
• 谷歌工程实践揭示：估算误差常达200%-400%

反常识案例：

• SpaceX星舰开发采用“测试直至失败”模式，放弃传统估算
• 特斯拉自动驾驶迭代通过实时数据驱动取代里程碑计划

根本质疑：在云计算/持续交付普及的今天，基于“预定义范围”的估算体系是否违背快速迭代原则？是否应转向基于吞吐量（Throughput）的流动式规划？