<<架构漫谈>>读后感

今天按照老师的要求，看了架构漫谈1--9讲，觉得受益良多，以下是我得点点读后感：

（一）什么是架构？

架构的英文是Architecture，从定义上看，架构好像是一个过程，也不是很清晰。下面从架构的缘由开始讲解一下：为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，有了分工之后，人们的效率得到了巨大的提高，所以这就产生了架构，所以文章也对这种现象总结了一些规律。

1. 必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了）

2. 每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象）

3. 每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见2，从而缩短时间）

4. 人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了）

5. 目标系统的复杂性使得单个人完成这个系统，满足条件2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率）。

总结一下，什么是架构，就是：

1. 根据要解决的问题，对目标系统的边界进行界定。
2. 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3. 并对这些切分出来的部分，设立沟通机制。
4. 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

（二）如何做好架构之识别的问题·

人们在处理问题的时候，都容易犯一个很大的问题，那就是在描写概念的时候缺乏主语。而我们大家都心照不宣的忽略这个主语，沟通的时候也都以为大家都懂得对方说的主语是谁，结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。

所以为了更好的解决问题，我们要更好的理解概念的问题·，架构的问题，不然在一段时间忙完了发现自己做的是无用功，所以我们要明白什么是主体。

（三）如何做好架构之架构切分

我们要非常的清楚，所有的切分调整，都是对相关人的利益的调整。因为维护自己的利益，是每个人的本性，是在骨子里面的，我们不能逃避这一点。在现在社会，每个人都希望能够把自己的利益最大化，所以人们为了工作更加的具有效率，自然需要舍掉一些自己不擅长的东西，用自己擅长的东西去换取别人擅长的东西。因此当人们认识到要主动的去切分一个系统的时候，毫无疑问，我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点，这是大方向。结合前一篇“识别问题”，一旦确定了问题的主体，那么系统的利益相关人（用现代管理学语言叫：stakeholder）就确定了下来。所发现的问题，会有几种情况：

1. 某个或者某些利益相关人负载太重。
2. 时间上的负载太重。
3. 空间上的负载太重，本质上还是时间上的负载太重。
4. 某个或者某些利益相关人的权利和义务不对等。

为了在切分系统的时候，更加的平衡我们需要要有着几个原则：

1. 必须在连续时间内发生的一个活动，不能切分。比如孕妇怀孕，必须要10月怀胎，不能够切成10个人一个月完成。

2. 切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。比方说妈妈10月怀胎，妈妈有权利处置小孩的出生和抚养，同样也对小孩的出生和抚养负责。为什么必须是这样呢? 因为如果权利和义务是不对等的话，会伤害每个个体的利益，分出来执行的效率会比没有分出来还要低，实际上也损害了整体的利益，这违背了提升整体利益的初衷。

3. 切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。

4. 切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化，那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候，整个系统的边界会进一步的完善，这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生，也会导致新的架构的切分。

在切分时候，这其实也就是一个建模的过程，为了把大问题分解成小问题，减少人们的负担量，使人们都更有效率的完成自己的工作。

（四）什么是软件

在初期，软件使用二进制编写的，从硬件到软件，成本都非常的高。随着半导体技术的进步，硬件的成本越来越低，性能越来越高，甚至出现了摩尔定律：当价格不变时，集成电路上可容纳的元器件数目，约每隔18-24个月增加一倍，性能提升一倍。软件方面，为了简化难度，开始采用汇编，进一步出现了类似于人类的语言的高级语言，这使得人类可以用类似于人的语言来和计算机沟通。软件工程师慢慢越来越多，开发软件的成本也越来越低。计算机就好像是一个只需要电，不需要休息的人，可以无休无止的工作。人们越来越愿意把原来只有人才能做的事情，交给计算机来做。结果就导致软件越来越丰富，能够做的事情也越来越多，成本也越来越低。随着软件的规模的变大，做好一个软件也变得越来越难了。早期的程序员写程序，主要是为了帮助自己研究课题。这些程序员熟练了之后，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。

所以软件工程师就是实现这个模拟过程的关键人物，他必须先理解人是怎么在日常生活中完成工作的，才能够很好的把这些工作在计算机中模拟出来，软件工程师本身的培养就比较难，同时行业知识也要靠时间的积累，这样就远远超出了软件工程师的能力了。所以软件开发就开始有分工了。

（五）软甲架构到底要解决什么问题

软件实际上就是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题：

1.业务问题

2.计算机问题

这就是软件比较复杂的地方，涉及到软件本身的业务体系，和所虚拟的业务体系。根据以上的分析，所生成的架构，究竟那些算是软件架构呢？

1. 软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。

2. 每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。

　　所以当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。

（六）不要空设架构师这个职位，要给他实权

当我们真正专注于别人的问题的时候，我们自己的理想，抱负，对技术的追求都不算什么了。这个时候就会真正的开始思考，别人究竟有什么问题。架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个leader。但是只是民意上的leader是没有用的，不能完全发挥架构师的能量。所以架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。所以很多公司设了很多架构师的职位，但是并不具备调动组织架构的权利，那么这个架构师的职位一定是形同虚设。架构师只能够通过建立某些流程来行使架构师的权利，比如强制架构review，反而会造成很多内部不必要的冲突，最终都会导致这些流程流于形式，得不偿失。反过来，具备架构师能力的组织领导人，一定是一个很好的领导，这个组织一定是很健康向上的，因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感，会及时的调整组织架构，在问题发生之前就解决了。这样这个组织就会具备更好的抗压能力，能够更好的为这个组织的客户服务，这个组织的成员内心一定都是比较平衡的，每个人的能力都能够得到比较好的发展。当然读者可能又会说，这不是管理学的东西吗？ 是的，但也是架构的问题。所有架构的核心就是组织架构。或者也可以这样说，一个合格的组织领导人，一定必须是一个合格的架构师。

所以有人说架构师还需要技术吗？很多人会问，特别是做软件行业的，架构师是不是需要学习技术，甚至是学习语言？ 如果一个架构师还有这个困扰——就如问这个问题的人，说明目前还不具备做架构师的能力，或者说还不具备对自己领域——哪怕是技术领域——的自信，更别谈业务领域了。

（七）从架构的角度想如何写好代码

重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。

软件实际上是对现实生活的模拟，虚拟化。这是一个非常重要的前提，直接决定了我们的代码应该分为几部分。结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：

1. 表达业务逻辑的代码。很多人把这部分叫做Domain Logic，或者叫Domain Model。这部分实际是来源于生活的，必须保持和现实生活中的切分一致，并非人为的抽象而成。

2. 对用户提供访问并保存业务逻辑运行结果的代码。计算机的状态保存有一个缺陷，本机保留业务运行结果有很大的问题，一般都在外存储设备上保存，也便于扩展。

这样，就划分成了几个责任：

1. Service就专注于user的需求，并组合Glue Code提供的服务完成需求。

2. Glue Code专注于组合business的调用，管理Business里面对象的生命周期，并且通过Repository保存或加载Business的状态

3. Business专注于实现业务的核心模型。

4. Repository专注于数据的保存，并和存储设备一一对应。

（八）理清技术，业务和架构的关系

技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：

1. 技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。

2. 有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务。有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题。

　　所以技术与技术之间，有两种关系：

1. 在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。

2. 一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。

所以在我们做工作的时候，公司里的技术人员总是和业务人员发生冲突呢？ 这是因为技术人员很多时候关心的技术，和业务的主要目标往往不是直接对应的，业务也是负责某一部分的业务，也不是和业务的主要目标直接对应的，都是树的分支节点（上文已经解释了为何会发生这种情况）。只有直接解决业务问题的那个技术（或业务）—— 树的根节点 —— 会和业务直接相关。所以一旦产生冲突，一般必须两个根节点（一般都是领导）碰面才能解决问题，就是这个原因——他们都知道业务主要目标。这也是为什么下层无法理解上层，而上层都喜欢下军令状，要求下层执行。人只有尽量去理解上层的问题才能做下层的分拆。所以架构师应该承担起解决业务问题的这个角色来。所以，准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。