架构与设计专项测试

使用HTTP方法语义：GET用于获取资源，POST用于创建资源，PUT用于更新资源，DELETE用于删除资源

URL中包含操作动词，如 /api/getUser、/api/deleteOrder

使用复数名词表示资源集合，如 /users、/orders

在URL中传递敏感参数，如 /api/users?password=xxx

使用HTTP状态码表示响应结果，如200表示成功，404表示资源不存在

所有API都返回200状态码，在响应体中用自定义字段表示错误

API版本号放在URL路径中，如 /api/v1/users

API版本号放在请求头中，如 Accept: application/vnd.api+json;version=1

URL路径版本化简单直观，便于客户端理解和使用

请求头版本化更符合REST原则，URL保持简洁

版本升级时应该立即废弃旧版本，强制所有客户端迁移

应提供版本过渡期，给予客户端足够的迁移时间

不同版本API可以共存，使用路由分发处理

向后兼容的改动（如添加可选字段）不需要升级版本号

创建资源成功返回201 Created

删除资源成功返回204 No Content

客户端请求参数错误返回400 Bad Request

客户端未提供认证信息返回401 Unauthorized

客户端已认证但无权限访问返回403 Forbidden

请求的资源不存在返回500 Internal Server Error

客户端请求条件不满足返回409 Conflict

请求超时返回408 Request Timeout

使用Basic Auth将用户名密码放在请求头中

JWT Token应该设置合理的过期时间，并使用强密钥签名

API Key应该硬编码在客户端代码中便于调用

敏感API不需要任何认证，只需验证请求来源IP

重构应该在添加新功能之前进行，使代码结构更清晰

重构应该在修复Bug时进行，使代码更容易定位问题

重构应该一次性完成所有改动，避免多次提交

重构必须保持代码功能不变，外部行为不能改变

重构时应该同时修改代码结构和功能

重构需要测试保障，每个重构步骤都应该可验证

重构时机包括：代码难以理解、重复代码过多、方法过长

重构应该遵循"小步前进"原则，每次只做一个小改动

提取方法（Extract Method）：将一段代码提取为独立方法

内联方法（Inline Method）：将方法调用替换为方法体内容

提取变量（Extract Variable）：将复杂表达式结果存入临时变量

提升方法（Pull Up Method）：将子类方法移动到父类

降低方法（Push Down Method）：将父类方法移动到子类

重命名方法（Rename Method）：使方法名更清晰表达意图

封装字段（Encapsulate Field）：将公开字段改为私有并添加getter/setter

删除重复代码（Remove Duplicate Code）：直接删除所有相似代码

重复代码（Duplicated Code）：相同代码出现在多处

过长方法（Long Method）：方法超过10行就需要重构

过大类（Large Class）：类承担太多职责

过长参数列表（Long Parameter List）：方法参数过多

发散式变化（Divergent Change）：一个类因多种原因被修改

霰弹式修改（Shotgun Surgery）：一个改动需要修改多个类

依恋情结（Feature Envy）：方法过多使用其他类数据

数据泥团（Data Clumps）：多个数据总是一起出现

重命名速度更快，节省开发时间

自动更新所有引用，避免遗漏导致代码错误

可以同时修改多个文件的注释内容

自动生成重命名操作的Git提交记录

直接将整个单体应用拆分为几十个微服务

采用渐进式拆分，优先拆分边界清晰的模块

先建立微服务基础设施（服务发现、配置中心、消息队列）

拆分前确保单体应用有清晰的模块边界和接口定义

每次拆分一个服务后立即上线，无需验证

使用绞杀者模式（Strangler Pattern）逐步替换功能

数据库应该先拆分，再拆分应用服务

保持新旧系统并行运行，逐步切换流量

每个微服务应该围绕业务能力边界划分

微服务越小越好，一个服务只做一件事

服务边界应该与团队组织边界对应（康威定律）

高内聚低耦合是确定边界的核心原则

共享数据库表的服务应该合并为一个服务

服务间调用次数越少越好，减少通信开销

一个服务可以包含多个相关的业务实体

服务拆分后应该能独立开发、测试、部署

先保持共享数据库，应用服务拆分后再拆分数据库

使用数据同步机制保持新旧数据库数据一致

使用分布式事务保证跨服务数据一致性

最终一致性比强一致性更适合微服务场景

使用事件溯源模式解耦服务间数据依赖

数据迁移期间应该禁止用户操作

使用Saga模式处理跨服务长事务

读取数据时可以同时查询新旧数据库验证一致性

使用特性开关控制新旧系统切换，可随时回滚

架构演进完成后进行一次性全面测试

一次性切换所有用户到新系统

新系统上线后立即删除旧系统代码

单一职责原则(SRP)：一个类只负责一个职责

开闭原则(OCP)：对扩展开放，对修改关闭

里氏替换原则(LSP)：子类可以替换父类使用

接口隔离原则(ISP)：使用多个专门接口而非通用接口

依赖倒置原则(DIP)：高层模块依赖抽象而非具体实现

将所有方法都放在一个类中，便于统一管理

使用继承重写父类方法时，改变方法的预期行为

高层模块直接依赖底层模块的具体实现类

将用户管理类拆分为用户信息类、用户持久化类、用户验证类

将日志记录功能从业务类中提取为独立的日志服务类

一个类既处理业务逻辑又负责数据库连接管理

将报表生成逻辑从订单处理类中分离到报表生成类

将权限检查逻辑从控制器类中分离到权限过滤器类

一个服务类同时处理API请求、数据验证、数据库操作

将缓存管理功能提取为独立的缓存服务类

使用策略模式，通过添加新策略类来扩展功能

使用装饰器模式，在不修改原类的情况下添加新功能

使用继承重写父类方法来添加新功能

修改已有类的源代码来添加新的业务分支

使用模板方法模式，子类实现具体步骤

使用工厂模式，通过添加新工厂类支持新类型

在已有方法中添加if-else分支处理新情况

使用观察者模式，添加新观察者扩展行为

子类重写父类方法，但保持方法的预期行为不变

子类在父类方法基础上添加了额外的可选功能

子类重写父类方法时抛出了父类方法不会抛出的异常

子类实现父类的抽象方法，提供具体的实现逻辑