在这周的软件架构分析课上，老师着重为我们做了架构漫谈的概论引导，特意选了比较有代表性的章节来介绍架构、如何了解和学习架构以及如何正确清晰的认识架构，这将会使我们在思想上对架构有一个定位。仔细通读了架构漫谈的所有章节后深有感触，他以本人的实战经验为基础，讨论了什么是架构、怎样做好架构、如何写好程序的感悟，让我们从他的思想中定位架构。下面是我自己在读完所有章节后对如何正确的认识和理解架构、软件架构要解决的问题以及架构师该怎么做、理清架构同技术，业务，代码的关系这三点的一些浅薄的认识和感悟。
如何正确的认识和理解架构
架构，每个人都有自己不同和不同程度的认识和见解，但基础概念对于架构来说是非常重要的，有时候我们可能太过于相信自身潜意识下的认知，把自己长期状态下潜移默化的东西当成真正正确的概念，其实不然，那只是对特定的概念的一种称呼，他并不是怔怔的概念。那么为什么要引入概念这个词，所谓概念就是对一个事物的作用的概述，既然架构实际上解决的是人的问题，那么作用和问题的匹配就很重要，那么概念就自然而然的加入了进来。对于问题而言，在项目里工程里，我们不能只看到问题本身，还要有更清晰的认识:这是个什么样的问题、为什么有这样的问题、这个问题的本质是要解决什么问题，而不能盲目地将自身对问题的表面意思妄加处理，否则不仅不能是真正的问题得到解决，也白白浪费了时间和资源。接下来就是如何将上面谈到的问题进行分配。在一个项目工程中，问题是非常多喝复杂的，所以不能一个人从头到尾都亲力亲为，必然会有很多人来共同开发设计，那么就需要根据利益关系去进行切分，已计提的切分标准把项目化整为零，使个体和所劳相对平衡，这样才能解决一些不必要的和项目本身基本无关的问题。
总的来说，架构是根据要解决的问题，对系统目标边界进行界定，并且对目标系统根据一定的标准进行一定的切分，设立沟通机制，是的部分之间能够进行有机的联系，最终能够完成目标系统的所有工作。
软件架构要解决的问题以及架构师该怎么做
软件架构需要解决的问题就是软件的问题，那就涉及到了业务和实际业务模拟，即业务问题和计算机问题，也就同时涉及到了人:业务员和软件工程师的问题了。业务人员会考虑到业务问题的本质利益的问题，软件工程师则会考虑到他的业务利益所在，根据利益最大化的目标来解决现存的问题以及怎么来让软件能够在硬件上很好的运行。那么一旦开始，就涉及到设备、组件部署、设备连接、设备故障、数据分析等等问题，大多数情况下这不会是一个比较小的简单的业务，那么就会需要很多人来将系统差分成越来越多的部署单元来进行多人合作完成，最终再化零为整。
软件架构也不单单就是哪种拆分，可以是部署架构，也可以是代码架构等等，所以再说软件架构的时候一定要说清楚，同样它是需要组织和流程来保障的，否则就是一句空话。
之前理所应当的把架构师当成做架构的人，这种观点是极其错误的，一名合格的架构师旨在能够解决别人的问题，致力于克服对时间的恐惧和压力，对自己有信心，能够把完成别人的工作当成自己最大的利益，明白如何去发现问题，树立自信，只有从观念上抛弃只局限于把完成自己的工作当成自己的利益的观念，慢慢的在成功一次之后，就逐步走向了架构师的道路。在关注别人的问题的时候，不断进行思考究竟有什么问题，问题解决了谁会有收益，谁的收益大，只要让权责对等起来，便是一个架构师的高明所在。此外一名架构是还必须有组织领导人的能力和对技术的完美掌控，这个前面都说过了，这里就不再多讲了。
理清架构同技术，业务，代码的关系
因为有了架构，在代码的编写过程中我们需要更加有条理性，对模块编写素质的严格规范，抛弃以前不好的习惯，用于研究业务问题，将利益联系起来，有条理的去做每一件事。里面有一段话我感觉讲得很好，很贴合实际，形象生动。“业务选手，越想从水里浮起来，就越想把头抬起来，身体反而沉下去。只有克服恐惧，把头往水里压下去，身体才能从水里浮起来。真正专业的习惯往往是和我们日常的行为相反的”。
技术是为解决业务问题而产生的，目的都是为了人的利益，所以在面对一个业务问题的时候，高效低成本会成为首选，或者将之前的技术进行革新。这种准确识别采用的技术的能力也是架构是所要具备的能力之一。