架构整洁之道心得体会

1、软件架构是 系统设计过程中的重要设计决定的集合

2、走的快的唯一方法是走的好

3、软件架构的规则其实就是排列组合代码块的规则

4、底层设计细节和高层架构信息是不可分割的

5、软件架构的终极目标是:用最小的人力成本来满足构建和维护该系统的需求

6、一个软件架构的优劣,可以用它满足用户需求所需要的成本来衡量

7、软件工程师持续低估那些好的,良好设计的,整洁代码的重要性

8、胡乱编写代码的工作速度其实比循规蹈矩更慢

9、要想跑的快,先要跑的稳

10、清晰的认识并避开工程师们过度自信的特点

11、软件系统价值维度:

11.1、系统行为:紧急,但并不总是特别重要

11.2、系统架构:重要,但并不总是特别紧急

12、平衡系统架构的重要性与功能的紧急程度这件事,是软件研发人员自己的职责

13、软件系统的可维护性需要由我们自己来保护

14、软件架构师必须创建出一个可以让功能实现起来更容易,修改起来更简单,扩展起来更轻松的软件架构

15、软件架构师更关注系统的整体结构,而不是具体的功能和系统行为的实现

16、编程范式告诉我们应该在什么时候采用什么样的代码结构

17、三种编程范式:

17.1、结构化编程:对程序控制权的直接转移进行了限制和规范

17.2、面向对象编程:对程序控制权的间接转移进行了限制和规范

17.3、函数式编程:对程序中的赋值进行了限制和规范

18、科学与数学在证明方法上有着根本性的不同

19、测试只能展示BUG的存在,并不能证明不存在BUG

20、在架构设计领域,功能性降解与拆分任然是最佳实践之一

21、组件的独立部署能力决定了其独立开发的能力

22、面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制的能力

23、应用程序划分为可变与不可变的两种组件

24、为软件构建中层结构的主要目标

24.1、使软件可容忍被改动

24.2、使软件更容易被理解

24.3、构建可在多个软件系统中复用的组件

25、SOLID原则:单一职责原则,开闭原则,里式替换原则,接口隔离原则,依赖反转原则

26、任何一个软件模块都应该只对其某一类行为者负责,将服务不同行为者的代码进行切分

27、单一职责原则主要讨论的是函数和类之间的关系

28、开闭原则:设计良好的计算机系统用哪个个易于扩展,同时抗拒修改(在不需要修改的前提下就可以轻易被扩展)

29、高阶组件不会因为低阶组件被修改而受到影响

30、长方形与正方形问题,从数学角度与从生活角度看是不可用的

31、任何层次的软件设计如果依赖了它并不需要的东西,就会带来意料之外的麻烦

32、如果想要在软件架构设计上追求稳定,就必须使用稳定的抽象接口,少依赖多变的具体实现

33、源代码依赖方向与控制流方向正好相反,就是依赖反转的原因

34、组件是软件的部署单元,是整个软性系统在部署过程中可以独立完成部署的最小实体

35、插件化架构:组件化的插件架构已经成为我们习以为常的软件构建形式

36、复用/发布等同原则:软件复用的最小粒度等同于其发布的最小粒度

37、共同闭包原则:我们应该将那些会同时修改,并且为相同目的而修改的类放到同一个组件中,将不会同时修改,并且不会为了相同的目的而修改的那些类放到不同的组件中

38、将由于相同原因而修改,并且需要同时修改的东西放在一起,将由于不同原因而修改,并且不同时修改的东西分开

39、共同复用原则:不要强迫一个组件的用户依赖他们不需要的东西

40、不要依赖不需要用到的东西

41、无依赖环原则:组件依赖关系图中不应该出现环

42、稳定依赖原则:依赖关系必须要指向更稳定的方向

43、稳定抽象原则:一个组件的抽象化程度应该与其稳定性保持一致

44、软件系统的组成元素:策略、细节

45、策略:软件中所有的业务规则与操作过程

46、细节:指那些让操作该系统的人、其他系统以及程序员们与策略进行交互,但是又不会影响到策略本身的行为

47、一个优秀的架构师应该致力于最大化可选择项数量

48、系统需要按照其水平分层和用例进行解耦

49、解耦层次:源代码层次,部署层次,服务层次

50、边界线应该画在那些不相关的事情中间

51、将系统设计为插件式架构,就等于构建起了一面变化无法逾越的防火墙

52、划分边界就是指在模块之间建立这种针对变更的防火墙

53、一个策略距离系统的输入/输出越远,它所属的层次就越高

54、通过将策略隔离,并让源码中的依赖方向都统一调整为指向高层策略,我们可以大幅度降低系统变更锁带来的影响

55、业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程

56、软件的系统架构应该为该系统的用例提供支持

57、良好的架构设计应该只关注用例,并能将他们与其他的周边因素隔离

58、按照不同的关注点对软件进行切割

59、视图部分除了加载视图模型所需要的值,不应该再做任何其他的事情

60、架构设计的任务就是找到高层策略与底层细节之间的架构边界,同时保证这些边界遵守依赖关系规则

61、让代码避免与操作系统层产生依赖

62、一个优秀的架构师是不会让实现细节污染整个系统架构的

63、如果不考虑具体实现细节,再好的设计也无法长久

64、响应式设计:前期设计够用,后期进行大量重构

65、架构设计方法:按层、按模块、端口与适配器、组件

66、在区分架构好坏标准上达成共识是一件非常重要的事

67、系统架构设计的第一步是识别系统中的各个角色和用例

68、大型架构设计有时候会导致大型灾难

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值