约定编程：架构明显的编程风格.pdfVIP

约定编程：架构明显的编程风格 2.20.1 前⾔ 我们⼀直强调推荐让后台接⼜开发更简单。 所以，我们提供了PhalApi开发框架和WIKI⽂档。然后， 仅仅是个开始。 因为，真正发挥作⽤，实现价值的还是来⾃项⽬实际开发中的源代码。 但纵使我们提供了好的框架作为基础，但不得不承认的⼀个事实是：架构模型和项⽬ 代码随着各⾃的演进逐渐产⽣分歧。⽽ 种分歧，如果没有注意、管理和约束，则会 产⽣越来越混乱的代码。 在说明如何编写简洁的项⽬代码之前，让我们先了解⼀下PhalApi的架构思想以及主要 的设计意图。 2.20.2 开发-配置-使⽤ 模式 (develop-config-use pattern) 开发-配置-使⽤ 模式即：开发实现-配置注册-客户使⽤ 模式。 现分说如下。 (1)开发实现 开发实现的主要内容是组件、公共服务或者基础设施的功能实现，此部分主要针对⾼ 级开发⼯程师，或者有经验的PHP 同学。 例如对项⽬的接⼜签名的验证拦截、⼀个完成了对七⽜云存储接⼜调⽤的扩展、又或 者是项⽬内部加密的⽅案等， 些以包或者接⼜提供，为外部使⽤提供了配置说明、 使⽤⽰例和⽂档说明。更为重要的是，应该提供了配套的单元测试，并有着很⾼的代 码覆盖率。 此类实现应该是稳定的，即没有明显或者隐藏的BUG 。即使有，原作者也可以快速进 ⾏定位和解决，以及后期的扩展和升级。 (2)配置注册 ⼀旦上⾯的接⼜被实现后，不同的项⽬都可以轻松引⼊和使⽤。 块通常由项⽬的负 责⼈，或者主程来操作，因为在对项⽬进⾏构建部署、组件和环境装配时，需要考虑 到哪些组件需要被⽤到，以何种⽅式进⾏初始化和装载。 但使⽤的⽅式，应该是简明的。如简明的安装，简明的配置。所以， ⾥⾃然⽽⾔， 就涉及到了 依赖注⼊ ，DI 。 通过DI ，项⽬的负责⼈，可以轻松地将已通过严格测试的组件/服务注册进来。完成此 步骤后，⼀切都整装待发，剩下的就是使⽤的问题了。 (3)客户使⽤ 项⽬会不断有新的需求出来，⽽团队也会因此同步增加吸纳新开发同学进来负责新模 块新功能的开发。⽽新的同学，往往会是⼀些开发新⼿，他们需要使⽤已有的功能， 快速实现⼀些具体的业务逻辑、规则和功能。 但如果他们还需要实现⼀些基础重要的功能，又要考虑如何与现在项⽬整合，会分散 他们的关注点。⽽且，即使放⼿给他们去做，他们也会常常因为考虑不周或者编程风 格各异⽽产出⼀些与项⽬期望不符的代码。 若换⼀种⼯作的⽅式，即如果新⼿使⽤已有的组件进⾏⼀些特定领域业务的开发，会 是怎样？ 我想，会有很⼤的改观。 ⽐如，我们对新来的同学说，你使⽤DI()-logger就可以写⼀条⽇志了，如： DI()-logger-debug(app enter); 新⼿可能很喜欢追问⼀些问题，他可能会问及到，那怎么将⼀些参数 （当时⽇志的上 下⽂）也进⾏纪录呢？你可以很骄傲地说：也是可以的，你只需要 样写就可以了： DI()-logger-debug(app enter, array(device = iOS, versio (4) 建和使⽤分离 开发-配置-使⽤ 模式 也符合了创建和使⽤分离的思想。 不同的项⽬，不同的应⽤，需要的初始化服务不⼀样；不同的规模，对不同的技术解 决⽅案也不⼀样；不同的环境，配置也不⼀样。 但即使是 样，新⼿还是可以⼀如既往地使⽤之前注册的服务 （也就是不需要修改任 何调⽤代码）。也就是上层的调整或者环境变更 些，对新⼿的使⽤都是透明的。为 了更好地理解 些概念， ⾥补充⼀些案例场景。 以⽇志为例 假设我们有个项⽬A ，分别部署到内⽹测试环境和外⽹⽣产环境，显然内外⽹环境的 配置是不⼀样的。我们希望在内⽹环境为⽇志开启debug模式以⽅便开发⼈员进⾏调 试，在外⽹则希望将其关闭以减少系统的性能开销。在⼀开始使⽤⽂件作为⽇志存储 ⽅案时，对应的内⽹环境初始化代码如下： //⽇志纪录 DI()-logger = ne PhalApi_Logger_File(API_ROOT . /Runtime, PhalApi_Logger::LOG_LEVEL_DEBUG | PhalApi_Logger::LOG_LEVEL_I 在外⽹，我们只需要去掉PhalApi_Logger::L G_LEVEL_DEBUG 即可： //⽇志纪录 DI()-logger = ne PhalApi_Logger_File(API_ROOT . /Runtime, PhalApi_Logger::LOG_