这个礼拜，我精读了架构漫谈这本书，感觉自己对架构方面的知识有了更为深刻的了解。感觉学习了架构之后，能对自己的学习和实践有更大的帮助。在这个学期众多的结组任务中，我们可以通过架构的知识，来界定小组目标系统的边界，并将目标系统进行切分之后再把相应的任务分配给组员，这样可以让小组有机地联系起来并进行合作。接下来是我对架构漫谈的一些学习的心得。
首先，读一本书我们要明白的第一件事情就是我们为什么要读，我们需要从书中获得怎样的收益。相同的，这本书的标题是架构漫谈，所以理所当然的我们应该首先认识一下，什么是架构而我们为什么要应用架构。所以到底什么是架构呢，书中给出了明确的总结：1.根据要解决的问题，对目标系统的边界进行界定；2.并对目标系统按某个原则进行切分，切分的原则要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间；3.并对这些切分出来的部分，设立沟通机制；4.根据3，使得这些部分之间能够进行有机地联系，合并组装成为一个整体，完成目标系统的所有工作。所以架构到底有什么用呢？其实，架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动，而架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
在了解了什么是架构和架构是用来做什么的之后，就像老师上课所提的问题一样，我们应该明白如何做好架构之识别问题，这是一个架构的基础和核心所在。就是上课的的那个笑话例子来说，老师叫了五名同学起来回答，什么是问题的本质，但是大家都没有看到关键所在，所以都没有答出正确的答案。其实，出现这个现象是由于我们大部分的时候都过于关注解决问题，急于完成自己的工作，而不关心“真正的问题是什么而造成的”。当我们去解决一个问题的时候，一定要先把问题搞清楚。这也是我为什么要单独写一篇文章讲这个的原因。去看看软件开发工作者的时间分配也可以看出，大家大部分时间花在讨论解决方案和实现的细节上，基本都不会花时间去想“问题是什么”。或者即使想了一点点，也是一闪而过，凭自己的直觉下判断。只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师。那么如何识别问题呢？所有的概念基本都有一个很大的问题，就是缺乏主语。而我们大家都心照不宣的忽略这个主语，沟通的时候也都以为大家都懂得对方说的主语是谁，结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才是有意义的。
在上课的时候，老师让我们仔细阅读了架构漫谈的第八章：从架构的角度看如何写好代码。在我们之前的学习编码中，我们并没有对架构的概念，所以就上个学期软件需求分析的大作业来说，一开始编程的时候并没有想太多，就是针对各个不同的功能来设计了页面就行了，结果在之后需求不断变更和要求不断增加的时候，才发现很多的时候都要对自己的代码推翻了重新编写才能更好地去解决问题，不然有些问题根本是难以实现，所以就感觉上个学期的工作量特别的大，这实际上就是当初为了完成任务，没有充分思考所带来的后果。就像书中作者游泳教练所说的道理一样“业余选手，越想从水里浮起来，就越想把头抬起来，身体反而沉下去。只有克服恐惧，把头往水里压下去，身体才能够从水里浮起来。真正专业的习惯往往是和我们日常的行为相反的”。我们真正想要快速地完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，如果我们越是想节约时间来应付差事，我们就越会花更多的时间去解决因为应付而产生的问题。
通过了对本书的精读，让我了解到了架构的重要性。在本书中，我理解了架构的真谛：架构之识别问题和架构之架构切分。希望通过以后对架构的更深刻的学习，能够提升自己发现问题和思考的能力。
