切换模式
高可用性模块架构设计原则1
乔布斯的fan
百度后台开发，腾讯后台开发
- 开发正确的原型(BUILD THE RIGHT KIND OF PROTOTYPE )，有两种原型：一次性（throwaway）原型和演进式（evolutionary）原型。一次性原型用快速而粗糙的方式构建，交给客户以获得反馈，在得到期待的信息后即被废弃。获得的信息被整理进需求规格说明，用于正规的产品开发。演进式原型用高质量的方式构建，交给客户以获得反馈，获得期待的信息便进行修改，以更加贴近用户的需求。重复此过程，直到产品收敛到所期望的样子。一次性原型应该在关键需求特性没有很好理解时使用。演进式原型应该在关键特性已被充分理解，但很多其他需求特性没被充分理解时使用。如果对大多数功能都不了解，则首先构建一个一次性原型，然后从零开始构建一个演进式原型。
- 构建合适功能的原型(BUILD THE RIGHT FEATURES INTO A PROTOTYPE )，当建立一次性原型时，只需要开发那些没有被充分理解的特性。如果你开发已充分理解的特性，最终除了浪费资源外，将一无所获。当建立演进式原型（原则13）时，要优先开发那些已经被充分理解的特性。（注意，它们可能已经被充分理解，因为之前已使用一次性原型进行验证）你的希望是，通过体验这些特性，用户能更好地确定其它需求。如果你基于模糊的需求(高质量的)开发了一个演进式原型，一旦需求搞错了，你将不得不抛弃这个高质量的软件，并且浪费了资源。
- 渐进地扩展系统(GROW SYSTEMS INCREMENTALLY )，渐进地扩展系统，是降低软件开发风险的最有效方法之一。从一个小的可用系统开始，只实现少数功能。然后逐步扩展，覆盖越来越多的最终功能子集。这样做的好处是：（1）降低每次开发的风险；（2）看到一个产品版本，通常可以帮助用户想象出他们想要的其他功能。这样做的缺点是：如果过早选择了一个不合适的系统架构，则可能需要全面的重新设计、才能适应后续的变更。在开始增量开发之前，开发一次性原型（原则11，12和13），可以降低这种风险。
- 不同的阶段，使用不同的语言(DIFFERENT LANGUAGES FOR DIFFERENT PHASES)，业界对“简单方法解决复杂问题”的永恒渴望（原则19），促使许多人宣称：最佳的软件开发方法，是在整个开发生命周期中、使用相同的符号表达方法。既然在任何其他工程领域都并非如此，为什么在软件工程领域会是这样？在不同的设计活动中，电力工程师会使用不同的表达方法：方框图、电路图、逻辑图、时序图、状态转换表、柱状图等。这些表达方法为我们提供了在思维中可操纵的模型。使用越多的符号、越丰富多样的表达方式，我们就越能更好地对开发中的产品进行可视化。除非对所有阶段都是最优选择，否则为什么软件工程师想要将Ada用于需求、设计和代码？除非对所有阶段都是最优选择，否则为什么要在所有阶段都使用“面向对象”的方法？
发布于 2021-02-21 20:21
数学
计算机科学