今年新开始我们开始学习了软件架构这一学科,所以特地查看了一下以前的大神的博客园的博客,自己学习一下。
所谓软件架构师,其实就是一个能够根据客户的要求,结合实际能力,将客户的需求转换为专业的开发计划和一系列的要求文本,能够制定一个总体框架,领导一个小组完成这个开发计划,相当于一个计划的灵魂和指向者。
对于一个软件来说,软甲架构师决定了这个软件的全部,到底这个软件要如何设计都是由架构师提前架构出来的。
事实上,架构在软件发明时的N多年以前,就已经存在了,这个词最早是跟随着建筑出现的。所以,我觉得有必要从源头开始,把架构这个概念先讨论清楚,只有这样,软件行业架构的讨论才有意义。
为什么会产生架构,总的来说还是有这个需求,才会产生这个学科,一个人开始工作的时候,可以完成一件事,一群人完成一件事情的时候,每个人就会有独立的分工,每个人的时间有限,每个人的能力有限,所以复杂的目标,完成这个就需要架构,大概就是这个意思。从某种意义上讲,架构是人类发展过程中,从由懵懵懂懂的,被动的去认识这个世界,变成主动的去认识,并以更高的效率去改造这个世界的方法。
了解了什么是架构对于我们来说是十分重要的,构建实际上是解决人的问题,所以软件构架也不例外,最终的目的都是解决人的需求。
一名软件架构使得职责是什么呢?按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。当我们告知一个问题时会犯一些常见的错误,比如
1.被告知要处理一个问题,但是交过来的实际上是一个解决方案,不是问题本身。
2.被告知要处理一个问题,直接通过直觉就有了一个解决方案,马上考虑解决方案如何落地,或者有几种解决方案,选哪个合适。
作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。明白了问题的主体,这个主体就自然会带来很多边界约束,这个时候才算是真正的明白了问题。可以想象,这样下去最后的结果一定是大家都满意的,因为真正的问题解决了。只有真正明白了是谁的问题,才能够真正地完成自己的任务,真正地把自己的问题解决掉,而不是反过来。当问题的主体离架构师越远,就会让找出问题主体的过程越加困难。
如果要当软件架构师,必须要知道几点重要的事情,我们要确定要解决谁的问题,首先是业务问题
具体的现实生活状态下,没有软件的时候,所解决的问题的主体是谁,解决的是什么问题,是如何解决,如何运作的?
二、计算机问题
如何把现实生活用软件来模拟?
模拟出来的软件,需要哪些硬件设施才能够满足要求? 并且当访问量越来越大的时候,软件能否支持硬件慢慢长大,性能线性扩展?
因为硬件是可能会失效的,软件如何在硬件失效的情况下,仍然能够保证可用性,让用户能够不中断的访问软件提供的服务?
怎么收集软件产生的数据,为下一阶段的工作提供依据?
分别是谁的问题呢?
业务的owner需要提升业务的效率,降低业务的成本,这是动机。这个实际上就是业务的问题,所以一般软件开发的出发点就在这里。
是软件工程师的问题,要解决业务owner把业务虚拟化的问题,并且要解决软件开发和运营的生命周期的问题。
作为软件架构师,软甲当然是重中之重,软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件,后来慢慢的就有意识的去切分,演变成了不同的架构。这个背后的动力也是一样的,就是提升参与的人的利益,降低成本。导火索也是软件工程师的任务太重,我们需要把很多工作拆分出来。拆分的原则也是一样的,如何让权责一致。同样,这个拆分也是需要组织架构的调整,来保证架构的落地
软件的本质,其实就是通过把人类的日常工作生活虚拟化,减少成本,提升单个人员的生产力,提升人类自己的利益。软件工程师的职责在这个浪潮中,不堪重负,自然而然就分拆为不同的角色,形成了一个独特的架构体系。这一切的背后,仍然是为了提升人类自己的利益,解决人类自己的问题。
软件架构师,就是为了更好地完成这个过程