架构漫谈--读书笔记

这几天阅读了王概凯老师的博客《架构漫谈》

 架构实际上是解决人的问题。而架构在思考层面上是抽象的，因此做好架构的必备能力就是正确认识概念，概念混杂的后果就是灾难性的跑偏，而且王老师在博文中指出过：做架构在多数情况下是在新的领域中解决问题。新领域环境下工作对概念的认识更加重要，你不能说还没学会走就开始跑，这还刨除了邯郸学步（跑偏了）的情况。架构不要求是全知全能的天才，但一定要知道在这个领域里该做什么，在短时间内能够进入状态，一定程度上掌握这个领域，才能正确解决问题。

上个世纪程序多由一个人完成，而随着软件的发展，人们对各种各样需求的增加，软件也变得越来越复杂，一个人已经无法承担，这时候有了软件开发团队，团队中各干各的显然不行，因此开始有意识地去分工。再后来，软件工程师应对其他行业知识显然是苦手，而不对行业知识有个明确认知也没办法完成甲方任务，这时候就出现了架构师。

架构不是只针对软件开发提出的概念!事实上任何领域都有架构的影子，而本篇笔记所提及的架构，是偏向软件架构的。

架构的专业解释是：根据要解决的问题界定目标系统边界；针对不同角色对工作进行切分，实现并行；保证每个切分部分之间能够建立有机联系，形成整体完成目标。用白话说，比如有一个房子，它的目的是能够让人居住，那么对房子的架构就是：墙（遮风保护），窗（采光），门（住户出入），地板（行走），屋顶（挡雨）等等。这些是为了能让人居住而必备的基本元素，后续再根据想法添置些什么，让这个房子变得更漂亮些，让人住得更舒服一些，这些就是提升这个房子的竞争力了。如今软件开发团队中，有专门的“架构师”的岗位，他们负责的就是在拿到项目的时候，能够精确的下达任务，让各个模块并发执行开发，提高效率，一个好的架构师，带给团队的利益是非常大的。

       架构该做些什么呢？首先就是要正确地识别问题。不要认为这很容易，有的时候客户不一定能清晰表达出自己的需求，要不然也不会出现复数的开发与协商。架构师要明白：发现问题永远比解决问题更重要。当认识问题之后，架构师就要着手开始切分，为什么要切分？从现实层面考虑，你不可能把一个任务交给一个人去干，首先干活儿的人无法接受，那太多了，负担太大；没活儿干的人也无法接受，他们不干活去哪来的钱。因此切分能够保证每个人在一定程度上有利可图。架构师在切分时不能无厘头，它同样有着原则：（1）必须在连续时间内发生的一个活动不能切分；（2）切分部分的负责人，对该部分的权力与义务必须对等；（3）切分部分不能超出一个人的负载；（4）切分是内部活动，不管怎么切，对整个系统外部是透明的。在遵循这些原则的基础上，我们再来考虑怎么切分，有人说谈架构就是谈分层，这话没什么问题，但要明确的是，分层源于树的概念，树的概念是由原则2推出来的：切分后整个系统从一个主干分成了许多分支，如X功能，Y功能，后台管理……。当一个成熟的软件开发完成时，我们应该看到的是枝叶繁茂的参天大树，而不是叶子都没有几个的枯树。谈起分层时要注意了：层数越多沟通越多，效率越低。因此分层要尽可能地让它变成一颗平衡树，这样才能让效率最大化。在切分4原则中，1，3，4原则更多的是一个基本标准，原则2才是最被看重的，因为它与利益直接相关。因此架构师在切分以及后续的调整时，满足原则的基础上需要重点参考原则2，这样才能保持组织的良性发展。可见架构师在团队内需要平衡甚至调整别人的利益，因此架构师在团队内有很大的影响力，架构师必须是一个合格的leader。

       现在再回到软件架构，软件自然离不开代码，王老师在讨论软件时有一个观点：软件实际上是对现实生活的模拟，虚拟化。以这个为前提的基础上，代码可以分为两个大类：表达业务逻辑的代码；提供访问保存运行结果的代码。分类后不难看出，第二部分代码不存在业务逻辑，因为只是给个输入输出，那么在开发过程中是可以并行执行的。这么看无疑是提供了一个开发思路：有着业务逻辑的代码往往牵扯到很多东西，开发过程存在限制，没有业务逻辑的代码就是单一的执行输出，写好接口就大功告成了，测试上单元测试都不用做，连通性测试就OK了。从架构角度看我们要明确哪些代码需要业务逻辑，哪些代码不需要，在此基础上再考虑设计模式，代码复用等问题，这样才能最大程度提高效率，实现目标。

       技术是为了解决业务问题，架构是为了能够高效率地使用技术，去解决业务问题。架构的目标是解决问题，架构的重点在发现问题。