架构漫谈读后感
一、说在前面
今天读了王概凯的九篇架构漫谈，收获颇丰，在这里做下笔记，并围绕软件架构师如何工作进行谈一谈。
二、笔记
一、什么是架构 产生架构的原因： 个人观点：当大家需要合作完成一件事情的时候，每个人都有自己擅长做的事情，于是当分工发生后每个人的实际生产力都因为做了自己擅长的事情得到了提高，就可以提高整体的生产力。类比到软件系统上也是这样。一个软件需要被完成，之中需要包括多个系统，系统中又有许多不同的功能，将这些功能和系统抽象统一出来（我认为可以理解成盖房子时提前准备好石头沙子砖头等材料，然后再按照图纸拼起来）我认为这就是产生架构的原动力。 （1）必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了） （2）每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象） （3）每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见 2，从而缩短时间） （4）人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了） （5）目标系统的复杂性使得单个人完成这个系统，满足条件 2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率） 什么是架构： 个人观点：将问题进行抽象统一，找到其中各个部分的联系，再将各个模块组合到一起。 （1）根据要解决的问题，对目标系统的边界进行界定。 （2）并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。 （3）并对这些切分出来的部分，设立沟通机制。 （4）根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
架构实际上解决的是人的问题
概念是人认识这个世界的基础
什么才是概念（名相）？：
个人观点：能完成一个具体作用的东西，概念是为其起的一个名字
相实际上代表的是这个作用，并不是具体的某个东西，而名是用来标识这个作用的，用来交流的。
为什么需要概念：
个人观点：概念可以清晰的定义不同作用的事物，让其有区分。另外就和每个人都有自己的名字一样，可以很容易的交流沟通和认识新的人，有概念之后就方便了人们对新事物的学习和已知事物的区分。
每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。
关于抽象：
个人观点：抽象和泛化是两个相反的动作，抽象是从一个事物或多个事物中找到它的关键点（可以用来定义其本身的点）。例如：我们平时在交流时，A问B说你记不记得那个谁了？然后B说是谁啊？。这是A就会说是咱们班那个眼睛大，长得白，高高的那个男生。这四个特点（班里、眼睛大、白、高、男生）就是A抽象出来的关键点。
抽象这个词代表的含义，实际上是把不同的概念的相似的部分合并在一起，形成一个新的概念。这个里面问题很多：首先“相似的部分”在不同的人看来，并不一定那么相似；其次，抽象之后形成的是一个新的概念，和原来那个概念并不一样，所解决的问题也不一样。所以我们不能用抽象来定义一个事物，抽象实际上是一个分类的过程，完全是另一码事。
做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决了 80% 了。这个能力基本上就决定了架构师的水平。 面对问题有哪些困难呢？ 个人观点： （1）找到真正的问题，提出的问题和解决问题的人理解的问题是不是同一个问题（可能有点绕）。 （2）问题的重点是什么（和第一点其实差不多）。 （3）容易想当然，接到问题后就想当然的去按照自己的直觉解决问题，沉浸在工作中，却忘了为什么要干，自己要解决掉是什么问题，结果到最后只是驴唇不对马嘴南辕北辙，反而增大了工作量还弄得都不高兴。 （4）提问题的人是不是需要解决问题的人，还是问题的传话人？ 要正确的认识问题，需要问两个问题： （1）这是谁的问题？ （2）有什么问题？ 当得到的回答是支支吾吾的时候，我们就知道正确的方向在哪儿，以及需要做哪些事了。以我的经验，问题1会花比较多的时间，也是支支吾吾最多的地方，因为架构要解决的问题都是人的问题。但是一旦确定了答案，问题2就会变得非常容易。可以这样说，架构师的能力大部分会体现在问题1的识别上。
个人观点：各司其职，工作要尽量均衡，不能全部压到一个人身上。类比到软件上就是，各个模块之间要均衡，不能头重脚轻。 所发现的问题，会有几种情况： （1）某个或者某些利益相关人负载太重。 ·时间上的负载太重。 ·空间上的负载太重，本质上还是时间上的负载太重。 （2）某个或者某些利益相关人的权利和义务不对等。 切分就要有几个原则： （1）必须在连续时间内发生的一个活动，不能切分。比如孕妇怀孕，必须要 10 月怀胎，不能够切成 10 个人一个月完成。 （2）切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。比方说妈妈 10 月怀胎，妈妈有权利处置小孩的出生和抚养，同样也对小孩的出生和抚养负责。为什么必须是这样呢? 因为如果权利和义务是不对等的话，会伤害每个个体的利益，分出来执行的效率会比没有分出来还要低，实际上也损害了整体的利益，这违背了提升整体利益的初衷。 （3）切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。 （4）切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化，那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候，整个系统的边界会进一步的完善，这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生，也会导致新的架构的切分。
个人观点：可以根据人的输入来控制机器来输出相应的结果，替人来完成简单和繁琐的工作。
软件的历史，实际上可以说是用机器模拟人的历史。不管大家（包括在这个历史过程中的参与者）有没有意识到，我们都有意无意的在计算机上模仿人类的行为。从冯诺依曼结构开始，程序逻辑开始脱离硬件，采用二进制编码。加上存储，配合输入输出，一个简化的大脑就出现了。图灵机则是模拟大脑的计算，用数学的方式把计算的过程定义了出来，著名的邱奇 - 图灵论题：一切直觉上能行可计算的函数都可用图灵机计算，反之亦然。软硬件两者一结合，一个可编程的大脑出现了，这也是现在为什么我们把计算机叫做电脑。在硬件上编写出的程序，就是软件，是用来控制硬件的行为的。
个人观点：架构师掌管着一个工程的整体进度，所以手中必须要有点权力，否则如果有人觉得他的方案有问题或者是不愿意做就会肆意妄为，而架构师却无能为力。所以我认可这个观点。
架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个 leader。但是只是民意上的 leader 是没有用的，不能完全发挥架构师的能量。
架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。所以很多公司设了很多架构师的职位，但是并不具备调动组织架构的权利，那么这个架构师的职位一定是形同虚设。架构师只能够通过建立某些流程来行使架构师的权利，比如强制架构review，反而会造成很多内部不必要的冲突，最终都会导致这些流程流于形式，得不偿失。
个人观点：我认为从架构的角度看写好代码就是从宏观的角度来看，将代码写成一个一个组件，组件都是标准件，组件写好之后就是搭建的问题了。 （1）Service 就专注于 user 的需求，并组合 Glue Code 提供的服务完成需求。 （2）Glue Code 专注于组合 business 的调用，管理 Business 里面对象的生命周期，并且通过 Repository 保存或加载 Business 的状态 （3）Business 专注于实现业务的核心模型。 （4）Repository 专注于数据的保存，并和存储设备一一对应。
九、理清技术、业务和架构的关系
