概述
本文档列出了指导 Magento 2 开发团队成员的基本编码和应用程序设计原则。
Magento 核心开发人员在代码审查期间使用本文档作为参考；一些规则在 Magento 静态测试中有相应的代码检查。
这些指导方针来自多年的辛勤工作、经验和讨论。我们坚信新的技术举措应该遵循这些建议，并且应该改进现有代码以满足这些建议。
文本约定
使用 RFC2119 来解释关键字，例如：
必须和不得
必需的
应该和不应该
应该和不应该
受到推崇的
可能
可选的
一、基本编程原理
1.1.不应修改函数参数。
1.2.必须在函数上声明显式返回类型。
1.3.应该使用标量参数的类型提示。
1.3.1.所有新的 PHP 文件都必须启用以 declare(strict_types=1); 开头的严格类型模式。所有更新的 PHP 文件都应该启用严格类型模式。 PHP 接口可能有这个声明。
2.类设计
2.1.对象分解必须遵循 SOLID 原则。
2.2.对象实例化
2.2.1.一个对象必须在实例化后准备好使用。不允许使用额外的公共初始化方法。
例子：
2.2.2.工厂应该用于对象实例化而不是 new 关键字。出于测试或可扩展性的目的，对象应该是可替换的。例外：DTO。 DTO 中没有行为，因此没有理由对其进行替换。测试可以为存根创建真正的 DTO。数据接口、异常和 Zend_Db_Expr 是 DTO 的例子。
2.3.类构造函数只能有依赖赋值操作和/或参数验证操作。不允许进行其他操作。
2.3.1.当参数验证失败时，构造函数应该抛出异常。
例子：
2.3.2.不得在构造函数中触发事件。
例子：
2.4.所有依赖项必须由客户端对象所需的最通用的类型请求。
例子：
2.5.代理和拦截器绝不能在构造函数中显式请求。
2.6.不应使用继承。组合应该用于代码重用。
例子：
2.7.所有非公共属性和方法都应该是私有的。
2.8.抽象类不得标记为公共@api。
2.9.服务类（提供行为但不提供数据的类，如 EventManager）不应具有可变状态。
2.10.只有数据对象或实体（产品、类别等）可以有任何可观察状态。
2.11.不应使用“二传手”。它们只允许在数据传输对象中使用。
2.12. “Getters”不应该改变对象的状态。
2.13.不应使用静态方法。
2.14.必须避免时间耦合
示例#1：
示例#2：
2.15.必须避免类设计中的方法链。
2.16.应该遵守得墨忒耳法则。
2.17.图案
2.17.1.代理应该用于延迟加载可选依赖项。
2.17.2.当需要将树作为单个对象处理时，应该使用复合材料。
例子：
2.17.3.当有多种算法来执行一个操作时，应该使用策略。
- 依赖注入
3.1.对象之间不应该有循环依赖。
3.2. app/etc/di.xml 文件必须只包含框架级依赖注入 (DI) 设置。
3.3.所有模块化 DI 设置（表示层配置除外）应该存储在 <module_dir>/etc/di.xml 中。
3.4.所有模块化表示层 DI 设置应该存储在 <module_dir>/etc/<area_code>/di.xml 中。
4.拦截
4.1.仅当在某些情况下应该替换原始方法的行为时，才应使用环绕插件。
4.2.插件不应在自己的模块中使用。
4.3.不应将插件添加到数据对象中。
4.4.插件必须是无状态的。
4.5.插件不应该改变被拦截对象的状态（被拦截的对象是 $subject）。
- 例外
5.1.向最终用户显示的所有异常必须以以下格式生成错误消息：
症状
细节
解决方案或解决方法
5.2.异常不能在抛出它们的同一个函数中处理。
5.3.如果函数 A 调用函数 B，并且函数 B 可能抛出异常，则此异常必须由函数 A 处理或由函数 A 的文档块中的 @throws 注释声明。
5.4.异常不得处理消息输出。处理代码决定了如何处理异常。
5.5.业务逻辑（应用程序和域）不得使用异常进行管理。应该使用条件语句来代替。
5.6.异常类的短名称必须清晰、有意义，并说明异常的原因。
5.7.抛出的异常应该尽可能具体。顶级通用 \Exception 不应在任何地方抛出。
5.8.与第三方库的所有直接通信 M
本文来源于：
Magento2.x企业级开发实战
