第一部分 认识架构
第1章 生命周期
生命周期指一个事物的出生、长大、衰老、消亡的过程。
生命周期里面包含有各种活动，这些活动是推进这个生命周期的必要因素，并且这些活动之间有时间上的推进关系。
生命周期总是有一个主体，所以，更多的是明确指出某某的生命周期。
一个生命周期里面的活动可以进行拆分，拆分的原则就是形成若干个新出的生命周期，每个新的生命周期都有自己的主体。
拆分之后主题不变的子生命周期，被称为核心生命周期。主体改变的子生命周期，被称为非核心生命周期。
每个主体的生命周期活动的变化都积累在该主体本身，这就是内聚。内聚由主体和生命周期两个元素构成。
在把一个大的生命周期拆分为多个小的生命周期之后，核心生命周期活动的执行都严格地在时间上连续。而非核心生命周期的管理，则围绕着核心生命周期形成了一个树状结构。随着大的生命周期的拆分，树在逐渐地长大。
拆分之前，生命周期内部的活动都是由该生命周期的主体来执行的。在拆分之后，核心生命周期还是由原生命周期的主体来执行，但是非核心生命周期的主体发生了变化。也就是说，生命周期的运营和执行产生了分离。
拆分自后，一个很有意思的情况出现了，本来必须由同一个主体在时间和空间上连续执行的事情，就可以解除空间上的限制，变成可以由不同主体来执行，但是，原主体生命周期执行上仍然保持时间上的连续。也就是说，空间上连续的限制可以通过拆分生命周期来打破，形成空间上并行和时间上穿行的状况。
比如，吃饭是人的核心生命周期，必须要自己执行，别人无法代替。为了完成吃饭这个生命周期活动，在没有产生社会分工之前，每个人都自己种粮，用自己种的粮食做饭吃，这个过程按照时间顺序连续发生。我们把这个过程拆分以后，发现里面只有吃是人类核心的生命周期活动，别人无法代替，必须自己执行，而其他生命活动都是为吃服务的。随着社会分工的发生，拆分出来种粮的生命周期管理，烧饭的生命周期管理等，可以交给其他人执行。人们可以通过购买粮食和请人烧饭来直接获取执行的结果，以推进自己吃饭的核心生命周期周期活动。这就了管理和执行的分离。
当启动一个核心生命周期的时候，必须把树上该节点的所有父生命周期启动才可以，也就是所谓的业务流程，因为大生命周期本身内部活动功能还是按照时间顺序连续发生的。
非核心生命周期处于一种服务的状态，要按需给出结果。执行时间足够短的可以在请求的时候实时给出结果，太长的则需要预先执行好，需要时直接给出结果。
当非核心生命周期拆分出来成为服务后，这个服务不再仅仅给一个人使用，而变成了所有人都能够共享。
非核心生命周期一旦拆分出来后，往往就变成了一个通用的服务，反而获得了更大的生命力，不再局限于原有的大生命周期。对于非核心生命周期的掌握，慢慢也就形成了一个个的职业。
而原有的大生命周期则变得更加精简，可以更加专注于自己的核心生命周期活动，以节省更多的时间。
第2章 时间
时间可以通过事务的变化体现，而生命周期变化体现的也就是时间。
过去的已过去，未来的还没来，只有当下的一刻才最真实的。
尽可能作出更多成就的办法，就是尽量做自己最擅长的事情，以期获得最大的产出。
第3章 为什么会产生架构
当每个人都必须自己完成所有活动必须的活动的时候，是没有架构的。一旦产生了分工，就把原来每个人所必须做的人类非核心生命周期工作，切分成由不同的人来分别完成，最后再通过交易，使得每个个体都拥有生活必需品，而不需要每个个体都做所有的事情，只需要每个个体都做好自己擅长的事情，并具备一定的交易能力即可。这样每个人为自己核心生命周期所花的时间就少得多了，有更多的时间来提升核心生命周期的质量，从而使生命的到了某种程度的延长。这实际上就形成了人来社会的架构。
第4章 什么是架构
架构产生的动力：
1）必须有人执行的工作；
2）每个人的时间有限；
3）对目标系统有更高的要求；
4）目标系统的复杂性使得当人完成这个系统时会受限于时间。
架构的思考来源于对生命周期的识别和拆分。
从架构本身来看，架构也是人来活动的一种分工，人类架构的体现就是组织架构。因此，架构也有其自身的生命周期，有其自身的规律。人类的架构总是在人类的业务遇到瓶颈的过程中产生，在瓶颈的解决中应用，在业务消亡时，他也就跟着消亡。
架构是对业务生命周期的拆分。
架构的生命周期可以被拆分为架构设计的生命周期和架构湿湿的生命周期，其中，架构设计的生命周期是为架构实施的生命周期服务的，因此，架构实施的生命周期是架构的核心生命周期。
架构设计的生命周期，主要工作就是研究业务本身的生命周期。然后再根据业务面对的问题，发现瓶颈，进行架构的拆分。拆分的原则是把非核心生命周期拆分出来，由不同的角色来负责，让人们可以并行工作。每个角色达到权责的对等，并形成不同的角色各自的激励机制。架构的目的并非产生在一个业务之外新的东西出来，只是为了让业务长得更加高大强壮，服务于更多的人。
架构实施的生命周期，则是为了把架构的拆分落实到组织架构上，让每个人能够按照架构的职责拆分，并行工作，执行各自的生命周期。这些角色按照树状架构协调互相之间的沟通，使得每个拆分出来的非核心生命周期的增长，都贡献给核心生命周期，同时自己也能够收益。
在架构落地之后，架构就具备了生命。人们在这个架构下有条不紊地协作，共同完成业务的核心目标。
第5章 架构和树
架构是顺应业务生命周期规律的一种拆分，这个拆分始终是围绕着业务的核心生命周期的。
第6章 概念
人类架构实际上解决的是人的问题，而概念是人互相沟通并认识这个世界的基础。
概念是解决问题的解决方案。比如，建筑解决的是“人需要独占的空间，并还能够比较方便地和外部世界沟通”的问题。
要做好架构，首先必须具备的能力就是要能够正确地认识概念，能够识别概念背后所代表的问题，找出核心生命周期。进而才能够认识目标领域所需要解决的问题，认识目标领域的核心生命周期，这样才能够为做好架构打好基础。
第7章 什么是抽象
要定义一个事物只能用这个事物独特的地方，也就是它的个性，而不是共性，而抽象恰恰主要关注在共性上，不具备这个能力。但要找出事物的个性，就必须要深入分析和理解这个事物的核心生命周期。核心生命周期明去了，事物的个性也就明确了。
要做好架构，首先要具备的能力是识别个性的能力，也就是发现问题（找到核心生命周期）的能力。做架构的人必须亲自体验业务，感受业务，才可能真正认识业务的个性，真正认识业务所面临的问题。在理解业务个性的基础上，才能够谈共性。
第8章 识别问题
当我们要解决一个问题的时候，一定要克服对时间的焦虑，耐心地先把问题搞清楚。
只有真正敢投入思考“这是谁的问题”，关心“真正问题是什么”的工程师，才有可能成长成为真正地架构师。
找出问题的主体，是做架构的首要问题。
发现问题永远比解决问题更加重要。
明白了问题的主体，人们才可能真正地认识问题是什么。
第9章 切分的原则
架构师要非常清楚，所有的拆分调整，都是对相关人的利益进行调整。
每个人的时间和能力都有限 ，不可能什么都懂，什么都会。因此，人们需要放弃自己一些不擅长的事情，用自己擅长生产的东西去换取别人擅长生产的东西。对一个人干所有的事情，分工的结果让大家都能够得到更多，也因此产生了一个互相依赖的社会。这就是人类社会自然而然产生的架构切分，背后的动力是人们对自己利益的渴望，对提高生命周期推进质量的追求。
如何在这个社会上立足，判断的标准就是如何提供更好更有质量的服务给这个社会。提供得到服务更多更好，就能够换取更多更好的生活必需品。
当人们认识到要主动去切分一个系统的时候，就不能忘掉利益这个原动力。所有的切分都不能违背这一点。
一旦确定了问题的主体，那么系统的利益相关人就确定了下来，那么，相关问题就会变成：1）某些利益相关人的时间或空间上的负载太重；2）某些利益相关人的权利和义务不对等。
利益相关人负载太重（时间上的负载太重）是导致切分的原因，权责不对等是切分不合理而导致的新问题。只有把负载太重的利益相关人在时间上连续的动作，切分成时间或空间上可以并行的工作，在时间或空间上横向扩展，让更多的人并行工作来提升产出。
切分的原则：1）被切分的生命周期，如果必须要生命周期的主体在连续的时间内持续执行，而且不能够被打断并且更换生命周期主体的话，就不能切分出去。2）每一个生命周期的负责人，对所负责生命周期的权利和义务必须是对等的；3）切分出来的生命周期，不应该超出一个自然人的负载；4）切分是内部活动，内部无论怎么切，对整个外部都应该是透明的。
所有的拆分都应该是树状的结果。
分工是用来提升整体利益的。
分层的前提是把一个生命周期的连续过程拆分成了一棵树，因为有棵树才有分层的出现。
对于一个组织架构，也要让它成为一个完美的树，并且使树的层次尽可能低，因为层次越深，沟通损失就越大，效率就越低。平衡树（任意节点的子树的高度差都小于等于1）的深度可以做到比较均衡。如果某个节点的能力很强，可以帮助减少树的高度；技术的提升也可以提升每个节点的能力，降低树的层数。很多管理学都在讨论如何降低组织架构的层数，使得管理能够扁平化，原因就在此。
一个好的组织领导一定是一个好的架构师。
架构切分的过程就是建模的过程。在早期流量不大的时候，往往一个人同时会兼很多的工作，一个系统往往也会做很多的事情。在流量增大以后系统很快就达到瓶颈，这个时候就不得不进行拆分了。要做到拆分必须去识别核心生命周期和非核心生命周期，把非核心生命周期切分出来。切分出来的不同子生命周期就形成了不同的概念。所以每个概念背后就是一个生命周期，每个生命周期就是一个模型。核心生命周期模型把所有的模型通过树组织起来，形成一个新的模型。
这些不同的概念，大部分的时候人们已经自发地建好了，架构师更多地是要去理解这些概念，职别该概念背后代表的问题以及该概念对应的人的利益。
架构切分的输出实际上就是一个系统的模型，一个以业务生命周期为树干的数。
架构切分的结果最终都会体现在组织架构上，因为架构的切分是实际上是对人利益的重新分配，另一方面，架构的切分需要组织架构来保障实施。
一个好的架构拆分，都会形成一棵树，慢慢会长成一片森林。每棵树在这个森林里都能够获得所需要的养分，有自己的空间。每棵树的内在是平和的，舒展的，遵循自己的生命周期规律，顺其自然地长大，一派欣欣向荣的景象。这就是架构的魅力所在。
第十章 架构与流程
流程就是多个角色为了把一件事做好，按照时间的顺序协作并完成的整个过程。一个流程的执行过程，本质上就是一个事物的生灭过程，是一个生命周期。
流程是描述整个事物发展各种可能性的树。
在对业务架构分析的过程中，对业务的流程梳理是非常重要的事情，往往代表了业务的核心。
流程背后的实质，是业务的核心生命周期。如果没有分工，是不会产生流程的，一个人按时间顺序从前做到后，没有人与人的协作。
流程把不同职责的角色串联起来，完成业务生命周期的所有活动，也就是说，流程的推动都是和人相关的，流程实际上串联出来的是不同角色协作的过程。
由于组织架构是一棵树，所以流程实际上就是对该流程负责人所负责的组织架构树的某种方式的遍历。
核心生业务生命周期。业务为了长大，发生了架构拆分，形成了一棵树。而流程则是拆分之后的业务进行组合，通过遍历树，重新形成了业务生i给你周期整体。
第十一章 什么是架构师
架构的目的是为了增长。
而要达到增长，就必须把很多人合并起来做同一件事情，并且使他们做的事情合并起来达到1+1>2的效果。而在现实生活中，人数增长到一定的程度，沟通效率就会下降。到了一定程度，人越多产出反而越少，这个时候就需要架构师。
架构师会把需要增长的业务了解清楚，挖掘出核心生命周期，并确定核心生命周期的主体。换句话说架构师要发现问题的主体，并确定核心问题。在确定核心生命周期之后，架构师还需要对业务核心生命周期进行分析，剥离出非核心生命周期，并根据当前人员的状况，合理地分配非核心生命周期的权责。这样不同的人就可以并行地互不影响地做不同的事情，最后根据核心生命周期，把他们的工作组合起来，达到1+1>2的效果。
以上仅仅是把现在的问题解决好，还需要更进一步，那就是根据对不同生命周期的运营情况，对未来的增长做一定的预判，提前做好规划，做相应人员、技术的储备-这就是战略架构。
架构师独特的地方在于，他自己的社会分工职责在于给别人分工。
架构师的工作成果应该由问题解决的结果来决定。也就说，架构师的权责也是要对等的。因为工作的时候并不是说每个人的“蛋糕”都一样多才好，有的人工作能力强，有的人工作能力弱。架构师工作的反馈，应该由问题的解决效果，也就是增长的效果来决定。如果以很少的资源增长达到了很大的业务增长，肯定是一个非常好的架构师，所节省下来的资源应该反馈给架构师，形成正向反馈。
架构实际上是一个通用的行为，只是大部分的时候人们自己没有意识到而已。比方说，很多人的办公桌看起来乱七八糟，但是它的工作非常有效率。因为他在长期的实践之后，根据每天自己的工作，整理出了自己工作的核心生命周期，与其相关的每样东西都摆放在合理的位置，其他的东西都放在非关键路径上。这个时候他已经在做架构思考了，因为他已经在专注于自己工作的核心生命周期，把非核心的都尽量剔除掉，以提高自己每天的产出。他已经是每天自己工作的架构师了，只是他自己没有意识到而已。任何一个人，只要他在思考如何做得更好，如何做得更多，必然会导致他去思考核心生命周期，那么，他已经在做架构的思考了。
只有真正具备权利落地的人才能叫架构师。
架构师要对总体的增长的效果负责，那么自然就意味着要能够调动资源，也要有权利分配。所以架构师往往都是某个业务或者领域的负责人。
第二部分 软件架构
第十二章 什么是软件
软件或技术是业务的使能者，实际上就是把业务的成本从很高降到了很低而已，并不是有了什么新的业务。
软件的主要目的，就是把人类的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效率的新生活，让核心生命周期的运行能够更加容易，让非核心生命周期的处理更少地占用人类的时间，变相延长人类的生命。
第十三章 软件的生命周期
软件的生命周期分为软件开发的生命周期和软件运行的生命周期。软件的运行周期是软件的核心生命周期。
软件运行的生命周期分为软件访问的生命周期、软件的功能生命周期、软件的监控生命周期。
从软件运行的生命周期角度来说，一个可运行的生独立部署单元才算是一个真正的软件。
一万个小时理论：如果每天工作八小时，一周工作五天，那么成为一个领域的专家至少需要五年。
学习一个东西如果只能是听懂，还不算是学会；如果自己能够按照所学的执行，也才学会了一半；如果能够把自己所学的东西用自己的语言表达出来，让别人听懂，这才算差不多学会了。
无论是哪种切分或者分工模式，即软件开发模式，其目标都是达到软件开发的增长。
所有达到增长的手段，都是围绕软件开发核心生命周期进行拆分的。把可以并行的非核心生命周期切分出来，以提升不同人员工作的时间和空间的并行度。这就是软件开发的架构。
第十四章 什么是软件架构
现实生活是软件思想的最主要来源。
软件架构就是通过对软件生命周期的切分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式。
架构追求的实际上是业务不断的长大：通过对业务生命周期的拆分，突出并精简业务核心生命周期，拆分出非核心生命周期，达到不同生命周期在空间和时间上并行，便于不同的人同时开展工作，提升业务人员单位时间内产出的办法。
业务相当于基因，而架构树状拆分则相当于细胞的分裂。就好比一个人，都是从一个细胞逐渐分裂出来的一棵树，起决定作用的不是分裂本身，而是他的基因。基因决定了细胞最终会分裂生长成什么样的一个生命。
只有业务才会进化，架构是支撑业务长大的，形成的是新的拆分。
第十五章 什么是软件架构师
软件的核心是模拟人的业务，而不是软件本身。
对于从软件工程师成长起来的软件架构师，要真正成长为一个架构师，首先需要克服的就是时间困境。从软件工程师的角度出发，首先需要面对的就是用自己的软件技术能力去解决业务问题。这些业务对软件工程师来说，是另一个行业的内容，是“别人”的问题。因此，软件工程师对于业务往往一知半解，也没有太大的动力去研究，他们主要专注于完成自己手头上的编码工作。如果一个人在工作中，只是致力于完成自己的工作，已做好自己的工作为主要的目标，那么用自己的行业知识去理解另一个行业，就很容易出现沟通的困境，造成很多理解上的困难。
当软件工程师需要帮助别人解决问题时，并且按时、按需解决业务问题已经成为他们自己的问题的时候，软件工程师就有了时间的压力，潜意识里自然而然地产生对时间的恐惧。在潜意识里，这个恐惧会想方设法地推动软件工程师采用各种手段，如加班加点，以便及时地完成工作，换取报酬。要想成为架构师，则必须超越对时间的恐惧，看清楚需要解决问题的主体是业务人员，而不是自己，即需要解决的问题是另一个行业的问题，自己是在帮助业务人员解决问题。这也是软件特别的地方。如果只顾着完成自己的工作，而业务的问题没有解决，那么很可能需要返工，从而导致软件工程师投入更多的时间。要知道，工作是否完成由业务人员决定，而不是软件工程师自己。
为什么软件工程师会对时间有恐惧和压力呢？其原因是他们把按时完成自己的工作当成了自己的最大利益。人对时间的压力是与生俱来的，并且对业务的不了解也会导致他们没有太大的把握。这一问题在其他行业的表现并不明显，毕竟在其他行业，架构师主要处理的是本行业的问题，对业务比较熟悉。软件行业则较为特殊，通常是以业务问题是否解决为判断标准，是在解决另一个行业的问题，这一点提高了对软件架构师的要求。这就要求软件架构师把完成业务的工作当成自己的最大利益，深入到业务中去。随着对业务的熟悉，对时间的恐惧才会慢慢地消失。对业务领域理解地越深入，就越知道如何去发现文艺，慢慢就会成为业务专家了。只有做到这一点，才能在业务领域建立自信，成为一个合格的软件架构师。
作为软件架构师，必须时刻把对软件的生命周期和业务的生命周期的识别放在第一位。软件生命周期的核心在于软件运行生命周期，以及围绕软件运行生命周期的拆分和组织，业务生命周期的核心在于围绕业务核心生命周期的拆分和组织。
软件开发的拆分和软件运行的拆分的目标都是为了支持业务流量的增长。
在代码层面，要对业务代码和访问代码做好架构拆分。业务代码是软件访问生命周期的核心，软件运行的拆分受限于软件代码的拆分。因此要确保业务代码符合业务的生命周期，使得业务生命周期活动的结果是积累在生命周期的主体上，也就是内聚性，避免散落到访问代码中。
软件的运行生命周期决定了软件的运维。对软件运行生命周期的拆分，就形成了软件的运维体系。
架构师的核心在于架构的执行。
软件架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好地发挥架构师的作用，才能偶把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。
一个好的领导，就是一个很好的架构师。在这个架构师的领导下，这个组织一定是健康向上的。因为好的架构师会关注核心生命周期，能够通过合理地拆分保证权利和义务的对等。对等就意味着权利得到了真正的下放，各角色的激励也能够到位。并且这类领导对业务的组织架构变化也会很敏感，会及时地根据业务组织架构的变化，根据软件开发生命周期和软件运行生命周期进行对应的组织架构调整，在问题发生之前就把问题消弭于无形。这个组织会具备更好地抗压能力，能够更好的为业务服务。
人类架构的核心就是组织架构。正确的组织架构才能保证架构的执行。
不懂业务的架构师一定不是一个好架构师。
大自然是最好的架构师，但大自然并不懂得如何去实现每个生命、每种技术，她所做的只是让每种生命顺应自己的生命周期而已。
要想做好架构师的工作，就要向大自然学习，这样才能够认识到事物自身的生命周期，并能够去顺应事物自身生命周期的规律来进行拆分，以达到增长的目的。
架构师很冷静、很平等地对待所有的技术。对于软件架构师来说，他们要深刻地另外软件开发的生命周期和软件的运行生命周期，以及业务的生命周期，把它们合理地结合在一起，并更够通过软件的快速增长来支撑和顺应业务的增长。这些是软件架构师的核心能力。为达到这些目标，无论是新的还是旧的技术、先进的技术还是落后的技术，只要场景合适，他们就会采纳。因为架构师是技术的使用者，他们把技术当做解决增长问题的手段和工具。
想做好技术的使用者并不容易。架构师必须深入地了解不同的技术，知道这些技术的强项和弱点，懂得合适地取舍。
没有最好的技术，也没有最差的技术，而问题总是在不断变化的。
使用一个技术就好比是搭积木，只要问题明确，寻找技术并组织来实现技术的拆分并不是难事。如果架构师能够深入理解技术背后的驱动力，了解技术是如何实现的，则能够作出更合理的判断和选择。所以，架构师在做好架构拆分后，会形成不同的生命周期。针对不同的生命周期，要选择不同的技术来进行支撑，再把不同的生命周期交给不同类型的软件工程师去实现。这就是架构师和技术人员的分工配合：架构师拆分生命周期，技术人员实现生命周期。
这就是为什么架构师需要有组织架构的权利，因为要确保架构拆分的落地。技术更多的是需要软件工程师掌握的。架构师思考技术时则更多地考虑技术对生命周期拆分的支撑，以及不同技术实现拆分时落地的成本和收益。
如果把业务理解为硬币，则可以认为架构和技术是硬币的两面，架构和技术共同形成了业务。
技术是架构师手中的工具，当没有合适的技术时，架构师会去创造技术，或者催生出新的技术。
其实对于做软件的技术人员而言，技术也可以分为两个部分：一部分是软件技术，另一部分是业务技术。当前软件行业所说的技术，基本上都是指软件技术和计算机相关的技术，也就是软件的访问生命周期所设计的技术，比如服务、存储等相关的技术，或计算机硬件设备相关的技术。软件技术大部分集中在软件的访问生命周期部分。业务技术这一块，软件工程师则较少涉及，这部分主要隐藏在业务逻辑中。因此在谈技术时，只谈软件技术是远远不够的。而不管是软件技术还是业务技术，均来源于对现实生活问题的解决，现实生活才是架构师真正的养分来源。
技术人员如果要成为架构师，就必须跳出技术的视角，换一个角度去看技术。要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，俄入世追求新潮的技术或者自己喜欢的技术。
第十六章 业务、架构和技术三者的关系
任何技术都是为解决某种问题而存在的。
技术，就是通过人为创造条件，让制定的规律按照人类的意愿发生。
所谓业务，就是要解决人类的问题，目的是为了支撑人来自身的生命周期，使人类获得利益。
技术总是在人类对业务目标要求不断提高的情况下产生，其目的是为了获取更大的利益。
业务是核心，技术是解决业务问题的工具，而架构是让业务长大的组织方法。架构需要技术去实现拆分，而技术需要架构来合理组织，以提升效率。
架构师，也就是软件开发组织的领导，应该承担起解决业务问题的角色，专注于业务和软件本身的架构，通过对软件开发生命周期和软件运行生命周期的拆分，让技术人员合理地分工。只有把业务和软件很好地结合起来，才能更好地完成业务目标，才会让软件更好的服务于大家。
软件运行生命周期这部分才是软件真正的核心能力。
第十七章 软件研发
软件最初的编写人员本身就是业务专家，业务非常精通，然后才学习用软件来提升业务的。
传统企业培养工程师做业务，可以降低沟通的成本，赢得未来。而软件工程师同时也应该跳出工程师的视角，以业务的视角来思考，则可以更快地融入业务并主导业务。
软件开发的生命周期包括：1）确定业务需求；2）编码；3）测试；4）上线。
要通过生命周期活动的不断积累，使得软件不断地长大，成为可以为人类带来收益的虚拟人。
迭代：软件无法一次把所有的业务都模拟出来，必须要分步骤的一个一个阶段做出来，通过用户的反馈，一点点地长大。迭代的前提是确定优先级。
软件开发的生命周期要允许犯错。因为软件要模拟的是人，人与人合作总会因为沟通等问题犯错的。
人与人之间必须通过亲身体验并操作才能够发现错误，仅仅依靠书面和口头的沟通是无法避免错误的。要减少错误，就必须要犯错误，只要犯的错误能够得到快速的反馈和纠正就不会造成问题。相反，犯的错误越多，纠正得越快，就越能够减少线上的问题。想要快速发现和纠正错误，就要做好迭代，而做好迭代就必须确保迭代的生命周期要足够短，这样就可以快速地纠正错误，才能够拥抱错误。这就是所谓的“敏捷”，核心就在于快速迭代并得到反馈。
快速地迭代以月甚至周为单位，这样一旦发现问题，或者业务有变化，就可以快速地应变，甚至“试错”。
所有的软件开发生命周期的活动，以及软件开发过程中的所有其他角色，都是为了帮助软件工程师更好、更有效率地编写代码，或者修改代码。
为了组织好代码，需要架构师去理解业务的核心生命周期以及业务的架构拆分，形成代码的架构。
为了组织好软件工程师，我们需要把软件划分为组件，或者拆分软件，尽可能的让软件工程师之间并行工作，较少冲突。
为了组织好软件工程师，就需要形成软件工程师的组织架构，与软件、组件进行对应，与业务的组织架构对应。
因此，架构师成为了软件开发生命周期推进的组织角色，为软件工程师保驾护航。
软件研发是一个复杂的活动，是创造并组织虚拟人的活动。
将业务建立在软件之上，可以实现软件和业务的合体，可以产生巨大的生产力。
只有软件工程师成为业务专家，写出来的软件才是靠谱的。
软件架构师要学习业务的架构，根据业务特点确定软件开发的核心生命周期，根据业务组织架构确定软件的拆分和架构：1）组织软件工程师进行有效地分工，形成软件开发团队的组织架构；2）为了减轻软件工程师的负担，要把软件开发过车过程中的非核心生命周期拆分出来，形成软件开发本身的业务架构，并通过这个自动化来提升软件工程师的开发效率。
软件工程师要做好架构工作，必须首先是业务的架构专家，同时也得是软件的架构专家，只要这样，才能够有效地支持好软件工程师的工作。
架构师如果自身时间有限，则必须要对自己的工作进行架构拆分。根据自身的核心生命周期，把非核心生命周期拆分出去，交由其他的角色负责，所形成的也是一个树状架构。
软件所面对的共有三大业务领为业务领域（由业务组织架构来推动业务的架构）、软件开发业务领域（由软件开发的业务组织架构来推动软件的业务架构。所形成的是软件开发模式，不同角色的分工模型）、软件运行业务领域（由软件的开发工程师来负责编写代码，形成软件的架构，并支撑软件的运行。对不同的软件开发工程师进行分工，形成不同的软件开发工程师组织架构，以支撑不同的软件，与软件的架构相匹配）。
软件业务组织架构和软件开发组织架构共同组成了软件研发团队。业务的特性和软件开发业务的特性同时积累到软件中，形成了软件的架构。
在软件开发生命周期中，软件工程师和软件架构师是最重要的两个角色，他们的分工分别是：软件工程师负责建设，软件架构师负责组织。
为了支持软件工程师的工作，软件架构师的工作职责主要包括：（1）理解业务组织架构，业务组织架构支撑并推进业务架构，背后的原因是对业务生命周期的拆分。（2）根据对业务生命周期的以及软件开发生命周期的拆分的特点，形成了软件软件开发本身的业务体系，以及对软件开发生命周期拆分，形成了和两者都相匹配的软件开发团队的组织架构。（3）对软件进行架构拆分，匹配业务架构和软件开发的业务架构。
第十八章 软件架构的拆分
业务组织架构拆分的背后原动力，是每个人的负载超限。
软件是为人服务的，是为业务服务的。
软件开发团队的拆分：最好是一个业务团队对应一个软件开发团队。当业务组织发生变化的时候，软件开发部门也应该要有相应的变化。
软件的拆分：最好是一个软件开发团队开发一个软件。
CTO的作用：辅助CEO管理软件方面的事务，管理软件开发团队的分工。
业务组织架构的拆分决定了软件开发团队的组织架构，进而决定了软件的组织架构。
影响软件拆分的动力就是流量的增长，也就是希望单位时间可以处理更多的业务。
第十九章 如何写好代码
代码主要由两部分构成：
1）表达业务生命周期的代码；
很多人把这一部分叫做业务逻辑或者业务模型，这部分是来源于生活与业务，必须和现实生活以及业务保持一致，忠实于现实中的业务。保持和现实生活一致的意思就是，业务代码的拆分，要和现实生活中业务人员的职责拆分一致，并保持内聚。也就是要根据业务的生命周期，分析出业务的核心生命周期，识别出非核心生命周期，以及他们之间的组织方式，用代码表达出来。这些生命周期对应的负责角色名称同时也需要明确。
内聚，是指某个生命周期的变化是积累在一个生命周期主体上的，而不是分散在不同的主体上。在代码中表示一个生命周期主体，就是指一个对象。一个对象的名字，就是该生命周期主体的名字；一个对象的方法，就是该生命周期主体的某个生命周期活动；一个对象的内部数据，就是该生命周期主体做生命周期活动的结果，积累在该对象上。某一时刻一个对象的内部数据，就是该生命周期主体当前的状态。对象的内部数据，会随着该生命周期主体的生命周期活动的进行以及时间而发生变化。对象内部数据的变化，即记录着业务的变化，也记录着生命周期活动的推进。
2）表达用户访问生命周期的代码。
软件的核心生命周期就是为用户提供对业务的访问，使得业务逻辑更够服务与用户。而为了让用户能够访问到所模拟的业务逻辑，则必须要提供访问的通道。表达访问生命周期的代码就是业务生命周期对外的访问通道，软件的核心价值通过这部分代码展现出来。
网友评论