极客时间-左耳听风-软件开发与架构设计的原则

软件开发与架构设计的原则

PS：内容为左耳听风的读书笔记，该节内容多为作者职业生涯的总结，平时需要反复提醒自己，细看内容其实有很多需要慢慢体会。

软件开发

不重复性

只要相似的代码出现不止一处，就必须将其共性抽象出来，形成唯一的方法

KISS原则

大道至简原则，例如宜家简约且高效的设计和生产方式

面向接口而非实现原则

1. 注重接口而非实现，依赖接口而非实现
2. 组合优于继承

命令查询分离原则

当一个方法通过返回一个值来响应一个请求的时候，就具有查询的性质
当一个方法要改变对象状态的时候，就具有命令的性质
在设计时应该尽量使接口单一化，保证方法的行为严格限于命令或者查询

按需设计的原则

只设计必需的功能，避免过度设计；只实现目前需要的功能，以后需要的功能以后再添加

迪米特法则

最少知识原则，概括为不要和陌生人讲话

正式表述为：对象O中的一个方法M，应该只能访问以下对象中的方法：

• 对象O
• 与O直接相关的组件对象
• 由方法M创建或实例化的对象
• 作为方法M的参数的对象

SOLID原则

1. 单一职责原则：一个类应该只承担一个职责，并且应该把这个职责尽可能地履行好，是高内聚低耦合原则的引申
2. 开闭原则：模块应该可扩展但不可修改，模块对扩展开放，而对修改封闭
3. 里氏代换原则：子类型必须能够替换父类型
4. 接口隔离原则：在接口中而不是在类中实现功能，而且使用多个专门的接口比单一的总接口更好
5. 依赖倒置原则：高层模块不应该依赖于低层模块的实现，而应该依赖于高层的抽象

共同封闭原则

一个包中所有的类应该对同一种类型的变化关闭。简单而言，一起修改的类应该组合在同一个包中

共同重用原则

不应该将未被重用的类和重用的类组合在一起

好莱坞原则

控制反转或依赖注入DI

高内聚低耦合

约定优于配置原则

约定优于配置原则倡导一些公认的配置方式和信息作为内部的默认规则来使用

关注点分离

在软件开发中通过各种手段将问题的各个关注点分开。一个问题被分解为独立且较小的问题时往往更容易得到解决。

契约式设计原则

对于类的一个方法，其契约中都存在一个前提条件以及后续条件

前提条件用于说明方法接受什么样的参数数据
后续条件说明这个方法完成时的状态
即：期望的是什么，要保证的什么，要保持的是什么？

无环依赖原则

解决了包之间的关系耦合问题

架构设计

关注收益而不是技术

• 降低技术门槛，加快整个团队的开发效率
• 让整个系统运行得稳定 → 需要对有计划和无计划的宕机提出相应的解决方案
• 通过简化和自动化来降低成本

如果系统架构不能在以上三点发挥作用，就没有意义了

以服务和API为视角

公司存在运维和开发两个角色，需要有统一的视角和目标即从服务和API的角度看问题(作为后端开发需要学习并掌握K8s)

选择主流和成熟的技术

大部分情况下选择Java没错

完备性比性能重要

• 优先使用科学，严谨的技术模型，只以不严谨的模型作为补充，例如用ACID的关系数据库，然后用NoSQL做补充
• 不必过分担心性能问题

制定并遵循标准规范

• 服务间调用的协议标准和规范：Restful API路径，状态码等等
• 一些命名的标准和规范
• 日志和监控的规范：日志格式，监控数据，采样要求，日志报警等等
• 配置的规范：操作系统配置，中间件配置，软件包配置等
• 中间件使用规范
• 软件和开发库版本最好在整个组织架构内每年升级，然后在团队内保持统一

重点强调：

1. Restful API的规范非常重要
2. Zipkin链路追踪，监控系统宁愿瘫痪也不干扰业务应用
3. 每年至少要有一次软件版本升级的评审

重视可扩展性和可维护性

1. 通过服务编排来降低服务之间的耦合
2. 通过服务发现或服务网关来降低服务依赖带来的运维复杂度
3. 遵循软件设计原则和最佳实践 → SOLID，SOA或Spring Cloud等架构的实践

对控制逻辑全面收口

控制逻辑：是用来决定程序是多线程还是分布式，使用数据库还是文件，以及如何实现配置，部署，运维，监控，事务控制，服务发现，弹性收缩，灰度发布，高并发等。

不要迁就技术债务

1. 使用老旧技术
2. 不合理的设计
3. 缺少配套设施

不要依赖经验

1. 用足够多的时间查找相关资料
2. 收集，对比各家公司或开源世界的做法
3. 比较各种方案的优点后形成自己的决策

提防与应对X-Y问题

实际上遇到的问题是X，却误认为需要解决Y，追问原始需求可以帮助我们找到真正的问题。

对新技术激进胜于保守