软件架构师是如何工作的

最近看完了王概凯写的九篇架构漫谈后，对于软件架构师是如何工作的，首先我们的先知道什么是架构，架构就是根据要解决的问题，对目标系统的边界进行界定，并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间，并且并对这些切分出来的部分，设立沟通机制，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

软件架构师想要做好架构，搜先需要的必备的能力九世纪正确的认识概念，能够发现概念背后所代表的问，进而才能够认识目标领域索需要解决的问题，这样才能为做好架构打好基础。

其次做好架构首先需要识别出需要解决的问题，这个能力基本上决定了架构师的水平。一般来说，如果把真正的问题找到，那么问题就已经解决了 80% 了，要正确的认识问题，需要问两个问题：1这是谁的问题？2有什么问题？只要确定了问题一那么问题二解答就会变得非常容易，架构师的能力大部分会体现在问题 1 的识别上。其次还有做好架构的切分，架构的切分的导火索是人的负载太重。架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。

软件架构师是对软件进行架构，那么什么是软件呢，软件是用机器模拟人，在硬件上编写出的程序，就是软件。软件工程师是实现这个模拟过程的关键人物，他必须先理解人是怎么在日常生活中完成工作的，才能够很好的把这些工作在计算机中模拟出来，为了提升人类自己的利益，解决人类自己的问题。

软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，相关 stakeholder 的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。

最后我们要理清技术，业务和架构的关系，技术总是在人类解决对业务的要求不断提高的情况下产生，技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：

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

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

当关系 2 发生的时候，这个地方必定会形成一个切分，新技术会通过某种方式和原有的技术连接在一起形成一个整体，让这个新的技术可以和原有技术共同工作，使得原有的技术可以用更高的效率解决问题。因为要解决的主要问题（生火）并没有发生改变，分拆所形成的是一个树状的结构。

按照前面的架构定义，这个时候其实已经产生了架构。也就是说，一般是先有技术，才会有架构。这些其他技术（弓弦拉动木棍），是从直接解决问题的初始主要技术中分拆出来形成的，并通过树状结构和主要技术（钻木取火）组合在一起。在解决主要问题（生火）之后，再开始逐渐的分拆为更为细粒度的技术（弓弦转木棍）。

而这个细粒度的技术（弓弦转动木棍）往往不会和业务的主要目标（生火）发生直接的关系。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。很多人把这个过程称为架构的进化，我更愿意把这个过程称为技术的进步所导致的新的架构分拆，因为这个过程内在的动力，更多的是来自技术对解决业务问题的解决。

当技术所解决的问题和分拆出来要解决的问题，完全匹配的时候，这是最完美的。比如需要提供 web 要访问的 service，很多 MVC 的 framework 就可以很好的满足这一点。而这个时候如果非要自己实现一个，很有可能就是重新发明轮子。
当技术所提供的能力远远超过需要解决的问题时，往往掌握技术和维护技术会成为瓶颈。因为越复杂的技术，成本越高。如果自己实现一个仅仅是解决当前问题的方案，可能成本反而更低。这也是为什么很多大型的互联网公司不断地开源出来自己的技术的原因。而这些技术对于我们来说是否适用？他们原本是用来解决谁的问题的？什么问题？如果不清楚这些，就冒然采用，可能会导致更高的成本。
当技术所提供的能力和我们所要解决的问题部分匹配时，还是要看成本。比如当我们需要一个锤子的时候，手边正好没有，但是却有一只高跟鞋，勉强也可以替代锤子。但是长期来看，这么用不划算，因为高跟鞋的价格比锤子高很多，耐用性差很多，维护成本也高很多。

目的也是为了获取更大更好的利益，准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。