阅读笔记——架构漫谈

　　这学期学习了软件体系结构这门课，想要做出好的软件，就需要在制作过程中对整个软件系统进行设计，引入软件架构的概念，为此阅读了王概凯的架构漫谈，得出了以下体会。

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

　　对于架构，我是这样理解的：架构是在一个整体中产生的，在整体中对整个系统进行切分，每个被切分的小模块担任不同的角色，每个角色相互沟通，完成各自的分工，进而完成整体所执行的功能，提高效率。这里的架构并不只是针对软件而言，对于任何领域的工程都能有所启示。在平常不经意间我们也在使用架构，譬如合作分工进行整体软件的制作，会使工作效率整体提高。从架构的机制可以看出架构产生的原因：整体系统复杂度、要求高；个人的时间和精力有限，每个人需要完成自己的分工。

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

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

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

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