标签：聊聊架构--读后感
为什么会产生架构？
什么是架构？软件架构？
什么是架构师？软件架构师？
对于这些问题，不知道有多少人思考过，至少我以前没有细想过。现在一谈起“架构”，就觉得它是一个很高大上的东西。在读完这本书后，你会发现原来它无处不在，只是很普通，时常发生的一种事而已。
让我们来看看作者对这些问题的见解：
1、为什么会产生架构？
在这个问题上，作者首先阐述了一个概念“生命周期”：
简单说明，生命周期就是事物，从开始到结束、从生到死的过程。万事万物都有生命周期。
生命周期包含各种活动，活动的推进是生命周期的必要因素。
生命周期里面的活动拆分后，形成若干新的生命周期。
拆分后主体不变的是核心生命周期，变化了的是非核心生命周期。
生命周期拆分以后，因为非核心生命周期的主体已经发生变化。
主体便可以将这些非核心生命周期分配给其他主体代为执行。这样，生命周期从时间连续的执行变成了空间上并行，时间上串行的连续活动。
在说明了生命周期一后，作者进一步说明的促成架构产生的原因：
生命无常，虽然每个人个体的生命周期无法按自我意愿进行延长。但是，通过提高自身的能力以获得更多成就，产生对社会更多的贡献，这是另一种层面的生命的延伸。
按特点进行分工以后，生产力得到了提升。相对的人的生命得到了一定的延长。实际上按特长进行分工便形成了人类社会的架构。
从人类发展的历史过程看，人类从原始社会单独猎取事物到现在社会各展所长的发展过程，本质上都是为了让自身在有限的生命中获取更多的物质追求。
所以，人类追求利益是推动架构产生的根本，这确实是一个很给力的说法。
2、什么是架构？软件架构？
架构的思考来源于对生命周期的识别，以及对生命周期的拆分。架构是为了业务而服务，让业务更加高效，让业务更健壮，让业务更服务于更多的人。
软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式。
软件架构离不开软件开发团队的组织架构，这个组织架构是软件开发生命周期和软件运行生命周期的执行者。
3、什么是架构师？软件架构师？
人人都是架构师。在生活当中每个人或多或少的都在进行着业务的架构划分。比如，桌面的摆放，软件的顺序，到达某个点的路线。在阅读本书的过程后，从雾里看花，身在此山中的感觉中走了出来。发现架构无处不在，不管是夫妻之间，同事之间，朋友之间。根据不同的主体进行分析，了解他的主要问题所在，或者沟通的要点。将会给生活、工作带来莫大的帮助。
软件架构师需要去拆分生命周期，并要形成组织架构去落实架构执行，而且要平衡别人的利益，甚至去调整别人的利益。
对于软件的开发生命周期和软件的运行生命周期，软件架构师必须要具备权力去调整。这一点要求软件架构师必须是一个软件团队组织领导者的身份。
要想做好架构师的工作，就要向大自然学习，这样才能够认识到事物本身的生命周期，并能够去顺应事物自身的生命周期的规律来进行拆分，以达到增长的目的。
架构师很冷静、很平等地对待所以的技术，只选用合适的技术。技术人员喜欢热衷于某种技术，对其他技术嗤之以鼻
架构师是技术的使用者。技术本身没有好坏，因时因地而已
架构师拆分生命周期，技术人员实现生命周期。这就是为什么架构师需要有组织架构的权力，因为要确保架构拆分的落地。
技术是架构师手中的工具，当没有合适的技术时，架构师回去创造技术，或者催生出新的技术。
通过作者对3类问题的阐述，我们可以看出，他所描述的架构、架构师都别开生面，与我们平常说的有所不同。
作者认为架构的目的是为了实现某种业务，以达到让业务更加高效、健壮，让业务更服务于更多的人。而技术是架构的工具。架构师应该因地制宜的合理使用。
为了实现架构，架构师应该深入了解业务，然后对业务进行拆分以完成架构设计，然后再对组织架构进行相对的调整，合理分配管理相关人去实现架构。
这样的思路，看起来确实合情合理，软件架构设计是一个人的世界观、价值观的体现，别人是否会完全认同一个软件架构师的设计呢？（不用想，肯定有人会不认同） 那么，要想让设计成为现实，就需要足够的权力去落实。
在这里需要提出几个问题：
1、一个软件开发团队到底需要什么样的领导呢？
个人认为，人世间不外乎四种人：擅长做人的人，擅长做事的人，两者都擅长的人，两者都不擅长的人。不过这只是一种粗略的分法，人是一种很动态的生物，用确定的指标是无法描述清楚的，只是各有所长罢了。
就目前我所看过的书中，基本都认为“擅长做人的人更适合做领导”。用道理上来说，我也是这么认为的，只要用好形形色色有本事的人，又有什么做不好呢？
不过，现实中为什么软件开发团队总是是出现把软件做得不合适的情况呢？这只能说明，这种软件开发团队的领导并不是真正的“擅长做人的人”。
那到底什么样的人才是真正“擅长做人的人”？好人？坏人？擅长交际的人？幽默的人？逻辑性强的人？思维缜密的人？
这是一个没有确定答案的问题，每个人都有自己的见解，什么样的人都有可能性。因为这个世间的老板就是形形色色的，他们就是领导者的代表。（从结果导向逆向分析是个不错的思路）
2、如果你是一个软件团队的领导，但你不擅长架构应该怎么办呢？
其实在上面已经回答了这个问题，要么你有能力让自己变得擅长架构，要么去思考怎么样做一个真正“擅长做人的人”。
第一种办法，不用分析了，你自己办到了谁都拦不了你。
第二种办法，说白了就是找一个人擅长架构的人，让他去为自己做好架构。这种方式可以认为是放权管理。其实这是管理的最高境界，因为尺度很难把握，所以不容易做到。
3、如果让一个擅长架构的人去做团队的领导，会不会有什么问题？
其实在软件行业，这样的情况很多，好多团队的领导者都是优秀的工程师一步一步升上来的。有的人呢，最后会把团队管理的很好，其实这种人是在逐步学习“擅长做人”的本事，学有所成后最后转变成了 “擅长做人的人”或“两者都擅长的人”。还有一部分，团队会被管的乌烟瘴气。所以，世事无绝对，人类的可塑性是非常强的。只有最终的结果才能说明一切。
架构的实施是需要权力的，这是一个事实。现实中，高层期望软件开发团队的领导就是那个架构师。不过似乎总是事与愿违。 在IT行业，有很多的架构师，大家都认为架构师应该是某方面技术能力很强的那种人。其实这种人只能说是某方面的技术专家，而架构师应该是那些擅长将业务用适当的技术实现出来的人。
这就要求：第一、他们要弄明白业务，这一点在工作中其实是由产品经理去协助完成的，对于大多开发人员来说都不会太难；第二、他们要设计架构、选用技术方案把业务实现用来。往往差距就出现在了这里。
我们经常会遇到，有人选择了一个很新潮，或很复杂的技术实现了一个业务需求；或者是实现方案设计的不合理，造成有漏洞或者实现成本很高，浪费了很多的时间。
那我们究竟应该怎么样去选择合适的技术，怎么样去设计方案呢？ 我个人认为应该这样去思考：
1、利益才是选择的根本依据，我们选择一种新技术到底会给我们带来什么样的收益？收益是否大于代价？
2、对于架构设计，我觉得可以想简单一点。想象一个书架，如果把所有书乱七八糟的摆放，是不是会很难找到一本书？所以需要我们分门别类的去摆放书籍。 如果我们做了一个分类“科学”，这个分类的书有几百本，是不是又会很难找到一本书？这时就需要去把分类更加细化。 如果我们分出了几百个分类，是不是又会比较难找一本书呢？这时就需要产生大分类去管理小分类。 生活中的好多事物的管理都是如此，软件虽然比较虚拟，但是道理是一样的。把项目拆分成合理的大小，把代码规整的摆放好就是架构设计。 开发管理软件的目的就像管理书架中的一本书一样，现在不过变成了一段虚拟的代码而已。
本文出自 “风之痕_雪虎” 博客，请务必保留此出处http://snowtiger.blog.51cto.com/12931578/1947385
标签：聊聊架构--读后感
原文地址：http://snowtiger.blog.51cto.com/12931578/1947385
