架构漫谈阅读笔记

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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