精华内容
下载资源
问答
  • 很多人都想知道架构师是做什么?我们看看下面的一段对话。 菜鸟—— 刚入门的程序员 老鸟—— 资深架构师 老鸟:菜鸟,你的目标是什么? 菜鸟:我要成为一个软件架构师。 老鸟:对一个年轻的工程师来说...

    阅读本文大概需要 6 分钟。

     

    很多人都想知道架构师是做什么?我们看看下面的一段对话。

     

    菜鸟 —— 刚入门的程序员

    老鸟 —— 资深架构师

    老鸟:菜鸟,你的目标是什么?

    菜鸟:我要成为一个软件架构师。

    老鸟:对一个年轻的工程师来说,这是一个很好的目标。那你为什么要成为架构师呢?

    菜鸟:我要领导一个团队,还要做所有关于数据库、框架和Web服务器的重要决定。

    老鸟:好吧,如果是这样,你就没必要成为一个软件架构师了。

    菜鸟:当然有必要了!我要成为一个能够做所有重要决定的人。

    老鸟:这样很好,只是你没有列出哪些才是重要的决定。你刚才说的那些跟重要的决定没有什么关系。

    菜鸟:你说什么?难道数据库不重要?你知道我们在数据库上面花了多少钱吗?

    老鸟:可能很多。不过数据库仍然不是最重要的。

    菜鸟:你怎么能这么说呢?数据库可是整个系统的心脏啊!所有的数据都保存在这里,它们在这里被排序,被索引,被访问。如果没有数据库,整个系统就无法运作!

    老鸟:数据库只不过是一个IO设备,它提供了一些有用的工具对数据进行排序、查询,并生成报表,但这些工具都只是整个系统的附属品。

    菜鸟:附属品?真是不可思议。

    老鸟:是的,附属品。你的系统业务逻辑或许会用到这些工具,但这些工具并非业务逻辑固有的组成部分。如果有必要,你可以随时替换掉这些工具,但业务逻辑还是那些业务逻辑。

    菜鸟:好吧,不过如果把这些工具替换掉,我们就要重新实现业务逻辑了。

    老鸟:那是你的问题。

    菜鸟:为什么这么说?

    老鸟:你认为业务逻辑依赖数据库,但实际上不是这样的。如果你的架构足够好,最起码业务逻辑不应该依赖数据库。

    菜鸟:这太疯狂了。我怎么可能创建出不使用这些工具的业务逻辑?

    老鸟:我并没有说业务逻辑不要使用数据库工具,我的意思是它们不应该依赖这些工具。业务逻辑不应该知道使用的是哪一种数据库。

    菜鸟:如果业务逻辑对数据库一无所知,它怎么使用这些工具呢?

    老鸟:依赖反转。你要让数据库依赖业务逻辑,而不是让业务逻辑依赖数据库。

    菜鸟:你的话让人费解。

    老鸟:费解吗?我讲的可是软件架构。这个就是依赖反转原则,让下层策略来依赖上层策略。

    菜鸟:那就更加费解了!既然上层策略(假设你指的是业务逻辑)要调用下层策略(假设你指的是数据库),那么就应该是上层策略依赖依赖下层策略,就像调用者依赖被调用者一样。这是众所周知的!

    老鸟:在运行时确实是这样的,但在编译时我们要把依赖反转过来。上层策略的代码里不要引用任何下层策略的代码。

    菜鸟:拜托!不引用代码就无法调用它们。

    老鸟:当然可以调用了。面向对象就可以做到。

    菜鸟:面向对象对真实世界进行建模,把数据和函数组合到对象里,把代码组织成直观的结构。

    老鸟:这是他们告诉你的吗?

    菜鸟:所有人都知道的,这不是很明显的事情吗?

    老鸟:确实如此。不过,面向对象是可以做到不引用也能调用的。

    菜鸟:好吧,那它是怎么做到的?

    老鸟:你应该知道,在面向对象系统里对象会给其它对象发送消息的,对吧?

    菜鸟:是的,当然。

    老鸟:那么你就该知道,消息发送者是不知道消息接收者是什么类型的。

    菜鸟:这要看使用的是哪一种语言了。在Java里,发送者最起码要知道接收者的基本类型。在Ruby里,发送者知道接收者一定会处理它所发送的消息。

    老鸟:是的。不过不管是哪一种情况,发送者都不知道接收者具体的类型。

    菜鸟:嗯,是的。

    老鸟:所以发送者可以给接收者传递一个函数,让接收者执行这个函数,这样发送者就不需要知道接收者是什么类型了。

    菜鸟:没错。我了解你的意思。不过发送者仍然依赖接收者。

    老鸟:在运行时确实是的,但在编译时不是这样的。发送者的代码里并没有引用接收者的代码。实际上,是接收者的代码依赖了发送者的代码。

    菜鸟:啊!但发送者仍然会依赖接收者的类。

    老鸟:看来需要用代码来说明了,我用Java来写些代码。首先是发送者代码:

    老鸟:下面是接收者代码:

    老鸟:可以看到,接收者代码依赖了发送者代码,也就是说SpecificReceiver依赖了Sender。同时可以看到,发送者代码对接收者代码一无所知。

    菜鸟:哈,你作弊了。你把接收者的接口放到了发送者的类里了。

    老鸟:你开始明白了。

    菜鸟:明白什么?

    老鸟:当然是架构原则啊。发送者持有接收者必须实现的接口。

    菜鸟:如果这意味着我要使用内部类,那么……

    老鸟:使用内部类只是方法之一,还有其它的方法。

    菜鸟:请等一下。最开始我们讨论的是数据库,那这些跟数据库又有什么关系呢?

     

    老鸟:让我们来看一下其它代码吧。首先是一个简单的业务逻辑

    菜鸟:这个业务逻辑没有做什么事情啊。

    老鸟:这只是个例子。在实际实现业务逻辑的时候,不会有很多类似这样的类的。

    菜鸟:好吧。那么Gateway是用来做什么的呢?

    老鸟:它为业务逻辑提供了所有访问数据的方法。下面是它的代码:

    老鸟:要注意,这个接口是在businessRules包里面的。

    菜鸟:好吧。那Something这个类又是用来做什么的呢?

    老鸟:它代表一个简单的业务对象。我把它放在另一个叫entities的包里。

    老鸟:最后需要实现BusinessRuleGateway接口,这个实现类会知道相关的数据库细节:

    老鸟:可以看到,业务逻辑是在运行时对数据库进行调用的。而在编译时,是database包引用了businessRules包。

    菜鸟:好吧,我想我明白了。你用多态性隐藏了数据库实现。不过在业务逻辑里,仍然引用了数据库的工具接口。

    老鸟:不,不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具接口,而是业务逻辑创建了它们所需要的接口。在实现这些接口的时候,可以调用相应的工具。

    菜鸟:嗯,这样的话,如果业务逻辑需要所有的工具,那么你必须把所有工具都放到Gateway接口里。

    老鸟:哈,我觉得你还是没有明白。

    菜鸟:不明白什么?我觉得已经很清楚了。

    老鸟:每个业务逻辑只定义它所需要的接口。

    菜鸟:等等,什么意思?

    老鸟:这个叫作接口分离原则。每个业务逻辑只使用一部分数据库工具,所以每个业务逻辑只定义能够满足需要的接口。

    菜鸟:这样的话,你就会有很多接口,而且有很多实现类。

    老鸟:哈,是的。你开始明白了。

    菜鸟:这样子很浪费时间!我为什么要这样做呢?

    老鸟:这样做是为了让代码更干净,并且节省时间。

    菜鸟:算了吧,这样只会增加更多的代码。

    老鸟:相反,这其实是很重要的架构决定,这跟你之前所说的那些所谓的重要决定是不一样的。

    菜鸟:什么意思?

    老鸟:还记得你刚开始说你要成为一个软件架构师吗?你还想要做所有重要的决定?

    菜鸟:是啊,我是这么想过。

    老鸟:你想做所有关于数据库、Web服务和框架的决定。

    菜鸟:是啊,而你却说它们都不重要,还说它们其实跟重要的决定不相干。

    老鸟:没错,它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。

    菜鸟:但首先要先决定用什么数据库、Web服务器或框架啊!

    老鸟:实际上应该在开发后期才开始做这些事情——在你掌握了更多信息之后。

    老鸟当架构师草率地决定要使用一个数据库,后来却发现使用文件系统效率更高

    老鸟当架构师草率的决定使用一个Web服务器,后来却发现团队需要的不过是一个socket接口

    老鸟当架构师草率地决定使用一个框架,后来却发现框架提供的功能是团队不需要的,反而给团队带来了诸多约束

    老鸟当架构师在掌握了足够多的信息后才决定该用什么数据库、Web服务器或框架

    老鸟当架构师为团队鉴别出运行缓慢、耗费资源的IO设备和框架,这样他们就可以构建飞速运行的轻量级测试环境

    老鸟:当架构师把注意力放在那些真正重要的事情上,并把那些不重要的事情放在一边。

    菜鸟:我完全不知道你在说什么了。

    老鸟:好吧,如果在若干年后你还没有转做管理,或许会明白这一切的……

    对话来源网络,若有侵权,请联系删除

    通过上面的对话,让我们对架构师有了个简单的了解,那么架构师在一家公司有多重要呢?架构师对一家公司、一个项目有多重要?

    我们来看一看调查的数据

    架构师在公司中担当着「IT架构灵魂人物」的角色,因为他们不仅做着架构师的本职工作,还同时做程序开发,写核心代码。另外,架构师依旧是技术高手,编程能力依然是一流的。

    从图表结果来看,架构师必须具备出色的设计能力、编程能力和沟通能力,在完成本职的架构工作外,还要协调好项目中人员的关系,做出合理的分工,最终完成全部工作。

    最后,看下企业对Java架构师的职位描述与职位要求

    从招聘信息来看,架构师们必须是具有多年的从业经验,有过项目开发经历,精通多门编程语言且熟悉数据库的大咖。所以,想以架构师为目标的读者,就要加倍努力了!

    展开全文
  • 一个对话让你明白架构师是做什么的

    万次阅读 多人点赞 2019-03-11 10:56:31
    很多人都想知道架构师是做什么?我们看看下面的一段对话。 菜鸟—— 刚入门的程序员 老鸟—— 资深架构师 老鸟:菜鸟,你的目标是什么? 菜鸟:我要成为一个软件架构师。 老鸟:对一个年轻的工程师来说,...

    阅读本文大概需要 6 分钟。

    很多人都想知道架构师是做什么?我们看看下面的一段对话。

     

    菜鸟 —— 刚入门的程序员

    老鸟 —— 资深架构师

     

    老鸟:菜鸟,你的目标是什么?

    菜鸟:我要成为一个软件架构师。

     

    老鸟:对一个年轻的工程师来说,这是一个很好的目标。那你为什么要成为架构师呢?

    菜鸟:我要领导一个团队,还要做所有关于数据库、框架和Web服务器的重要决定。

     

    老鸟:好吧,如果是这样,你就没必要成为一个软件架构师了。

    菜鸟:当然有必要了!我要成为一个能够做所有重要决定的人。

     

    老鸟:这样很好,只是你没有列出哪些才是重要的决定。你刚才说的那些跟重要的决定没有什么关系。

    菜鸟:你说什么?难道数据库不重要?你知道我们在数据库上面花了多少钱吗?

     

    老鸟:可能很多。不过数据库仍然不是最重要的。

    菜鸟:你怎么能这么说呢?数据库可是整个系统的心脏啊!所有的数据都保存在这里,它们在这里被排序,被索引,被访问。如果没有数据库,整个系统就无法运作!

     

    老鸟:数据库只不过是一个IO设备,它提供了一些有用的工具对数据进行排序、查询,并生成报表,但这些工具都只是整个系统的附属品。

    菜鸟:附属品?真是不可思议。

     

    老鸟:是的,附属品。你的系统业务逻辑或许会用到这些工具,但这些工具并非业务逻辑固有的组成部分。如果有必要,你可以随时替换掉这些工具,但业务逻辑还是那些业务逻辑。

    菜鸟:好吧,不过如果把这些工具替换掉,我们就要重新实现业务逻辑了。

     

    老鸟:那是你的问题。

    菜鸟:为什么这么说?

     

    老鸟:你认为业务逻辑依赖数据库,但实际上不是这样的。如果你的架构足够好,最起码业务逻辑不应该依赖数据库。

    菜鸟:这太疯狂了。我怎么可能创建出不使用这些工具的业务逻辑?

     

    老鸟:我并没有说业务逻辑不要使用数据库工具,我的意思是它们不应该依赖这些工具。业务逻辑不应该知道使用的是哪一种数据库。

    菜鸟:如果业务逻辑对数据库一无所知,它怎么使用这些工具呢?

     

    老鸟:依赖反转。你要让数据库依赖业务逻辑,而不是让业务逻辑依赖数据库。

    菜鸟:你的话让人费解。

     

    老鸟:费解吗?我讲的可是软件架构。这个就是依赖反转原则,让下层策略来依赖上层策略。

    菜鸟:那就更加费解了!既然上层策略(假设你指的是业务逻辑)要调用下层策略(假设你指的是数据库),那么就应该是上层策略依赖依赖下层策略,就像调用者依赖被调用者一样。这是众所周知的!

     

    老鸟:在运行时确实是这样的,但在编译时我们要把依赖反转过来。上层策略的代码里不要引用任何下层策略的代码。

    菜鸟:拜托!不引用代码就无法调用它们。

     

    老鸟:当然可以调用了。面向对象就可以做到。

    菜鸟:面向对象对真实世界进行建模,把数据和函数组合到对象里,把代码组织成直观的结构。

     

    老鸟:这是他们告诉你的吗?

    菜鸟:所有人都知道的,这不是很明显的事情吗?

     

    老鸟:确实如此。不过,面向对象是可以做到不引用也能调用的。

    菜鸟:好吧,那它是怎么做到的?

     

    老鸟:你应该知道,在面向对象系统里对象会给其它对象发送消息的,对吧?

    菜鸟:是的,当然。

     

    老鸟:那么你就该知道,消息发送者是不知道消息接收者是什么类型的。

    菜鸟:这要看使用的是哪一种语言了。在Java里,发送者最起码要知道接收者的基本类型。在Ruby里,发送者知道接收者一定会处理它所发送的消息。

     

    老鸟:是的。不过不管是哪一种情况,发送者都不知道接收者具体的类型。

    菜鸟:嗯,是的。

     

    老鸟:所以发送者可以给接收者传递一个函数,让接收者执行这个函数,这样发送者就不需要知道接收者是什么类型了。

    菜鸟:没错。我了解你的意思。不过发送者仍然依赖接收者。

     

    老鸟:在运行时确实是的,但在编译时不是这样的。发送者的代码里并没有引用接收者的代码。实际上,是接收者的代码依赖了发送者的代码。

    菜鸟:啊!但发送者仍然会依赖接收者的类。

     

    老鸟:看来需要用代码来说明了,我用Java来写些代码。首先是发送者代码:

    老鸟:下面是接收者代码:

    老鸟:可以看到,接收者代码依赖了发送者代码,也就是说SpecificReceiver依赖了Sender。同时可以看到,发送者代码对接收者代码一无所知。

    菜鸟:哈,你作弊了。你把接收者的接口放到了发送者的类里了。

     

    老鸟:你开始明白了。

    菜鸟:明白什么?

     

    老鸟:当然是架构原则啊。发送者持有接收者必须实现的接口。

    菜鸟:如果这意味着我要使用内部类,那么……

     

    老鸟:使用内部类只是方法之一,还有其它的方法。

    菜鸟:请等一下。最开始我们讨论的是数据库,那这些跟数据库又有什么关系呢?

     

    老鸟:让我们来看一下其它代码吧。首先是一个简单的业务逻辑

    菜鸟:这个业务逻辑没有做什么事情啊。

     

    老鸟:这只是个例子。在实际实现业务逻辑的时候,不会有很多类似这样的类的。

    菜鸟:好吧。那么Gateway是用来做什么的呢?

     

    老鸟:它为业务逻辑提供了所有访问数据的方法。下面是它的代码:

    老鸟:要注意,这个接口是在businessRules包里面的。

    菜鸟:好吧。那Something这个类又是用来做什么的呢?

     

    老鸟:它代表一个简单的业务对象。我把它放在另一个叫entities的包里。

    老鸟:最后需要实现BusinessRuleGateway接口,这个实现类会知道相关的数据库细节:

    老鸟:可以看到,业务逻辑是在运行时对数据库进行调用的。而在编译时,是database包引用了businessRules包。

    菜鸟:好吧,我想我明白了。你用多态性隐藏了数据库实现。不过在业务逻辑里,仍然引用了数据库的工具接口。

     

    老鸟:不,不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具接口,而是业务逻辑创建了它们所需要的接口。在实现这些接口的时候,可以调用相应的工具。

    菜鸟:嗯,这样的话,如果业务逻辑需要所有的工具,那么你必须把所有工具都放到Gateway接口里。

     

    老鸟:哈,我觉得你还是没有明白。

    菜鸟:不明白什么?我觉得已经很清楚了。

     

    老鸟:每个业务逻辑只定义它所需要的接口。

    菜鸟:等等,什么意思?

     

    老鸟:这个叫作接口分离原则。每个业务逻辑只使用一部分数据库工具,所以每个业务逻辑只定义能够满足需要的接口。

    菜鸟:这样的话,你就会有很多接口,而且有很多实现类。

     

    老鸟:哈,是的。你开始明白了。

    菜鸟:这样子很浪费时间!我为什么要这样做呢?

     

    老鸟:这样做是为了让代码更干净,并且节省时间。

    菜鸟:算了吧,这样只会增加更多的代码。

     

    老鸟:相反,这其实是很重要的架构决定,这跟你之前所说的那些所谓的重要决定是不一样的。

    菜鸟:什么意思?

     

    老鸟:还记得你刚开始说你要成为一个软件架构师吗?你还想要做所有重要的决定?

    菜鸟:是啊,我是这么想过。

     

    老鸟:你想做所有关于数据库、Web服务和框架的决定。

    菜鸟:是啊,而你却说它们都不重要,还说它们其实跟重要的决定不相干。

     

    老鸟:没错,它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。

    菜鸟:但首先要先决定用什么数据库、Web服务器或框架啊!

     

    老鸟:实际上应该在开发后期才开始做这些事情——在你掌握了更多信息之后。

     

    老鸟当架构师草率地决定要使用一个数据库,后来却发现使用文件系统效率更高

     

    老鸟当架构师草率的决定使用一个Web服务器,后来却发现团队需要的不过是一个socket接口

     

    老鸟当架构师草率地决定使用一个框架,后来却发现框架提供的功能是团队不需要的,反而给团队带来了诸多约束

     

    老鸟当架构师在掌握了足够多的信息后才决定该用什么数据库、Web服务器或框架

     

    老鸟当架构师为团队鉴别出运行缓慢、耗费资源的IO设备和框架,这样他们就可以构建飞速运行的轻量级测试环境

     

    老鸟:当架构师把注意力放在那些真正重要的事情上,并把那些不重要的事情放在一边。

    菜鸟:我完全不知道你在说什么了。

     

    老鸟:好吧,如果在若干年后你还没有转做管理,或许会明白这一切的……

     

    对话来源网络,若有侵权,请联系删除

    通过上面的对话,让我们对架构师有了个简单的了解,那么架构师在一家公司有多重要呢?架构师对一家公司、一个项目有多重要?

    我们来看一看调查的数据

    架构师在公司中担当着「IT架构灵魂人物」的角色,因为他们不仅做着架构师的本职工作,还同时做程序开发,写核心代码。另外,架构师依旧是技术高手,编程能力依然是一流的。

    从图表结果来看,架构师必须具备出色的设计能力、编程能力和沟通能力,在完成本职的架构工作外,还要协调好项目中人员的关系,做出合理的分工,最终完成全部工作。

    最后,看下企业对Java架构师的职位描述与职位要求

    从招聘信息来看,架构师们必须是具有多年的从业经验,有过项目开发经历,精通多门编程语言且熟悉数据库的大咖。所以,想以架构师为目标的读者,就要加倍努力了!

     

    ·END·

    路虽远,行则必至

    本文原发于 同名微信公众号「程序员的成长之路」,回复「1024」你懂得,给个赞呗。

    微信ID:cxydczzl

     

    往期精彩回顾

    程序员接私活的7大平台利器

    教你一招用 IDE 编程提升效率的骚操作!

    作为程序员的你,一年看几本技术相关的书

    大学期间的副业赚钱之道

    5个相见恨晚的Linux命令

    缓存穿透,缓存击穿,缓存雪崩解决方案分析

    为啥程序员下班后只关显示器从不关电脑?

    送给程序员们的经典电子书大礼包

    面试时如何优雅地自我介绍?

    支撑百万并发的数据库架构如何设计?

    一千行MySQL详细学习笔记

    展开全文
  • 很多人都想知道架构师是做什么?我们看看下面的一段对话。 菜鸟—— 刚入门的程序员 老鸟—— 资深架构师 老鸟:菜鸟,你的目标是什么? 菜鸟:我要成为一个软件架构师。 老鸟:对一个年轻的工程师来说,...

    很多人都想知道架构师是做什么?我们看看下面的一段对话。

     

    菜鸟 —— 刚入门的程序员

    老鸟 —— 资深架构师

     

    老鸟:菜鸟,你的目标是什么?

    菜鸟:我要成为一个软件架构师。

     

    老鸟:对一个年轻的工程师来说,这是一个很好的目标。那你为什么要成为架构师呢?

    菜鸟:我要领导一个团队,还要做所有关于数据库、框架和Web服务器的重要决定。

     

    老鸟:好吧,如果是这样,你就没必要成为一个软件架构师了。

    菜鸟:当然有必要了!我要成为一个能够做所有重要决定的人。

     

    老鸟:这样很好,只是你没有列出哪些才是重要的决定。你刚才说的那些跟重要的决定没有什么关系。

    菜鸟:你说什么?难道数据库不重要?你知道我们在数据库上面花了多少钱吗?

     

    老鸟:可能很多。不过数据库仍然不是最重要的。

    菜鸟:你怎么能这么说呢?数据库可是整个系统的心脏啊!所有的数据都保存在这里,它们在这里被排序,被索引,被访问。如果没有数据库,整个系统就无法运作!

     

    老鸟:数据库只不过是一个IO设备,它提供了一些有用的工具对数据进行排序、查询,并生成报表,但这些工具都只是整个系统的附属品。

    菜鸟:附属品?真是不可思议。

     

    老鸟:是的,附属品。你的系统业务逻辑或许会用到这些工具,但这些工具并非业务逻辑固有的组成部分。如果有必要,你可以随时替换掉这些工具,但业务逻辑还是那些业务逻辑。

    菜鸟:好吧,不过如果把这些工具替换掉,我们就要重新实现业务逻辑了。

     

    老鸟:那是你的问题。

    菜鸟:为什么这么说?

     

    老鸟:你认为业务逻辑依赖数据库,但实际上不是这样的。如果你的架构足够好,最起码业务逻辑不应该依赖数据库。

    菜鸟:这太疯狂了。我怎么可能创建出不使用这些工具的业务逻辑?

     

    老鸟:我并没有说业务逻辑不要使用数据库工具,我的意思是它们不应该依赖这些工具。业务逻辑不应该知道使用的是哪一种数据库。

    菜鸟:如果业务逻辑对数据库一无所知,它怎么使用这些工具呢?

     

    老鸟:依赖反转。你要让数据库依赖业务逻辑,而不是让业务逻辑依赖数据库。

    菜鸟:你的话让人费解。

     

    老鸟:费解吗?我讲的可是软件架构。这个就是依赖反转原则,让下层策略来依赖上层策略。

    菜鸟:那就更加费解了!既然上层策略(假设你指的是业务逻辑)要调用下层策略(假设你指的是数据库),那么就应该是上层策略依赖依赖下层策略,就像调用者依赖被调用者一样。这是众所周知的!

     

    老鸟:在运行时确实是这样的,但在编译时我们要把依赖反转过来。上层策略的代码里不要引用任何下层策略的代码。

    菜鸟:拜托!不引用代码就无法调用它们。

     

    老鸟:当然可以调用了。面向对象就可以做到。

    菜鸟:面向对象对真实世界进行建模,把数据和函数组合到对象里,把代码组织成直观的结构。

     

    老鸟:这是他们告诉你的吗?

    菜鸟:所有人都知道的,这不是很明显的事情吗?

     

    老鸟:确实如此。不过,面向对象是可以做到不引用也能调用的。

    菜鸟:好吧,那它是怎么做到的?

     

    老鸟:你应该知道,在面向对象系统里对象会给其它对象发送消息的,对吧?

    菜鸟:是的,当然。

     

    老鸟:那么你就该知道,消息发送者是不知道消息接收者是什么类型的。

    菜鸟:这要看使用的是哪一种语言了。在Java里,发送者最起码要知道接收者的基本类型。在Ruby里,发送者知道接收者一定会处理它所发送的消息。

     

    老鸟:是的。不过不管是哪一种情况,发送者都不知道接收者具体的类型。

    菜鸟:嗯,是的。

     

    老鸟:所以发送者可以给接收者传递一个函数,让接收者执行这个函数,这样发送者就不需要知道接收者是什么类型了。

    菜鸟:没错。我了解你的意思。不过发送者仍然依赖接收者。

     

    老鸟:在运行时确实是的,但在编译时不是这样的。发送者的代码里并没有引用接收者的代码。实际上,是接收者的代码依赖了发送者的代码。

    菜鸟:啊!但发送者仍然会依赖接收者的类。

     

    老鸟:看来需要用代码来说明了,我用Java来写些代码。首先是发送者代码:

     

    老鸟:下面是接收者代码:

     

    老鸟:可以看到,接收者代码依赖了发送者代码,也就是说SpecificReceiver依赖了Sender。同时可以看到,发送者代码对接收者代码一无所知。

    菜鸟:哈,你作弊了。你把接收者的接口放到了发送者的类里了。

     

    老鸟:你开始明白了。

    菜鸟:明白什么?

     

    老鸟:当然是架构原则啊。发送者持有接收者必须实现的接口。

    菜鸟:如果这意味着我要使用内部类,那么……

     

    老鸟:使用内部类只是方法之一,还有其它的方法。

    菜鸟:请等一下。最开始我们讨论的是数据库,那这些跟数据库又有什么关系呢?

     

    老鸟:让我们来看一下其它代码吧。首先是一个简单的业务逻辑

     

    菜鸟:这个业务逻辑没有做什么事情啊。

     

    老鸟:这只是个例子。在实际实现业务逻辑的时候,不会有很多类似这样的类的。

    菜鸟:好吧。那么Gateway是用来做什么的呢?

     

    老鸟:它为业务逻辑提供了所有访问数据的方法。下面是它的代码:

     

    老鸟:要注意,这个接口是在businessRules包里面的。

    菜鸟:好吧。那Something这个类又是用来做什么的呢?

     

    老鸟:它代表一个简单的业务对象。我把它放在另一个叫entities的包里。

     

    老鸟:最后需要实现BusinessRuleGateway接口,这个实现类会知道相关的数据库细节:

     

    老鸟:可以看到,业务逻辑是在运行时对数据库进行调用的。而在编译时,是database包引用了businessRules包。

    菜鸟:好吧,我想我明白了。你用多态性隐藏了数据库实现。不过在业务逻辑里,仍然引用了数据库的工具接口。

     

    老鸟:不,不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具接口,而是业务逻辑创建了它们所需要的接口。在实现这些接口的时候,可以调用相应的工具。

    菜鸟:嗯,这样的话,如果业务逻辑需要所有的工具,那么你必须把所有工具都放到Gateway接口里。

     

    老鸟:哈,我觉得你还是没有明白。

    菜鸟:不明白什么?我觉得已经很清楚了。

     

    老鸟:每个业务逻辑只定义它所需要的接口。

    菜鸟:等等,什么意思?

     

    老鸟:这个叫作接口分离原则。每个业务逻辑只使用一部分数据库工具,所以每个业务逻辑只定义能够满足需要的接口。

    菜鸟:这样的话,你就会有很多接口,而且有很多实现类。

     

    老鸟:哈,是的。你开始明白了。

    菜鸟:这样子很浪费时间!我为什么要这样做呢?

     

    老鸟:这样做是为了让代码更干净,并且节省时间。

    菜鸟:算了吧,这样只会增加更多的代码。

     

    老鸟:相反,这其实是很重要的架构决定,这跟你之前所说的那些所谓的重要决定是不一样的。

    菜鸟:什么意思?

     

    老鸟:还记得你刚开始说你要成为一个软件架构师吗?你还想要做所有重要的决定?

    菜鸟:是啊,我是这么想过。

     

    老鸟:你想做所有关于数据库、Web服务和框架的决定。

    菜鸟:是啊,而你却说它们都不重要,还说它们其实跟重要的决定不相干。

     

    老鸟:没错,它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。

    菜鸟:但首先要先决定用什么数据库、Web服务器或框架啊!

     

    老鸟:实际上应该在开发后期才开始做这些事情——在你掌握了更多信息之后。

     

    老鸟当架构师草率地决定要使用一个数据库,后来却发现使用文件系统效率更高

     

    老鸟当架构师草率的决定使用一个Web服务器,后来却发现团队需要的不过是一个socket接口

     

    老鸟当架构师草率地决定使用一个框架,后来却发现框架提供的功能是团队不需要的,反而给团队带来了诸多约束

     

    老鸟当架构师在掌握了足够多的信息后才决定该用什么数据库、Web服务器或框架

     

    老鸟当架构师为团队鉴别出运行缓慢、耗费资源的IO设备和框架,这样他们就可以构建飞速运行的轻量级测试环境

     

    老鸟:当架构师把注意力放在那些真正重要的事情上,并把那些不重要的事情放在一边。

    菜鸟:我完全不知道你在说什么了。

     

    老鸟:好吧,如果在若干年后你还没有转做管理,或许会明白这一切的……

     

    对话来源网络,若有侵权,请联系删除

     

    通过上面的对话,让我们对架构师有了个简单的了解,那么架构师在一家公司有多重要呢?架构师对一家公司、一个项目有多重要?

    我们来看一看调查的数据

     

    架构师在公司中担当着「IT架构灵魂人物」的角色,因为他们不仅做着架构师的本职工作,还同时做程序开发,写核心代码。另外,架构师依旧是技术高手,编程能力依然是一流的。

    从图表结果来看,架构师必须具备出色的设计能力、编程能力和沟通能力,在完成本职的架构工作外,还要协调好项目中人员的关系,做出合理的分工,最终完成全部工作。

    最后,看下企业对Java架构师的职位描述与职位要求

     

    从招聘信息来看,架构师们必须是具有多年的从业经验,有过项目开发经历,精通多门编程语言且熟悉数据库的大咖。所以,想以架构师为目标的读者,就要加倍努力了!

    展开全文
  • \\\好吧,如果这样,你就没必要成为一个软件架构师了。\\\当然有必要了!我要成为一个能够所有重要决定的人。\\\这样很好,只是你没有列出哪些才重要的决定。你刚才说的那些跟重要的决定没有什么关系。\\\你说...

    我要成为一个软件架构师。

    \\
    \

    对一个年轻的工程师来说,这是一个很好的目标。

    \
    \\

    我要领导一个团队,还要做所有关于数据库、框架和Web服务器的重要决定。

    \\
    \

    好吧,如果是这样,你就没必要成为一个软件架构师了。

    \
    \\

    当然有必要了!我要成为一个能够做所有重要决定的人。

    \\
    \

    这样很好,只是你没有列出哪些才是重要的决定。你刚才说的那些跟重要的决定没有什么关系。

    \
    \\

    你说什么?难道数据库不重要?你知道我们在数据库上面花了多少钱吗?

    \\
    \

    可能很多。不过数据库仍然不是最重要的。

    \
    \\

    你怎么能这么说呢?数据库可是整个系统的心脏啊!所有的数据都保存在这里,它们在这里被排序,被索引,被访问。如果没有数据库,整个系统就无法运作!

    \\
    \

    数据库只不过是一个IO设备,它提供了一些有用的工具对数据进行排序、查询,并生成报表,但这些工具都只是整个系统的附属品。

    \
    \\

    附属品?真是不可思议。

    \\
    \

    是的,附属品。你的系统业务逻辑或许会用到这些工具,但这些工具并非业务逻辑固有的组成部分。如果有必要,你可以随时替换掉这些工具,但业务逻辑还是那些业务逻辑。

    \
    \\

    好吧,不过如果把这些工具替换掉,我们就要重新实现业务逻辑了。

    \\
    \

    那是你的问题。

    \
    \\

    为什么这么说?

    \\
    \

    你认为业务逻辑依赖数据库,但实际上不是这样的。如果你的架构足够好,最起码业务逻辑不应该依赖数据库。

    \
    \\

    这太疯狂了。我怎么可能创建出不使用这些工具的业务逻辑?

    \\
    \

    我并没有说业务逻辑不要使用数据库工具,我的意思是它们不应该依赖这些工具。业务逻辑不应该知道使用的是哪一种数据库。

    \
    \\

    如果业务逻辑对数据库一无所知,它怎么使用这些工具呢?

    \\
    \

    依赖反转。你要让数据库依赖业务逻辑,而不是让业务逻辑依赖数据库。

    \
    \\

    你的话让人费解。

    \\
    \

    费解吗?我讲的可是软件架构。这个就是依赖反转原则,让下层策略来依赖上层策略。

    \
    \\

    那就更加费解了!既然上层策略(假设你指的是业务逻辑)要调用下层策略(假设你指的是数据库),那么就应该是上层策略依赖依赖下层策略,就像调用者依赖被调用者一样。这是众所周知的!

    \\
    \

    在运行时确实是这样的,但在编译时我们要把依赖反转过来。上层策略的代码里不要引用任何下层策略的代码。

    \
    \\

    拜托!不引用代码就无法调用它们。

    \\
    \

    当然可以调用了。面向对象就可以做到。

    \
    \\

    面向对象对真实世界进行建模,把数据和函数组合到对象里,把代码组织成直观的结构。

    \\
    \

    这是他们告诉你的吗?

    \
    \\

    所有人都知道的,这不是很明显的事情吗?

    \\
    \

    确实如此。不过,面向对象是可以做到不引用也能调用的。

    \
    \\

    好吧,那它是怎么做到的?

    \\
    \

    你应该知道,在面向对象系统里对象会给其它对象发送消息的,对吧?

    \
    \\

    是的,当然。

    \\
    \

    那么你就该知道,消息发送者是不知道消息接收者是什么类型的。

    \
    \\

    这要看使用的是哪一种语言了。在Java里,发送者最起码要知道接收者的基本类型。在Ruby里,发送者知道接收者一定会处理它所发送的消息。

    \\
    \

    是的。不过不管是哪一种情况,发送者都不知道接收者具体的类型。

    \
    \\

    嗯,是的。

    \\
    \

    所以发送者可以给接收者传递一个函数,让接收者执行这个函数,这样发送者就不需要知道接收者是什么类型了。

    \
    \\

    没错。我了解你的意思。不过发送者仍然依赖接收者。

    \\
    \

    在运行时确实是的,但在编译时不是这样的。发送者的代码里并没有引用接收者的代码。实际上,是接收者的代码依赖了发送者的代码。

    \
    \\

    啊!但发送者仍然会依赖接收者的类。

    \\
    \

    看来需要用代码来说明了,我用Java来写些代码。首先是发送者代码:

    \\
    \package sender;\public class Sender {\  private Receiver receiver;\  public Sender(Receiver r) {\    receiver = r;\  }\  public void doSomething() {\    receiver.receiveThis();\  }\  public interface Receiver {\    void receiveThis();\  }\}\
    \
    \\
    \

    下面是接收者代码:

    \\
    \package receiver;\import sender.Sender;\public class SpecificReceiver implements Sender.Receiver {\  public void receiveThis() {\    //这里会做一些有趣的事情\  }\}
    \
    \\
    \

    可以看到,接收者代码依赖了发送者代码,也就是说SpecificReceiver依赖了Sender。同时可以看到,发送者代码对接收者代码一无所知。

    \
    \\

    哈,你作弊了。你把接收者的接口放到了发送者的类里了。

    \\
    \

    你开始明白了。

    \
    \\

    明白什么?

    \\
    \

    当然是架构原则啊。发送者持有接收者必须实现的接口。

    \
    \\

    如果这意味着我要使用内部类,那么……

    \\
    \

    使用内部类只是方法之一,还有其它的方法。

    \
    \\

    请等一下。最开始我们讨论的是数据库,那这些跟数据库又有什么关系呢?

    \\
    \

    让我们来看一下其它代码吧。首先是一个简单的业务逻辑

    \\
    \package businessRules;\import entities.Something;\public class BusinessRule {\  private BusinessRuleGateway gateway;\  public BusinessRule(BusinessRuleGateway gateway) {\    this.gateway = gateway;\  }\  public void execute(String id) {\    gateway.startTransaction();\    Something thing = gateway.getSomething(id);\    thing.makeChanges();\    gateway.saveSomething(thing);\    gateway.endTransaction();\  }\}
    \
    \\

    这个业务逻辑没有做什么事情啊。

    \\
    \

    这只是个例子。在实际实现业务逻辑的时候,不会有很多类似这样的类的。

    \
    \\

    好吧。那么Gateway是用来做什么的呢?

    \\
    \

    它为业务逻辑提供了所有访问数据的方法。下面是它的代码:

    \\
    \package businessRules;\import entities.Something;\public interface BusinessRuleGateway {\  Something getSomething(String id);\  void startTransaction();\  void saveSomething(Something thing);\  void endTransaction();\}
    \\

    要注意,这个接口是在businessRules包里面的。

    \
    \\

    好吧。那Something这个类又是用来做什么的呢?

    \\
    \

    它代表一个简单的业务对象。我把它放在另一个叫entities的包里。

    \\
    \package entities;\public class Something {\  public void makeChanges() {\    //...\  }\}\
    \\

    最后需要实现BusinessRuleGateway接口,这个实现类会知道相关的数据库细节:

    \
    \\
    \
    \package database;\import businessRules.BusinessRuleGateway;\import entities.Something;\public class MySqlBusinessRuleGateway implements BusinessRuleGateway {\  public Something getSomething(String id) {\    // 从MySQL里读取一些数据\  }\  public void startTransaction() {\    // 开始一个事务\  }\  public void saveSomething(Something thing) {\    // 把数据保存到MySQL\  }\  public void endTransaction() {\    // 结束事务\  }\}\
    \\

    可以看到,业务逻辑是在运行时对数据库进行调用的。而在编译时,是database包引用了businessRules包。

    \
    \\

    好吧,我想我明白了。你用多态性隐藏了数据库实现。不过在业务逻辑里,仍然引用了数据库的工具接口。

    \\
    \

    不,不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具接口,而是业务逻辑创建了它们所需要的接口。在实现这些接口的时候,可以调用相应的工具。

    \
    \\

    嗯,这样的话,如果业务逻辑需要所有的工具,那么你必须把所有工具都放到Gateway接口里。

    \\
    \

    哈,我觉得你还是没有明白。

    \
    \\

    不明白什么?我觉得已经很清楚了。

    \\
    \

    每个业务逻辑只定义它所需要的接口。

    \
    \\

    等等,什么意思?

    \\
    \

    这个叫作接口分离原则。每个业务逻辑只使用一部分数据库工具,所以每个业务逻辑只定义能够满足需要的接口。

    \
    \\

    这样的话,你就会有很多接口,而且有很多实现类。

    \\
    \

    哈,是的。你开始明白了。

    \
    \\

    这样子很浪费时间!我为什么要这样做呢?

    \\
    \

    这样做是为了让代码更干净,并且节省时间。

    \
    \\

    算了吧,这样只会增加更多的代码。

    \\
    \

    相反,这其实是很重要的架构决定,这跟你之前所说的那些所谓的重要决定是不一样的。

    \
    \\

    什么意思?

    \\
    \

    还记得你刚开始说你要成为一个软件架构师吗?你还想要做所有重要的决定?

    \
    \\

    是啊,我是这么想过。

    \\
    \

    你想做所有关于数据库、Web服务和框架的决定。

    \
    \\

    是啊,而你却说它们都不重要,还说它们其实跟重要的决定不相干。

    \\
    \

    没错,它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。

    \
    \\

    但首先要先决定用什么数据库、Web服务器或框架啊!

    \\
    \

    不,实际上应该在开发后期才开始做这些事情——在你掌握了更多信息之后。
    \哀,当架构师草率地决定要使用一个数据库,后来却发现使用文件系统效率更高。
    \哀,当架构师草率的决定使用一个Web服务器,后来却发现团队需要的不过是一个socket借口。
    \哀,当架构师草率地决定使用一个框架,后来却发现框架提供的功能是团队不需要的,反而给团队带来了诸多约束。
    \幸,当架构师在掌握了足够多的信息后才决定该用什么数据库、Web服务器或框架。
    \幸,当架构师为团队鉴别出运行缓慢、耗费资源的IO设备和框架,这样他们就可以构建飞速运行的轻量级测试环境。
    \幸,当架构师把注意力放在那些真正重要的事情上,并把那些不重要的事情放在一边。

    \
    \\

    我完全不知道你在说什么了。

    \\
    \

    好吧,如果在若干年后你还没有转做管理,或许会明白的……

    \
    \\

    感谢徐川对本文的审校。

    \\

    给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

    展开全文
  • (资深架构师: )好吧,如果这样,你就没必要成为一个软件架构师了。 (程序员:)当然有必要了!我要成为一个能够所有重要决定的人。 (资深架构师:)这样很好,只是你没有列出哪些才重要的决定。你刚才说的那些跟...
  • [size=medium]总是看到有很多人在各种论坛求教架构师要掌握什么什么的架构师没有多么高深,因为他们去了,去从无到有设计维护升级优化了一个系统,他就可以成为架构师了。 架构师这个名头一样的,但是每个...
  • 之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都非常值得参考的,不过感觉他们讲的更多的每次演变的结果,而没有很详细的讲为什么需要这样的演变,再加上近来感觉有不少同学都很难...
  • 本文一篇模仿问答的小故事,作者用幽默的风格简单分析了架构师的工作: 我想要成为一名软件架构师。 这年轻软件开发者很好的选择。 我想要带领团队,并在数据库与框架、webserver等方面作出重要...
  • 最新Web前端架构师

    2021-05-03 20:03:10
    第1周 需求分析和架构设计:做什么,如何做? 开工之前,先来看看我们到底要做一个什么项目,有哪些功能。然后站在上帝视角,从整体的架构层面,该如何设计该项目。 课程安排: 1、需求分析,到底要做一个什么产品 2...
  • WEB架构师成长之路

    2016-08-15 16:40:23
    牛人就是牛人,看了他写的,再回过头来想想,我为什么写不出来呢~ 来源地址:http://www.cnblogs.com/seesea125/archive/2012/04/17/2453256.html 赵学智@行胜于言 本人致力于学习面向对象、...
  •  一 、你必须学习面向对象的基础知识,如果连这个都忘了,那你的编程之路注定原始初级的重复! 很多程序员都知道类、方法、抽象类、接口等概念,但是为什么要面向对象,好处在哪里,要解决什么问题?只是...
  • 体系课-Web前端架构师

    2021-04-30 12:01:13
    第1周 需求分析和架构设计:做什么,如何做? 开工之前,先来看看我们到底要做一个什么项目,有哪些功能。然后站在上帝视角,从整体的架构层面,该如何设计该项目。 课程安排: 1、需求分析,到底要做一个什么产品 2...
  • 一 、学习面向对象的基础知识,那你的编程之路注定原始初级的重复!  很多程序员都知道类、方法、抽象类、接口等概念,但是为什么要面向对象,好处在哪里,要解决什么问题  降低软件开发的复杂度 提高软件...
  • 第1周 需求分析和架构设计:做什么,如何做? 开工之前,先来看看我们到底要做一个什么项目,有哪些功能。然后站在上帝视角,从整体的架构层面,该如何设计该项目。 课程安排: 1、需求分析,到底要做一个什么...
  • 第1周 需求分析和架构设计:做什么,如何做? 开工之前,先来看看我们到底要做一个什么项目,有哪些功能。然后站在上帝视角,从整体的架构层面,该如何设计该项目。 课程安排: 1、需求分析,到底要做一个什么产品 2...
  •  作为一名程序员,当亲戚问起职业的时候其实自己都不知道该如何描述,如果你说你是做Java开发或者web前端开发这一类说辞,家里人不仅听得云里雾里可能还会觉得这工作没那么好。正确的做法是回答在某某公司做工程师...
  • 一眨眼又到年底了,每到这个时候,我们都会慢慢反思,这一年都什么?有什么进步?年初的计划都实现了吗?明年年初有跳槽的底气了吗? 况且2020年我们经历了新冠疫情的洗礼,很多程序员都经历了失业,找工作的...

空空如也

空空如也

1 2 3 4 5 ... 13
收藏数 251
精华内容 100
关键字:

web架构师是做什么的