软件架构师如何工作

软件架构师如何工作

对于初学软件架构的我来说软件架构师的工作这个概念是非常模糊的，在我的理解上软件架构师所从事软件开发方面的工作应该与建筑方面的建筑设计师很类似，他们应该承担着类似的责任，在整个项目真正投入开发之前提前把整个项目的框架勾勒出来以便于告诉执行者他们需要如何去做，显而易见这个岗位是在整个项目建设过程中最为重要当然也是最难的工作。

当然对于架构免不了问一句：“何为架构？”

在王概凯的架构漫谈种种也谈到了这个问题：

什么是架构？

架构的英文是 Architecture，在Wikipedia 上，架构是这样定义的：

Architecture (Latin architectura, from the Greek ?ρχιτ?κτων arkhitekton"architect", from ?ρχι- "chief" and τ?κτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。

从这个定义上看，架构好像是一个过程，也不是很清晰。为了讲清楚这个问题，我们先来看看为什么会产生架构。

在了解了架构是何方神圣之后，我们免不了再问一句：“为什么会产生架构？”

在王概凯的架构漫谈种种也谈到了这个问题：

为什么会产生架构？

想象一下，在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。

但是一旦多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情。

整个人群的生产力和抵抗环境的能力都得到了增强。为什么呢？因为每个人的能力和时间都是有限的，并且因为人的结构的限制，人同时只能专心做好一件事情，这样不得已就导致了分工的产生。既然分工发生了，原来由一个人干生存所必需的所有的事情，就变成了很多不同分工的角色合作完成这些事情，这些人必须要通过某些机制合在一起，让每个人完成生存所必需的事情，这实际上也导致了交易的发生（交易这部分就不在这里展开了，有机会再讨论）。

了解了架构相关的理论之后我对于架构有了更深一步的认识，但是作为一个软件架构师应该如何工作呢？

1、学会识别问题

所有的概念基本都有一个很大的问题，就是缺乏主语。而我们大家都心照不宣的忽略这个主语，沟通的时候也都以为大家都懂得对方说的主语是谁，结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。

2、应该在开发过程中获得实权

如果我们还生活在这个恐惧下面，是不可能成为架构师的。要成为架构师，必须要超越这个恐惧才能够看清楚，我们要解决的是别人的问题，不是自己完成工作的问题。因为仅仅是完成了自己的工作，也并不一定就解决了别人的问题。如果别人的问题没有解决 -- 即使我们认为自己的工作完成了 -- 我们的工作实际也没完成，因为我们工作是否完成，是别人说的算的，不是我们自己。

3、理清技术、业务和架构的关系

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

技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。

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

所以技术与技术之间，有两种关系：

在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。

一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的 enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。