zoukankan      html  css  js  c++  java
  • 阅读王概凯老师架构漫谈系列总结

    这学期在学软件体系架构的课程,老师推荐了王概凯老师的架构漫谈系列专栏,在阅读专栏之后,对于什么是架构,怎样做好架构,软件架构如何落地,如何写好程序等问题有了较深的理解,在此简单记录一下阅读之后的感想

    架构漫谈第一篇主要在介绍什么是架构以及为什么会产生架构,在没有阅读文章以前,在学习中或许用到过架构的思想,但也是模棱两可,并不知道什么是架构,更不清楚是怎么产生架构的。王概凯老师提到,架构是把一个整体切分成不同的部分,由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动。在不严格角度来讲,就像我们学习中有很多情况下是在分工合作,与同学组成的团队一起做项目,想要合理的分工,并最终将软件做好,就需要做好架构,将每块部分功能分解,识别问题,拆分出来的各个部分和合并所对应的角色和所需要的核心能力等去有目的,主动的识别问题,并进行分解,合并,结果这个问题。

    架构漫谈第二篇主要介绍了概念的内容,如何有效的去认识概念,明白概念背后的含义,以及如何利用对概念的理解,快速的进行学习。概念很重要,如果没有办法理清一些基础概念,混淆,会导致实际做架构时,角色沟通,工作安排会出现很多问题,自然工作结果也就不会乐观。每个概念实际上解决的,还是人遇到的某个特定的问题,我们把解决问题的解决方案,给定了一个名字,这个名字就是对应的某个特定的概念。不管是处于一个怎样的身份和地位,想要做好架构,就必须要正确的认识概念,能够发现概念背后所代表的问题,,进而才能认识目标领域所需解决的问题。在这个问题上我需要努力的还有太多!

    架构漫谈第三篇在讲如何做好架构之识别问题,王概凯老师认为能够识别出需要解决的问题,问题就已经解决了80%了,这个能力基本决定了架构师的水平。而识别问题的一大前提就是要搞清楚是谁的问题,这个搞清楚了,问题的边界也就确定了,再去讨论问题才有意义。一个合格的架构师应该问的第一个正确的问题是:目标问题是谁的问题。如果我们发现在工程项目中,正在致力于完成自己的工作,要马上警惕起来,因为这样下去会演变成没有ownership的工作态度,在面对概念的时候,也会不求甚解,最终导致没有理解正确概念。总之总结在正确认识问题的角度上,需要问两个问题,是谁的问rr‘’题,有什么问题。读到这里我开始有些不明白,这是谁的问题,在我现在看来很难判定,比如谈到切土豆这个问题,想要一把锤子这个问题,就反复理解很多次,也还只是模棱两可。

    架构漫谈第四篇主要讲是如何做好架构之架构切分。维护自己的利益每个人不能逃避的一点,随着社会的发展,分工是必然的,每个人都想将自己的利益最大化,所以需要分工,用自己擅长的东西去换取别人擅长的东西。如果需要在这个社会上立足,判断标准就变成了如何给这个社会提供更好更有质量的服务,提供更多更好的服务,自然就能够换取更多更好的生活必需品,和我们做人的道理是一样的。我们要舍弃自己的一些东西,去和别人交换,如果不想依赖别人,不愿与别人交换,他就会辛苦很多,生活会差的多。

    架构漫谈第五篇主要是将什么是软件。软件的历史,实际上可以说是用机器人模拟人的历史,我们在有意无意的在计算机上模仿人类的行为,从冯诺依曼结构开始,程序逻辑开始脱离硬件,采用二进制编码。加上存储。软件开发就开始有分工了,行业知识和业务的识别,会交给BA,系统的设计会交给架构师,设计的实现交给架构师,实现的检验交给测试,还有很多其他角色的配合,为了组织这些角色的工作,还有项目惊雷,这就把原来一个人的连续工作,拆分成了不用角色人的连续配合,演化成了不同的软件开发的模式,然后慢慢演变成专门为别人开发软件的的软件公司。软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件,后来就慢慢有意识的去拆分,演变成了不同的架构,这个背后的动力也是一样的,就是提升参与的人的利益,降低成本。导火索也是软件工程师的任务太重,我们需要把很多工作拆分出来。拆分的原则也是一样的,如何让权责一致,这个拆分也需要架构对的调整,来保证架构的落地。

    架构漫谈第七篇讲了怎样成为架构师的前提条件,如何发现是谁的问题,架构师的权利和义务话题。架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。架构师要去平衡别人的利益,甚至会调整别人的利益,一旦架构师是全心全意的为别人的利益服务,自然而然的架构师就拥有了强有力的影响力,肯定会是一个leader。但是只是民意上的leader是没有用的,不能完全发挥架构师的能量。

    架构漫谈的第八篇讲了从架构的角度看如何写好代码,当我们有了好的架构,那就需要考虑如何将架构落地,而这个时候,代码就显得无比重要了,千万不要让代码成为架构扩展的瓶颈。软件架构实际上包括了代码架构,以及承载代码运行的硬件部署架构,实际上,硬件部署架构最终还是由代码的架构来决定,因为代码架构不合理,是无法把一个运行单元分拆出多个来的。

    架构漫谈第九篇讲了理清技术、业务、架构的关系,技术总是在人类解决对业务要求不断提高的情况下产生,目的也是为了获取更大的利益。业务是技术的前提,技术与技术有相互制约的关系,按照前面的架构定义,这个时候其实已经产生了架构,一般先有技术,才会有架构。

    阅读完王概凯老师的架构漫谈自己真的成长了很多,要多阅读,多积累,加深自己对软件行业的理解!

  • 相关阅读:
    Visual Studio 2019 使用 Web Deploy 发布远程站点到IIS服务器
    postman下载地址
    ASP.NET Core开发-Docker部署运行
    C# ffmpeg 视频处理格式转换具体案例
    C# ffmpeg 视频处理格式转换和添加水印
    C# ffmpeg 视频处理
    Tomcat 安装与配置
    Maven 快速入门
    Jenkins 快速搭建
    Google SRE 读书笔记 扒一扒SRE用的那些工具
  • 原文地址:https://www.cnblogs.com/ggrm/p/10521662.html
Copyright © 2011-2022 走看看