架构漫谈读后感

（一）什么是架构？程序员

    架构的英文是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）。而后就会有提升效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其余人（或者技术发明人本身）加以改进，这部分就会造成新的技术。

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