读后感

讲的是到底什么是架构，在我看来：就是把一整体划分为不同角色，各自完成自己的部分，最后有机的融合在一起。然后通过一个早期的例子来笼统地概括他的出现。在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。但是一旦多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情讲的是认识概念。架构实际上解决的是人的问题，举个例子，看到一个东西，比方说杯子，“杯子”就是一个名字，指代的看到的东西就是相，就是事物的相状。我们一听到“杯子”这个词，脑海里就会浮现出一个杯子的形象。而“杯子”这个词，是用来指代的是这个相状的，叫做名。合起来就叫做“名相”。每个概念都是因解决问题而产生的，最后我们把解决问题的解决方案，命名了一个名字，这个名字就是概念讲的是识别问题。首先通过一则笑话：女主人公：老公，把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半，然后下锅。每个人都做了很多工作，每个人都认为自己做的是对的，因此没有一个人对结果满意。因为真正的问题没有被发现，自然也就没有被解决，那么后续还得收拾残局，还要继续解决问题。事实上自己的工作并没有完成，反而更多了。把原因归结为沟通问题也是可以的，但对于解决问题似乎并没有太多的帮助。因为要改进沟通，这也是一个大问题。搞明白目标问题“是谁的问题，是什么问题”，当然也是需要沟通的。为了帮助自己更快的搞明白，首先要做的事是问正确的问题。架构师应该问的第一个正确的问题就是：目标问题是谁的问题。 在项目开发阶段，团队之间必备的就是沟通，如果沟通不好，项目组就会问题百出架构切分。我们已经知道，随着社会的发展，分工是必然的。每个人做着不同的工作，也可以说做着自己更为擅长的工作，各尽其职。这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化。在这个模式下，每个人必须要舍掉自己的东西，才能够得到更多的东西。牛顿第三定律也告诉我们想走必须留下点儿东西。讲的什么是软件。软件的产生就是人类在计算机上有意无意地模拟人的行为。软件早期是由程序员编写的，提高了自己的生产力，慢慢软件就变成了一个独立的行业。从最初的一个人完成，也逐渐变成多人分工完成。架构要解决什么问题。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化给架构师实权。架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个leader。但是只是民意上的leader是没有用的，不能完全发挥架构师的能量。架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。如何写好代码。作为一个软件工作者，无论干什么，编码是必不可少的。我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题。结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：表达业务逻辑的代码，对用户提供访问并保存业务逻辑运行结果的代码。理清技术、业务和架构的关系：技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求 -- 也就是业务。有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题，在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。