架构是什么
按照Bob大叔的说法，所谓架构就是“用最小的人力成本来满足构建和维护系统需求”的设计行为。
所谓软件架构，就是你希望在项目一开始就能做对，但是却不一定能够做得对的决策的集合。
从人力成本的角度来定义架构，所以，架构是否合理，完全取决于是否节省人力，便于维护、扩展。
第一性原理：技术是为商业价值和社会价值服务的。从这个原则出发，架构就是确保业务 短期快速发展、中期可延展、长期稳定，且低成本。在业务视角，对架构提出的要求就是“既要又要还要…” 架构，绝对不是“炫技”，现在大公司晋升汇报，都会需要讲技术能力，为了试点新技术，而强加给业务迭代，且往往业务和产品很难发现和知晓，这是非常本末倒置的行为。
架构的衡量
一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直都能维持这样的低成本，那么这个系统的设计就是优良的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的。就这么简单。
现代的goto
大家对结构化编程的一般理解是，由if-else、switch-case之类的语句组织程序代码的编程方式，它杜绝了goto导致的混乱。但是从更深的层次上看，它也是一种设计范式，避免随意使用goto，使用if-else、switch-case之类控制语句和函数、子函数组织起来的程序代码，可以保证程序的结构是清楚的，自顶向下层层细化，消灭了杂错，杜绝了混淆。
联系如今的分布式系统，我们在设计的时候，真的能够做到自顶向下层层细化吗？有多少次，我看到的系统设计图里，根本没有“层次”的概念，各个模块没有一致的层次划分，与子系统交互的不是子系统，而是一盘散沙式的接口，甚至接口之间随意互调、关系乱成一团麻的情况也时常出现，带来的就是维护和调试的噩梦。吹散历史的迷雾，不正是古老的goto陷阱的再现吗？
接口的设计
有多少次，我看到接口的设计非常随意，接口不是基于行为而是基于特定场景的实现，没有做适当的抽象，也没有为未来预留空间，直接导致契约僵硬死板。每新增一种终端呈现形式，整个内容生产流程就要大动干戈，这样的例子并不罕见。抹去历史的尘埃，这不正是“多态”出现之前的困境吗？
接口定义需要基于行为不可以基于场景设计，否则接口会变得杂乱无章
接口设计是站在自身角度，明确领域 应用定位，明确接口方法提供的能力，而不是基于需求方的需求（场景）
软件架构是系统设计过程中的重要设计决定的集合，可以通过变更成本来衡量每个设计决定的重要程度。
一个好的架构，不仅要在某一特定时刻满足软件用户、开发者和所有者的需求，更要在一段时间内持续满足他们的后续需求。如果你觉得好架构的成本太高，那你可以试试选择差的架构加上返工重来的成本。
某个系统因为其组件错综复杂，相互耦合紧密，而导致不管多么小的改动都需要数周的恶战才能完成。又或是某个系统中到处充满了腐朽的设计和连篇累牍的恶心代码，处处都是障碍。再或者，你有没有见过哪个系统的设计如此之差，让整个团队的士气低落，用户天天痛苦，项目经理们手足无措？你有没有见过某个软件系统因其架构腐朽不堪，而导致团队流失，部门解散，甚至公司倒闭？作为一名程序员，你在编程时体会过那种生不如死的感觉吗？
哈哈，深有体会，经历过这种痛苦之后，才会想着改变，想寻求更好的方法
相信每个写代码的人都知道这些编码的准则，但是大部分人包括我自己在写代码的时候可能早就把这些代码准则抛之脑后了，可能因为各种原因，工期紧张或者就是自己懒惰的思想作怪，于是代码就越写越烂了，有一天连自己也懒得看这玩意了，当需求改动的时候就会变成所有人都痛苦的时候，所以在写代码的时候花一点时间是琢磨一下准备是非常有必要的，这些都是前人总结出来经验。