《架构漫谈》有感

　　今天阅读了博客园中的9篇博文《架构漫谈》，有些自己的体会。

　　架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。对于我们软件架构来说，就自我感觉架构就是在我们最初的编程基础上逐渐产生对某一方面的认识从而得到在这一方面编程的更为简单快捷的方法，最终能够提升我们整体的编程效率。架构的拆分与合并，换句话说现将整体任务分解为几个简单的任务，最后通过整合从而实现最大效率的提升。

　　通过阅读了这几篇关于架构的漫谈，我感觉架构对于我们程序员来说就是为了减少工作量，提升工作效率。我们做架构很多时候是为了解决一个新的领域的问题，我们都是从懵懂到精通然后根据经验衍生出处理某一问题的最简单有效的方法，然后加以整理得到做某件事情的一个先后规范，提升工作效率。

　　关于做架构，正如《架构漫谈》的作者说的，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的，找出问题的主体，是做架构的首要问题。进而我们要做的是去认清问题而不是花大部分时间在讨论解决方案和实现的细节上。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。一旦确定了主体，剩下的就是去搞明白主体有哪些问题。

　　紧接着我要说的是架构的切分，架构的切分的导火索是人的负载太重。同样这验证了我们为什么要使用架构，使用架构是就为了减少我们的工作量，提升我们的编程效率。

　　软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。架构实际上是在工作量不断的增大，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。

　　架构与技术的关系：语言和技术应该是随手拈来才对，对于架构师这些都是工具。学习技术和语言，如果明白了这些技术和语言要解决的是谁的问题，什么问题，学起来是非常快，非常容易的。

　　重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。我们在做某一软件的时候首先应该理清楚它的业务流程，没有业务，谈技术就是空谈，有了业务，然后才能运用技术解决问题，经过一定的摸索，逐渐能够通过某一方法提升效率，而由这些方法组成的过程也就逐渐形成了构架。