架构漫谈阅读笔记

         新的一学期又开始了,迈进了大三的后半学期,新的征程已经开始。

   仔细想想过去的两年半里面,反思自己的生活,学习,静下心来发现自己一无是处,玩的也不用开心,学也没学到啥,但是已经大三下半学期了,虽然自己也每天忙忙碌碌,学了java,C++,android,html等一些知识,但是总感觉自己欠缺的很多,学到的只是皮毛,如果以这种姿态去面对下班学期的找工作,显然是不足够的,自己可能还没有一个专科学生懂得多。人总是在即将面临困难的时候才知道困难来了,不能再这样浪费时间了,自己这学期必须做出改变,好好规划自己未来应该做什么,如何做,目标是什么。

IT行业总是变化很快,技术总是在不断更新,只要自己稍微落后一点,就可能赶不上时代的步伐被淘汰,然而一个程序员的能力和精力是有限的,每一个程序员在35岁之后都不可能和年轻人去竞争,因为那时候他已经没有能力和精力去消耗了,而公司也宁愿用廉价而且精力十足,能够加班任劳任怨的刚刚毕业的大学生,所以这时候程序员就会面临失业的情况,那么程序员该何去何从,这是每一个程序员应该考虑的事情。

       软件架构师,这应该成为每个程序员努力的方向,为了避免以后的日子失业,我们必须朝着架构师的方向努力。

那么什么是架构师?这里我举一个例子,比如制造一辆汽车,如果每个车间都要按部就班,一步一步的来将每个元件做好,然后在组装,就会浪费时间,每个车间都有自己擅长和不擅长的东西,如果我们让这些车间做自己擅长的元件,那么显然会加快效率,而架构就是相当于分工,将任务细化,最后再用一种特有的秩序或规则整合起来,形成一个整体,这就是架构的意义。而设计这些时,那些用来沟通的规则或秩序必须设计好,能确保每个边界即相互独立又能相互沟通。

       其实一个国家体系就是架构的完美体现,各个部门,行业,都是架构的完美体现,并且这个架构是可以随时改动,不断完善的。

       而做好架构最重要的就是理解概念,什么是概念,就是对一个物体一件事情的解释,但是有些时候世界是不清楚的,只能用抽象,或相似的同义词来形容描述这个物体或事件,而通过这些解释我们就能很好的理解全面的认识这个事物,挖掘出和之相关的一系列东西,进而才能够认识目标领域所需要解决的问题,这样才能够为做好架构打好基础。

   那么认识了概念,怎样正确理解这个概念所包含的问题,所需要被解决的问题。这就是要正确识别问题。而识别问题最关键的就是知道是谁的问题,解决什么问题,一个who,一个what,只有搞清楚这两个w,才能很好的识别出问题,确定出问题的边界。作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。找出问题的主体,是做架构的首要问题。这也是我一再强调的,我们要解决的问题,一定都是人的问题。更进一步,架构师要解决的,基本都是别人的问题,不是自己的问题。再进一步,我们一定要明白,任何找上架构师的问题,绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话,提问题过来的人肯定都能够自己解决了,不需要找架构师。架构师都要有这个自觉:发现问题永远都比解决问题来的更加重要。大部分时候我们会发现,其实真正解决问题的时间远比发现问题的时间要少很多,只要确定了问题是啥,一切就简单了,难就难在问题是什么。

       人与人之间最亲密的关系连接者就是利益。

       架构的切分的导火索是人的负载太重。

   架构的切分实际就是对stakeholder的利益进行切分或合并,使得每个stakeholder的权责是对等的,每个stakeholder可以为自己的利益负责。

      架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。

      架构切分的结果一定是一个树状,这也是为什么会产生分层。层数越多沟通越多,效率越低,分层要越少越好。尽可能变成一颗平衡树,才能让整个系统的效率最大化。

      软件的本质,其实就是通过把人类的日常工作生活虚拟化,减少成本,提升单个人员的生产力,提升人类自己的利益。软件工程师的职责在这个浪潮中,不堪重负,自然而然就分拆为不同的角色,形成了一个独特的架构体系。这一切的背后,仍然是为了提升人类自己的利益,解决人类自己的问题。

     这就是阅读了漫谈架构之后的体验,最后说一下,一定要努力,未来可期。

原文地址:https://www.cnblogs.com/zll20153246/p/8530024.html