我个人觉得，架构设计开发最重要的就是两个原则：“自顶向下”原则和“MVP”原则。

自顶向下原则

先来谈一下“自顶向下”原则。多数程序员听到“自顶向下”这个原则时，都不会觉着陌生，但在工作中，我却发现很多初级程序员，都会一头扎进细节出不来，最终导致系统设计混乱以及延误工期。

那么符合“自顶向下”原则的做法是什么？

首先从最顶层需求开始分析，然后分析系统与外界的交互，进而分析系统内部所包括的组件，最后对各个组件进行分析得到类。

这中间每个步骤的产出都是一个文档，你去用这些文档去和上司、同事进行讨论，最终得到一个合适的设计文档，然后才应该去写代码。

为什么要自顶向下开发？

首先，就是自顶向下能帮我们明确系统设计的目标，把握全局，不至于走偏。

其次，也是最重要的因素，就是自顶向下原则方便我们修改对系统的认知。

没有人能够在开发前就对一个复杂系统有着全面且清晰的认知，我们每个人对系统的认知都是片面的，都是在盲人摸象。所以我们要和同事讨论、要和上级讨论、要和客户讨论，来尽量让我们对系统的理解更全面。

而讨论是需要一个介质的，否则就变成了空谈。这个介质最重要的特性是要易于修改，其次就是能较为清晰形象的表达系统，降低讨论的认知负担。

代码对系统的表达能力最强，但难以修改；语言最易于修改（说完就不认账:) ），但无法清晰表达系统。因此，相比较而言，我觉着手写的架构草图就是最合适的介质。

首先，它真的很容易修改，橡皮擦一擦就可以改了；其次，架构图也符合多数人认知一个复杂系统的习惯，很直观简单。

当然，我此处说的架构草图并非是遵从所谓的UML标准的图，只要你的图本身没歧义，不会对讨论者造成误导，怎样画都没问题。

通常来说，开发一个系统，我们要把50%-70%的时间花费在设计、讨论和文档上。

MVP原则

然后再来谈谈MVP原则。MVP，Minimum Viable Product，最小可行产品，指的就是先造出一个可跑通的产品，然后再考虑后续优化。

为什么要使用MVP原则？因为“过早优化是万恶之源”。

人人都知道“过早优化是万物之源”，但到底哪些优化是“过早优化”呢？

以我个人的观点，整个开发过程的前半程所作的绝大多数优化都可以看作是过早优化，无论这优化是为了性能，还是可读性。

这是因为前半程，我们主要关注的应该是开发过程中是否出现了没考虑到的风险点。

自顶向下原则只能保证我们对系统有了比较清晰的认知，但它并不能保证我们的认知是全面且无误的，总会有一些额外因素，只有到了真正去做的时候才能考虑到。

而这些额外因素出现的时机是不确定的，因此，如果在开发过程的前半程就浪费了大量时间在优化上，导致原本的预期赶不上，那整体项目进度就变得不可控了。

作为开发者，我们的首要优先级应该是尽量保证系统能跑，然后再去决定跑的够不够好，够不够快。（当然，如果deadline紧张到连基本功能都无法保证，那就是“此天之亡我，非战之罪也”）

除此之外，前半程的优化，大概率都不是最终的优化方案。

比如，你可能开始开发时遇到一些冗余代码，想要抽成一个函数把他们合并，然后你做了，做得很好。但后来开发时，你又发现有类似的冗余代码，但却无法利用你之前优化所作的抽象。这个时候，你又得花时间去做一套新的抽象，这中间的时间就被浪费了。

这种现象会出现，就是因为我们在还没有对系统有较全面了解的时候，就去做了优化，这些优化就就属于过早优化（英文即premature optimization，未成熟的优化）。

那么什么时候我们对系统有了较全面的了解呢？就是开发过程的后半段。这时功能基本完善，对系统也较为理解，此时优化就相对而言更具性价比。

当然，不做过早优化不意味着不做优化。如果你觉着这些优化很快就能完成，且影响范围较小，那么立刻去做也是一个优秀程序员应有的素养。还有些优化属于不做不行，你不做就会导致后续的开发受到影响，这种优化我也建议早做早好。

总结

总的来说，我们先按照自顶向下原则讨论出设计方案，然后基于MVP原则去逐步按照设计去开发，这就是一套比较完整的开发方法论。