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