最近新开了一门课，叫软件体系架构，主要讲软件架构的有关问题。其实，早就听说过，也接触过，但是我对架构还是缺乏一定的认识，今天读了老师介绍的博客，才有了一定的理解。博客比较权威，但是并不是很晦涩难懂，作者通过一系列的例子，向我们讲述了有关构建的知识。博客叫《构建漫谈》，是资深构架师王概凯执笔，一共有九篇，逐步讨论了什么是构架、怎样做好构架、软件构架如何落地、如何写好程序等。这篇读后感大部分是自己的理解，也不知道对不对，以后还会继续加深理解。
首先，要学习架构，首先就得知道什么是架构。博客通过两个例子来给我们讲述，我看了之后的理解就是，架构就是为了提高质量和效率，把一个整体的任务分割成不同的部分，然后由擅长的人来担任各个子任务，并通过建立的沟通机制，有机的结合成一个整体，并达到了原来的要求。从例子看来，架构有一定的必要性，因为无论怎样，人们都会想办法提高效率，这样自然而然就产生了架构。
其次，要解决问题就得先识别出问题。我突然就想到了以前上软件工程概论课上，老师PPT上有一个例子，说的就是客户想要做一个秋千，最后的成品千奇百怪，并且都不满足要求。我觉得识别问题大概也是这个意思，不要一看到问题就想着解决方案就急着开始着手落实，最后的结果往往不尽如人意。开始解决问题前，起码得知道问题是什么，提出问题的人想达到什么样的效果，而不是你自己想的效果，这样才能事倍功半。
架构的切分，就是你认为多的话，就可以对它进行切分，但绝不能违背利益。切分的原则都很有道理，也很容易理解。大概就是说，一个整体的活动不能分；每个部分的负责人要对自己的部分负责；不能超过承担人的负荷；最后就是要对整个系统透明，不能篡改解决问题的初衷。看到这里，真的很佩服作者。这不是恭维，是真的很佩服这种可以大道至简的人。
然后就是软件构架要解决的各种问题，其中有业务问题。这不禁又让我想到我们老师曾说过他在帮医院做系统时，在那个医院里待了半年时间，为的就是了解医院的业务流程，这样才能了解问题所在，从而得出问题的解决方案。
接着就是对于架构师的理解，如果一个人他只致力于解决自己的问题，完成自己的工作，那么他不能成为一个架构师。因为架构师要知道，我们要解决的是别人的问题，不是自己完成工作的问题。如果别人的问题没有解决，即使我们自己的工作完成了，我们的工作实际也没完成，架构师得有全局观念。一个架构师要了解清楚自己的责任和义务，只有这样，才能做个合格的架构师。
最后就是一点关于技术与构架，以及与业务之间的关系的理解。技术是为了解决业务问题而产生的，在这个解决问题的过程中，技术本身也有了一定的进化，这是追求效率的结果。而在解决业务问题并提高效率的过程中，也就有了构架的产生。所以说，是先有技术再有构架。
以上就是我对架构的一点个人理解，还有一些地方不太懂，还会仔细再读《构架漫谈》。