（一）第一篇：讲的是到底什么是架构，个人理解为：把一整体划分为不同角色，各尽其职，完成不同分工，这个整体完成所需要的各种活动。
然后通过一个早期的例子来笼统地概括他的出现。在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。那么为什么他会出现？必须由人执行的工作每个人的能力有限每个人的时间有限人对目标系统有更高的要求我自己理解：就是为了让工作效率达到最理想化。最终给出了他的定义：根据要解决的问题，对目标系统的边界进行界定。并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。并对这些切分出来的部分，设立沟通机制。根据前者，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
（二）第二篇：讲的是认识概念。架构实际上解决的是人的问题，而概念是人认识这个世界的基础，自然概念的认识就非常的重要。然而我认为在软件行业就是为了解决开发者的问题。每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。
（三）第三篇：讲的是识别问题。首先通过一则笑话：女主人公：老公，把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半，然后下锅。这让我们明白了沟通的重要性，那么在项目开发时沟通的作用更是发挥了很大的作用。所以我们真正需要识别的是问题的主体，问题隐藏的边界确定不下来，问题就不能确定，项目就不能进行。一般来说，从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。最坏情况就是当我们时间或者能力有限，实在是无法定位出是谁的问题的时候，比如系统出故障，也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本，尽量去隔离问题影响的范围。给我留出时间和空间去识别真正的问题。
（四）第四篇：架构切分。我们已经知道，随着社会的发展，分工是必然的。每个人做着不同的工作，也可以说做着自己更为擅长的工作，各尽其职。这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化。在这个模式下，每个人必须要舍掉自己的东西，才能够得到更多的东西。牛顿第三定律也告诉我们想走必须留下点儿东西。
（五）第五篇：讲的什么是软件。软件的产生就是人类在计算机上有意无意地模拟人的行为。软件早期是由程序员编写的，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。以下讨论的前提，都是基于帮助别人写程序，多人合作的基础上的。结论对于单人为自己写程序也适用。
（六）第六篇：架构要解决什么问题。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。
（七）第七篇：给架构师实权。架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个leader。但是只是民意上的leader是没有用的，不能完全发挥架构师的能量。架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。
（八）第八篇：如何写好代码。咱们做这一行的都知道，在做一个项目的过程中，编码是必不可少的。我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题。结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：表达业务逻辑的代码，对用户提供访问并保存业务逻辑运行结果的代码。
（九）第九篇：理清技术、业务和架构的关系。技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务。有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题。所以技术与技术之间，有两种关系：在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。
标签：架构,每个,概括,漫谈,技术,问题,解决,架构师 来源： https://www.cnblogs.com/jccjcc/p/12330802.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。