StreamSparkAI

概览/核心摘要

本总结深入剖析了软件开发的核心原则：“Make it Work, Make it Right, Make it Fast”，并强调其严格的先后顺序。这一原则指出，软件开发的首要任务是让产品能够运行起来（Make it Work），因为一个未被实际使用过的软件毫无价值。在此基础上，才能逐步优化使其“正确”（Make it Right），而“正确”并非一成不变的常量，它受限于开发者的认知、行业发展趋势以及解决方案的相对性。最后，当软件已能正常运行且架构合理时，才考虑提升其速度和性能（Make it Fast），但这一阶段对于大多数软件而言并非必需，且外部优化往往比代码层面的优化更有效。该原则旨在纠正软件开发中常见的“完美主义”误区，鼓励开发者以阶段性、动态的视角看待项目，避免陷入无休止的重构和优化，从而确保项目能够真正交付并投入使用。它将软件开发比作马斯洛需求理论，将“Make it Work”视为生存需求，“Make it Right”视为生活需求，而“Make it Fast”则是更高层次的升华。

软件开发的第一原则：Make it Work

软件开发的首要且最重要的原则是“Make it Work”（让它运行起来）。这意味着首先要确保软件能够实现其基本功能并实际运行。

• 核心观点：
  • 正如发言人所引用的名言：“make it work, make it right and make it fast。”其真正的重点在于“work, right, fast”的先后顺序。
  • 准确的表达应是：“make it work first, then make it right, and finally make it fast。”
• 未完成软件的无意义性：
  • 许多开发者，包括转录中提到的大学生，常陷入无休止的重构和优化，导致项目迟迟无法完成。
  • 尽管架构设计和代码质量可能因此提高，但软件并未因此更接近终点，反而“越走越远了”。
  • 发言人强调：“一个没有实际被使用过的软件，他压根就没有活过。”
  • 未完成或未上线的软件，无论其架构多好、代码多美、性能多强大，都“是空谈，毫无意义”。
  • 如果目的仅为简历上列出技术名词，不如直接背诵八股文，因为没有实际运行，就无法真正体验技术的优缺点。
• 基础性：
  • 只有在“Make it Work”的基础上，才有资格讨论后续的“Make it Right”和“Make it Fast”。

理解“Make it Right”的复杂性

在软件能够运行之后，下一个阶段是“Make it Right”（让它正确）。然而，“正确”并非一个固定不变的常量，而是一个动态的变量。

• “正确”的非恒定性：
  • 发言人指出，试图一开始就“一步直达终点”直接做到“正确”是困难的，就像“吃七个包子就能饱，为什么不直接吃第七个呢？”
  • “正确的做法从来都不是一个constant，它不是一个常量，而是一个变量。”
• 影响“正确”取值的三个因素：
  1. 认知范围： 随着开发者学习新理论和新思路，对“正确”的理解会不断刷新。
     • 例如，从直连数据库到使用连接池（connection pool），再到ORM，以及使用Redis进行缓存优化。
  2. 行业发展： 行业内的“state of the art”（当前最佳实践）是一个渐变过程，而非一夜之间形成。
     • 例如，Linux成为主流操作系统是一个逐步被不同社区（学术界、开源界、业界）接纳的过程。
     • 在竞争激烈的领域（如前端生态），同一时代可能有多个并驾齐驱的技术，一个大企业的背书或一个大版本发布都可能扭转局势。
  3. 正确的相对性： 软件开发中不存在绝对正确或绝对错误的解决方案（排除完全无法运行的情况）。
     • 发言人建议不应使用“right and wrong”，而应使用“better”和“worse”（而非“best”和“worst”），因为现实中追求的是“足够好”而非完美。
     • 追求完美会拖累解决其他问题的进度。
• 参照系：
  • “正确”是一个时间和空间上的相对概念，它需要一个参照系才能成立，而这个参照系的原点就是“Make it Work”。

“Make it Fast”：何时以及为何不常达到

“Make it Fast”（让它快速）是软件开发的第三个阶段，但对于大多数软件而言，这一阶段往往不会被达到。

• 非普遍需求：
  • 高频、高速、高并发的软件并非普遍现象。
  • 在大多数软件应用场景中，用户对响应速度和运行效率的感知是微妙的。
  • 从10秒优化到1秒的提升是显而易见的，但从1秒优化到900毫秒的提升，用户通常感觉不明显。
  • 只要没有指数级时间复杂度的代码，优化通常只在毫秒级别。
• 代码外优化更有效：
  • 在许多场景下，代码层面的优化效果远不如代码外的安排。
  • 例如，在互联网场景中，一个好的CDN服务商或符合用户分布规律的部署策略，对用户体验的优化效果远高于代码层面的优化。
• 优先级问题：
  • 在软件项目推进过程中，更高优先级的任务（如bug修复、新功能开发、旧功能改造以支持新功能）会不断插入。
  • 性能优化任务很容易被长期搁置。
• “Make it Fast”的价值体现：
  • 只有当软件真正运行起来，并拥有足够优秀的架构基础后，深入的性能优化才有价值。
  • 此时，可以探索更深层次的计算机技术奥秘，例如：
    • 链表和数组的性能局限与优点（第五期视频）。
    • 技术框架抽象层带来的额外负担（第六期视频）。
    • 底层原理带来的数量级优化效果（第十期视频）。
    • 通过减少服务间交流成本实现高速架构（第十三期视频）。
    • 正则表达式的性能缺陷及替代方案（第十五期视频）。
    • 文本作为数据结构的缺点和二进制格式的应用场景（第十八期视频）。
  • 如果基础不稳固，研究这些细节就像“研究回字的4种写法”，毫无意义。

总结与启示

• 马斯洛需求理论类比：
  • “Make it Work”被比作生存需求。
  • “Make it Right”被比作生活需求。
  • “Make it Fast”被比作人生的升华。
• 纠正误区：
  • 这一原则的最大价值在于清晰地展现了软件开发“是一种具有阶段性，是一个动态过程”的特性。
  • 它纠正了许多理论追求“最好结局”的倾向，避免开发者陷入“一锤子买卖”的错觉，认为“要做就做到最好才能拿出手”，结果导致“永远都出不了手”。
• 核心结论：
  • 软件开发不是追求一蹴而就的完美，而是要分阶段、动态地推进。首先让它跑起来，然后逐步优化使其合理，最后在有必要时再追求极致的速度。这种务实的态度能够帮助开发者更有效地交付项目。