遥不可及|每个架构师都在研究的康威定律，程序员进阶路上，你思考过吗？( 二 ) 背景今天的分享主要来自我之前的工作经

翻译为中文就是，架构表示对一个系统的成型起关键作用的设计决策，架构定系统基本就成型了，这里的关键性可以由变化的成本来决定。这句话是Grady Booch说的，他是UML的创始人之一。
进一步展开讲，架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能地小。
我刚入软件开发这个行业之出，谈的架构主要是性能，高可用等等。现在，见过无数遗留系统，特别是国内企业IT的现状，无数耦合性系统的遗留系统，不良的架构象手铐一样牢牢地限制住业务，升级替换成本非常巨大，所以我更加关注可理解，可维护性，可扩展性，成本。我想补充一句，创业公司创业之初获得好的架构师或技术CTO非常重要。
架构的迭代和演化性我是属于老一代的架构师， 99年参加工作。职业初学了很多RUP ，统一软件过程的理念。 RUP的理念对我的架构有很深的影响， RUP总结起来就是三个特点：

用例和风险驱动Use Case and risk driven
架构中心Architecture centric
迭代和增量Iterative and incremental

RUP很注重架构，提倡以架构和风险驱动，该开始一定要做端到端的原型prototype；通过压测验证架构可行性，然后在原型基础上持续迭代和增量式开发，开发->测试->调整架构->开发，循环，如下图所示：

从上图可以看出架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速的反馈，产品不满足最终用户需求，继续看下面两个图：

第一个图是讲最小可用产品（Minimum Viable Product ，MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。
另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的
给大家推荐两篇不错的微信文章（微信不能插入链接，根据题目Google下即可）：