读《架构漫谈》有感
先附上王概凯老师的《架构漫谈》的文章查看网址：https://www.infoq.cn/profile/25881D72552D8E/publish
《架构漫谈》共分有9篇文章：
一、什么是架构
王老师以人类文明发展史中的团结合作完成工作为例子，当完成一个相对复杂的工作时，一个人完成的话，需要按部就班一步一步的去完成，需要耗费大量的时间和精力，而且考虑到有的人擅长的方面不多，在不擅长的方面就要花费更多时间，因此，一个人完成工作不仅效率低时间长，而且可能质量也不高。但是如果有不同长处的人进行相对应工作的分工，不仅可以并行，同时施工，还能保证工作质量，于是这一整个工作被分割成了无数个小工作，不同的人完成不同的小工作，自此，社会的架构的概念出现。尤其要注意：需要是人进行的工作，不需要人来完成的谈不上架构。总结一下，架构就是：
- 根据要解决的问题，对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
- 并对这些切分出来的部分，设立沟通机制。
- 根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
二、认识概念是理解架构的基础
用王老师的例子，首先，我们思考，为什么杯子叫杯子，从属性来看，杯子如果碎了还能不能叫杯子，不能，因为它不再具有杯子的功能，所以，概念是通过它的作用来定义的，因此，要学好架构一定要有认识本质的能力，除此之外，王老师还让我对抽象的理解有了新的看法，抽象实际上是把不同的概念的相似的部分合并在一起，形成一个新的概念。因此我们要正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。不仅是架构，其他方面一样适用。
三、如何做好架构之识别问题
看看在我们处理问题的时候，都会犯什么样的错误：
1、被告知要处理一个问题，但是交过来的实际上是一个解决方案，不是问题本身
2、被告知要处理一个问题，直接通过直觉就有了一个解决方案，马上考虑解决方案如何落地，或者有几种解决方案，选哪个合适
在王老师的文章中，我印象最深刻的一句话就是：发现问题永远都比解决问题来的更加重要。
我们大多数时候都是在埋头解决问题，可我们很少考虑过我们解决的是谁的问题，在聊天中被我们自动忽略的主语成为了我们犯错的主要原因，我们每天忙碌在解决问题中，解决来解决去，最终有可能问题越来越多，有可能走了弯路，有可能解决的不是用户想要解决的问题，还有可能解决错了。因此，在与人沟通的时候我们要明确问题的主语，我们要解决的是什么问题，再切身处地的去思考要如何解决。
总结一下，要正确的认识问题，需要问两个问题：
1、这是谁的问题？
2、有什么问题？
四、如何做好架构之架构切分
切分就是利益的调整，有些人，拿着大把利益，但是他们付出了大量的时间和精力，他们撑不住了，需要切分，切分利益而获取时间和精力，有些人能力有限，不做切分就完不成任务，于是他们需要切分利益，也就是负责其中的一部分，做架构的调整。但是切分也有原则：
1、一件连续的，有周期的事不可分割；
2、切分的部分的负责人的权利和义务是对等的；
3、切分出来的部分，不应该超出一个自然人的负载；
4、切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的；
另外要注意，在切割的时候，一定要保证对所有人的长远利益是有益的，这样才能形成一个新的利益循环，良性的发展下去。
总结一下
1、架构的切分的导火索是人的负载太重。
2、架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。
3、架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
4、架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
五、什么是软件
简单地说，我们在硬件上编写出的程序，用来控制硬件的行为，就是软件。最开始软件只是程序员为了解决自己的问题而写代码，后来发现也可以为别人解决问题，自此，软件就此横空出世，逐渐发展成为一个行业。在有了软件之后，人们发现生活中的越来越多方面都可以和软件挂钩，我们的生活可以数字化，变得更好，更方便。于是，软件一点一滴渗入人们的生活，成为了人们生活必不可少的一部分。而软件的主要目的，还是把人类的生活模拟化，提供更低成本，高效率的新的生活。所以，软件还是要依赖人的知识的。于是乎，简单的软件已经无法让人们满足了，人们开始研发更复杂更实用更方便的软件，慢慢的，人们发现一个人来完成工作量太大了，于是，人们开始结组开发，于是，人们开始不同分工，架构由此产生。
六、给架构师实权
王老师提到，架构师对时间有恐惧，因为架构师和程序员不一样，程序员是明确的为自己解决问题，没有很严格的时间限制，只需要在规定时间解决自己面前的问题即可，但是架构师不是，他要在规定时间内完成对产品的理解，汇聚成易懂的语言传递给程序员，他需要有充分的理解能力和思考能力，善于发现问题，解决问题，准确无误的传达信息，在语言和沟通方面要很擅长。否则，未来，越来越少的人找你合作，逐渐没有收入，被淘汰。同时，架构师最好是领导职位，例如小组长等等，因为他会根据要求分配任务，也就是切分，他要考虑到每个人的利益，为人民服务，才能成为一个人心所向的好leader。所以，架构师需要有实权！！
七、从架构的角度看，如何写好代码
我们经常见到重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。这也并不是架构进化的事情，而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下，代码的架构应该是怎样的。要从三个方向，程序员，甲方和用户来看待软件，从而进行架构分析，最终决定最后的架构。
八、理清技术、业务和架构的关系
首先强调，有技术并不意味着就是架构师了，技术只是解决问题的方法，学会了技术如何解决问题，才是架构师的职责，学太多技术有时候反而不是好事，因为会不知道用什么来解决，所以，技术、业务和架构的关系可以总结为：
技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：
- 技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。
- 有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求–也就是业务。
所以技术与技术之间，有两种关系：
3. 在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。
4. 一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的 enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。
