阅读笔记——架构漫谈

　　上周读完资深架构师王概凯的9篇“架构漫谈”文章，我深有所感。也逐渐有了对软件架构的初步了解。再结合本学期软件体系结构这门课程在此发表一下我对架构的认识和理解，如有什么不对之处也欢迎大家前来指正，我也诚心接受大家的批评和建议。

　　首先对于“架构”的概念，我想先了解他是如何产生，也就是为什么会有架构会更容易帮助我们理解它。

　　我们从软件发展史上来看，从最开始由计算机的发展最初的软件是十分简单的，因为受到硬件的局限，准确地讲应该是程序，而程序也就用于解决我们自己的问题。以个人的能力完全可以去独立开发。后来就到了软件小作坊时代，这个时候软件已经开始流行了，同时也给软件开发人员带来了令人眼花缭乱的问题，单靠个人或者一小部分人的能力已经无法将问题解决。于是软件危机爆发了，同时我们的软件工程也诞生了，而软件架构又是软件工程中不可或缺的与部分。这正如王概凯所说，我们面临的复杂问题单靠个人或少数人已经无法解决。于是我们会发起合作，齐心协力，做好每个人擅长的一部分，有了明确分工，每个人负责问题的一部分，最好再结合到一起。这就是复杂问题简单化，简单问题流程化。软件架构就是如何对问题进行切分，逐个去解决，最后总结归整。

　　正确认识问题是软件架构的关键。

　　软件架构是解决人的问题，这里的范围很广，可以是客户、也可以是开发人员。首先要认清问题的主题，找准问题的方向再做深入挖掘。上学期的软件需求与分析的课程是我们认识到，客户（我觉得可以拓展到问题的主体）他所提出的问题只是极小一部分，犹如北冰洋中的冰山，它露出来的只是一小部分，有很大部分都是问题自己表达不出的或者自己还没意识到的。这更加考验架构师的能力。

　　然后就是架构的切分，因为个人的能力有限，单个人的在时间负载过重。还有就是利益分配不均，权利与义务不对等需要做出明确的切分。我们肯定要做出正确的切分，如果切分不当将会是问题更加复杂。架构漫谈提出了几条切分原则。（1）必须在连续时间内发生的一个活动，不能切分。（2）切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。（3）切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。（4）切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。在这里我们可以得到架构拆分是一个树状的结构，他会有着分层。在这里王概凯讲的非常好——如果某个节点的能力很强，也可以达到减小树的高度的结果。技术的提升，也是可以提升每个节点的能力，降低树的层数。很多管理学都在讨论如何降低组织架构的层数，使得管理能够扁平化，原因就在于此，这里就不展开讨论了。从这里也基本可以得出一个结论，一个好的组织的领导，一定也是一个很好的架构师。

　　技术、架构与业务的关系。首先架构师扮演的是上帝的角色，因为已经不再局限于解决自己的问题了。对于技术，首先抛出的一个简单的问题——掌握的技术越多，水平就越高吗？肯定不是的，技术只是我们用于解决问题的手段而已.不是有一种普遍的观点“技术仍普遍看不起业务，认为技术更高端，业务太低端，并且业务往往喜欢给技术挖坑，业务觉得技术眼高手低，理解总有偏差，但是自己又无可奈何，因为自己不会”。技术与架构以及与业务之间的关系。王概凯是这样讲的，

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

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

所以技术与技术之间，有两种关系：
3. 在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。
4. 一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的 enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。