首页 > 代码库 > 聊聊架构--读后感

聊聊架构--读后感

为什么会产生架构?

什么是架构?软件架构?

什么是架构师?软件架构师?

对于这些问题,不知道有多少人思考过,至少我以前没有细想过。现在一谈起“架构”,就觉得它是一个很高大上的东西。在读完这本书后,你会发现原来它无处不在,只是很普通,时常发生的一种事而已。

让我们来看看作者对这些问题的见解:

1、为什么会产生架构?

在这个问题上,作者首先阐述了一个概念“生命周期”:

       简单说明,生命周期就是事物,从开始到结束、从生到死的过程。万事万物都有生命周期。

       生命周期包含各种活动,活动的推进是生命周期的必要因素。

       生命周期里面的活动拆分后,形成若干新的生命周期。

       拆分后主体不变的是核心生命周期,变化了的是非核心生命周期。

       生命周期拆分以后,因为非核心生命周期的主体已经发生变化。

       主体便可以将这些非核心生命周期分配给其他主体代为执行。这样,生命周期从时间连续的执行变成了空间上并行,时间上串行的连续活动。

在说明了生命周期一后,作者进一步说明的促成架构产生的原因:

       生命无常,虽然每个人个体的生命周期无法按自我意愿进行延长。但是,通过提高自身的能力以获得更多成就,产生对社会更多的贡献,这是另一种层面的生命的延伸。

       按特点进行分工以后,生产力得到了提升。相对的人的生命得到了一定的延长。实际上按特长进行分工便形成了人类社会的架构。

从人类发展的历史过程看,人类从原始社会单独猎取事物到现在社会各展所长的发展过程,本质上都是为了让自身在有限的生命中获取更多的物质追求。

所以,人类追求利益是推动架构产生的根本,这确实是一个很给力的说法。

2、什么是架构?软件架构?

       架构的思考来源于对生命周期的识别,以及对生命周期的拆分。架构是为了业务而服务,让业务更加高效,让业务更健壮,让业务更服务于更多的人。

       软件架构就是通过对软件生命周期的拆分,在符合业务架构的前提下,以达到软件本身访问增长目的的方式。

       软件架构离不开软件开发团队的组织架构,这个组织架构是软件开发生命周期和软件运行生命周期的执行者。

3、什么是架构师?软件架构师?

       人人都是架构师。在生活当中每个人或多或少的都在进行着业务的架构划分。比如,桌面的摆放,软件的顺序,到达某个点的路线。在阅读本书的过程后,从雾里看花,身在此山中的感觉中走了出来。发现架构无处不在,不管是夫妻之间,同事之间,朋友之间。根据不同的主体进行分析,了解他的主要问题所在,或者沟通的要点。将会给生活、工作带来莫大的帮助。

软件架构师需要去拆分生命周期,并要形成组织架构去落实架构执行,而且要平衡别人的利益,甚至去调整别人的利益。

      对于软件的开发生命周期和软件的运行生命周期,软件架构师必须要具备权力去调整。这一点要求软件架构师必须是一个软件团队组织领导者的身份。

     要想做好架构师的工作,就要向大自然学习,这样才能够认识到事物本身的生命周期,并能够去顺应事物自身的生命周期的规律来进行拆分,以达到增长的目的。

     架构师很冷静、很平等地对待所以的技术,只选用合适的技术。技术人员喜欢热衷于某种技术,对其他技术嗤之以鼻

     架构师是技术的使用者。技术本身没有好坏,因时因地而已

     架构师拆分生命周期,技术人员实现生命周期。这就是为什么架构师需要有组织架构的权力,因为要确保架构拆分的落地。

     技术是架构师手中的工具,当没有合适的技术时,架构师回去创造技术,或者催生出新的技术。

通过作者对3类问题的阐述,我们可以看出,他所描述的架构、架构师都别开生面,与我们平常说的有所不同。

      作者认为架构的目的是为了实现某种业务,以达到让业务更加高效、健壮,让业务更服务于更多的人。而技术是架构的工具。架构师应该因地制宜的合理使用。

      为了实现架构,架构师应该深入了解业务,然后对业务进行拆分以完成架构设计,然后再对组织架构进行相对的调整,合理分配管理相关人去实现架构。

这样的思路,看起来确实合情合理,软件架构设计是一个人的世界观、价值观的体现,别人是否会完全认同一个软件架构师的设计呢?(不用想,肯定有人会不认同) 那么,要想让设计成为现实,就需要足够的权力去落实。

在这里需要提出几个问题:

1、一个软件开发团队到底需要什么样的领导呢?

     个人认为,人世间不外乎四种人:擅长做人的人,擅长做事的人,两者都擅长的人,两者都不擅长的人。不过这只是一种粗略的分法,人是一种很动态的生物,用确定的指标是无法描述清楚的,只是各有所长罢了。

     就目前我所看过的书中,基本都认为“擅长做人的人更适合做领导”。用道理上来说,我也是这么认为的,只要用好形形色色有本事的人,又有什么做不好呢?

     不过,现实中为什么软件开发团队总是是出现把软件做得不合适的情况呢?这只能说明,这种软件开发团队的领导并不是真正的“擅长做人的人”。

      那到底什么样的人才是真正“擅长做人的人”?好人?坏人?擅长交际的人?幽默的人?逻辑性强的人?思维缜密的人?

这是一个没有确定答案的问题,每个人都有自己的见解,什么样的人都有可能性。因为这个世间的老板就是形形色色的,他们就是领导者的代表。(从结果导向逆向分析是个不错的思路)

2、如果你是一个软件团队的领导,但你不擅长架构应该怎么办呢?

      其实在上面已经回答了这个问题,要么你有能力让自己变得擅长架构,要么去思考怎么样做一个真正“擅长做人的人”。

      第一种办法,不用分析了,你自己办到了谁都拦不了你。

      第二种办法,说白了就是找一个人擅长架构的人,让他去为自己做好架构。这种方式可以认为是放权管理。其实这是管理的最高境界,因为尺度很难把握,所以不容易做到。

3、如果让一个擅长架构的人去做团队的领导,会不会有什么问题?

       其实在软件行业,这样的情况很多,好多团队的领导者都是优秀的工程师一步一步升上来的。有的人呢,最后会把团队管理的很好,其实这种人是在逐步学习“擅长做人”的本事,学有所成后最后转变成了 “擅长做人的人”或“两者都擅长的人”。还有一部分,团队会被管的乌烟瘴气。所以,世事无绝对,人类的可塑性是非常强的。只有最终的结果才能说明一切。

      架构的实施是需要权力的,这是一个事实。现实中,高层期望软件开发团队的领导就是那个架构师。不过似乎总是事与愿违。 在IT行业,有很多的架构师,大家都认为架构师应该是某方面技术能力很强的那种人。其实这种人只能说是某方面的技术专家,而架构师应该是那些擅长将业务用适当的技术实现出来的人。

      这就要求:第一、他们要弄明白业务,这一点在工作中其实是由产品经理去协助完成的,对于大多开发人员来说都不会太难;第二、他们要设计架构、选用技术方案把业务实现用来。往往差距就出现在了这里。

      我们经常会遇到,有人选择了一个很新潮,或很复杂的技术实现了一个业务需求;或者是实现方案设计的不合理,造成有漏洞或者实现成本很高,浪费了很多的时间。

那我们究竟应该怎么样去选择合适的技术,怎么样去设计方案呢? 我个人认为应该这样去思考:

       1、利益才是选择的根本依据,我们选择一种新技术到底会给我们带来什么样的收益?收益是否大于代价?

       2、对于架构设计,我觉得可以想简单一点。想象一个书架,如果把所有书乱七八糟的摆放,是不是会很难找到一本书?所以需要我们分门别类的去摆放书籍。 如果我们做了一个分类“科学”,这个分类的书有几百本,是不是又会很难找到一本书?这时就需要去把分类更加细化。 如果我们分出了几百个分类,是不是又会比较难找一本书呢?这时就需要产生大分类去管理小分类。 生活中的好多事物的管理都是如此,软件虽然比较虚拟,但是道理是一样的。把项目拆分成合理的大小,把代码规整的摆放好就是架构设计。 开发管理软件的目的就像管理书架中的一本书一样,现在不过变成了一段虚拟的代码而已。


本文出自 “风之痕_雪虎” 博客,请务必保留此出处http://snowtiger.blog.51cto.com/12931578/1947385

聊聊架构--读后感