架构设计读后有感—

架构设计读后有感——原则

news2024/9/25 23:24:15

成为架构时是程序员的梦想，并不意味着把编程做好就能够自然的成为一个架构师，他们之间有一个鸿沟->“不确定性”

不确定性：编程本质上说是不存在不确定性的，因为一个输入可以通过逻辑的运算得到确定的值，即使是机器学习，也许会出现上一次同一个内容识别出现不同的结果，但是机器学习的本质目的就是在提高机器的“确定性”

对于架构来说，本质上是不确定的。
- 同样的系统可能A和B公司的架构不同，都能运转
  - 选择的组件，选择的数据库都有可能不同，但是实现的功能可能都是一样的。
- 究其原因就好像人人都说的有道理，所以人人都不一样
架构设计不会有很多约束，开发的时候，我们很多时候都要按照语法要求去编程
- 但是架构设计不同，可能会面临选择，让人陷入两难的境地。
  - 每次对某个业务需求场景设计业务也会出现很多种解决方案，每个方案对应的痛点又不同，确实两难
  - Angular更强大，React很灵活，选哪个呢？
  - 团队熟悉MySQL，MongoDB更适合业务，选哪个呢？
还有很多的类似的问题，关键在于架构设计没有一套准确而有通用的规范来指导架构师进行设计。
业务千变万化，技术层出不穷，设计理念也是百花齐放，但是有其共性的原则：合适原则、简单原则、演化原则

🍞1 合适原则

合适优于业界领先

优秀的技术人员总想不断挑战自己，想达到甚至优于业界领先水平“设计了xxx方案，达到和Google相同的技术水平”
- 梦想很美好，现实很骨感
- 如果你所对标的团队不是一个量级，那么项目的开发过程和迭代将会是一个巨大的灾难
梦想是好的，但是要脚踏实地，一步一个大脚丫，体现如下

没那么多人，却想干那么多活，是失败的主要原因

大公司分工细，一个小小的系统模块就可能由一个团队负责，但是小公司，很有可能就是一个团队负责整个模块，一个人负责一个小系统

没有那么多积累却想一步登天，是失败的第二个主要原因

没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个原因

简单优于复杂

软件架构设计很考验技术，而同样考验技术的还有钟表，蒸汽机，飞机，手机等等，都做的越来越精细，越来越复杂
- 同样的，这些复杂度也给对应的物品带来了更精确，更稳定，更安全的特性，不能说这些复杂度一无是处，也许在他们的领域这种复杂度刚刚好
然而架构设计并不一定越复杂越好，越简单的情况下，做出同样功能的系统，这样的架构师的能力肯定是很强的
- 因为简单并且功能相同，那么以后的代码维护，架构升级也能更好做
- 简单意味着更容易理解，团队的压力也会减少，并且降低新人的认识难度
软件领域的复杂特性体现如下

结构复杂的系统特点：组成其的组件数量多，组件之间的关系更复杂

但是如果组件集中了，降低了组件数量，就会将所有的复杂度集中在一个系统中，那样的逻辑复杂性不亚于结构复杂性

为什么电路或者手机复杂度那么高却没有软件架构这些问题？

因为软件架构设计出来的系统会做迭代升级，而手机或者电路，只会在开始设计时有复杂度，而生产或者上线发布后就不会在变动

演化优于一步到位

软件架构wiki：从目的、主题、材料、和结构的联系上来说，软件架构可以和建筑物的架构相比拟

但是建筑物一旦完成，就不可再变，而软件去需要根据业务变化
- 明长城：自600多年前建成，还是当年的机构
- windows：1.0->3.1->95->XP->Vista->7->8->10->11
win1和win11的架构对比可以发现，这俩不是同一个东西了，可以发现建筑物和架构的本质不同，架构是可以进行升级改变的

对于建筑来说，永恒是主题；对于软件来说，变化是主题

如果没有把握“软件架构需要根据业务发展不断变化”的本质，就容易在做架构设计的时候陷入误区：试图一碗饭吃到寄

软件架构设计其实更加类似于大自然“设计”一个生物

架构设计原则1：合适原则，合适的架构优于业界领先的架构
- 真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理的将资源整合在一起发挥出最大功效
架构设计原则2：简单原则，简单的架构优于复杂的架构
- 软件领域的复杂性体现在：结构的复杂性、逻辑的复杂性
架构设计原则3：演化原则，架构需要随着业务变化而不断演化
- 对于建筑来说，永恒是主题；对于软件来说，变化才是主题
- 架构设计类似于生物演化

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2165103.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！