读架构漫谈&我眼中的架构师

Posted 2021-02-12 mm20

      本周是开学的第二周，读了由资深架构师王概凯 Kevin 执笔的系列专栏架构漫谈。初识这门课，懂得也不是很多，读了架构漫谈，有了一些理解。

首先作者讲述了缘起，由早期人独立自主生活到后来的集群，作者由这个例子 引出人多力量大，每个人都有自己的独特本领：多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情。之后便由几个更加深入的例子讲述了自己理解的架构：

（1）根据要解决的问题，对目标系统的边界进行界定。

（2）并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。

（3）并对这些切分出来的部分，设立沟通机制。

（4）根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

       也是通过作者的几个例子，我也理解了架构最基本是什么。之后在读这个系列的内容，我开始认识“每个概念实际上所解决的，还是人遇到的某个特定的问题”，课堂我们也讨论了什么是“桌子”，大家给出的概念一开始我也认为让我说我也会这么说，可之后老师和我们再讨论，我也更加认识到“每个概念实际上所解决的，还是人遇到的某个特定的问题”，就比如桌子和椅子的高度也是有限定的，都是是解决人的问题。联想到软件也是解决人的问题，人的需求。作者之后便介绍到如何识别问题。做软件的最终要的就是认识到所有的需求，搞清楚需求，作者也说到：只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师 。然而现实是无论我们是敲代码还是别的什么工作，都会以自己认为对的方式完成自己的问题。这是极其糟糕的一面了吧。导致最后问题解决了是解决了，但是却跑偏了最初的目的，我们应该清楚认识到我们无论是做软件还是架构师在识别问题时，要解决的基本都是别人的问题，不是自己的问题。所以我们一定要先考虑到这一点，这一点我觉得是最重要的，也给了我们一个反思自己的机会，我们平时敲代码写系统是不是也是在解决自己的问题，我想是的。当然做架构师的下一步：调整利益。联想自己生活，每个人最擅长的肯定不是所有科目，这就需要同学之间的互帮互助了，也就是大家用自己擅长的东西去换取别人擅长的东西，扩大自己的利益（我终于在同学帮助下把这个bug改出来了！要不然不知道还能不能改出来！毕竟我一个人干这么一个大系统可能会有问题啊！）所以作者最后总结出：架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。咱们都是互相依赖的，这样每个人才会有多姿多彩的生活a!当然读这个系列的文章也带我们重新梳理了一下到底什么才是我们最熟悉的软件的问题。最后也由软件的产生加进了架构师的产生，还是和利益有关，自己的时间限制，任务繁琐，所以进行切分，互相依赖，好比盖房子，需要多个工种完成的。

         当然，架构出现了，架构师也就很重要了，没错，架构师必须是一个组织的领导人。架构师要解决的是别人的问题，不是自己完成工作的问题。架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。我认为一名架构师，在技术上需要有足够的自信，这样才能够去领导别人去做软件，同时也会受到信服。当遇到问题时，能提出解决问题的成本最低的方案，就是一名架构师应该做的。身为现在还在敲代码的我们，敲代码还是很现实很重要的事情，我们每个人看待代码的眼光、方式都不一样，作者介绍了从架构师的角度看待如何将代码写好：在写代码的过程中，最重要的就是逻辑方面的问题，不合理的逻辑结构，都会导致架构无法快速的横向扩展和分拆，并且增加了修改的成本，这些是不符合开发人员以及业务的利益的。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑，那么要马上意识到，这个地方是一个坑，这个问题一定和业务的分析不透彻有关系。最后介绍道：架构师应该承担起解决业务问题的这个角色，理清楚技术业务架构的关系极为重要。准确识别采用什么技术的能力，也是架构师所要具备的能力之一。

       通过读这一系列的内容，我也初步对“架构”以及架构师这个职业有了初步的了解，做软件的我们，要一点一滴做起，有了一个初步的认识，就要继续入门了。架构成长之路，开始吧！