看了架构漫谈这篇文章，使我感触很深。文章中先是从架构的起源来谈的。架构在软件发明之前就已经存在了，是随着建筑兴起的。早期的人类完全是自己自足的，各自干各自，都是独立的个体，互不往来。为了解决种族延续，于是出现男女群居，进而出现了分工。分工出现后，每个人的生产力都得到了提高，因为做的都是各自擅长的事。在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构的。一旦产生的分工，就把所有的事情，切分成由不同角色的人来完成，最后再通过交易，使得每个个体都拥有生活必须品，而不需要每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一定的交易能力即可。 这实际上就形成了社会的架构。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。这让我不禁想到，大二的软件工程课程上四人结组做的大作业，我们也是分工写的，也相当于一个最最基础的架构吧，分工合作的出现，于是产生了架构，就像老师说的，金山创始人之一求伯君最开始是自己一个人编的这个软件，那时候并没有架构，等到软件越做越大，合作出现的时候，才有了架构。架构实际上解决的就是人的问题。
认识概念是理解架构的基础，作者用“一个杯子的故事”引入概念的解释。概念也属于人认识这个世界并用来沟通的手段，包括“概念”这个概念，也是一样的。在古代，不叫“概念”，称之为“名相”。相实际上代表的是这个作用，并不是具体的某个东西，而名是用来标识这个作用的，用来交流的。所以说，每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。
其次就是识别问题。记得老师举得“切土豆”的例子，问这是什么问题，很多同学都回答沟通，或做土豆的问题，其实我开始也想的是沟通的问题，因为女主人没有表达清楚自己的意思，进而男主人切错了土豆。通过老师的讲解和阅读这篇文章后，我深刻的了解到：出现这个现象是由于我们大部分时候过于关注解决问题，急于完成自己的工作，而不关心“真正的问题是什么”而造成的。当我们去解决一个问题的时候，一定要先把问题搞清楚。文章中的一句话：“只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师”是我印象深刻，确实在以前的编程中都是按照老师给的题目，大致有一个解决方法就开始编写程序，并没关注问题的本身，跟别说思考了，都是通过直觉来解决问题的。所以，找出问题的主体，是做架构的首要问题，我们要解决的问题，一定都是人的问题。还有最重要的任何找上架构师的问题，绝对都不是真正的问题。如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。明白了问题的主体，我们才可能真正的认识问题是什么。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。一旦确定了主体，剩下的就是去搞明白主体有哪些问题。所以在以后要正确的认识问题，要注意两个方面:是谁的问题，有什么问题。
还有就是架构切分。所有的切分调整，都是对相关人的利益的调整。切分的过程就是建模的过程，每次对大问题的切分都会生成很多小问题，每个小问题就形成了不同的概念。这些不同的概念大部分时候人们自发的已经建好了，架构师更多的是要去理解这些概念，识别概念背后所代表的的人的利益。还有就是准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。
那么我们又应该如何写好代码呢，这篇文章中也说到了。我的认识就是，前台对用户的单独写一部分，相当于界面，然后业务逻辑的写一部分，数据库写一部分，相当于把软件代码分为三各部分。每个部分的职能都很单一，互不影响。就相当于我们这学期学的ssh框架。