前言
本篇文章是开启我写作之路的第一篇技术文章,有一些东西觉得可以和大家分享
如果文中有描述不合理的地方,望大家海量指出。
本系列文章我会根据我的实际项目经验谈谈以下内容
- 为什么要工程化
- 如何更好的组织业务代码
- 用
PHP
来构建一个基于微服务
的商城API
其中 实战
一节我将放在下一篇文章中去叙述 (Show Code)
为什么工程化
本篇谈及的工程化仅在代码组织和项目组织上的一些见解
我相信大家在多年的工作中一定接手过不少项目代码
从 搭建项目
到 维护项目
再到 开发新功能
这个过程中,我相信原先写代码的兄弟已经被问候多次。
我认为一个值得花时间去学习和研究的项目应该具有以下几点特征
项目结构组织明确
没有严格的按照工程层次划分目录, 随心所欲,导致冗余目录和相似功能目录增多,让人心里抵触。
我觉得一个良好的项目工程应该是经过系统的设计,并且他人从项目结构中可以轻易看出系统层次。
以一个微服务
中的工程标准,我一般会按以下结构组织代码
1 | markdown复制代码├─app // 服务APP |
工程化组织代码
代码组织混乱最常见的几种情况
- 变量定义不规范, 常量使用一堆
幻数
- 代码可复用性低
- 业务核心逻辑职责不明确
下面我会通过几段代码来说明一下工程化
组织带来的好处,希望借此抛砖引玉。
统一管理常量
项目中使用大量的数字来标识状态,会使他人接手项目的理解成本上线。
将常量的定义统一放到 类似 constants
的文件夹中统一管理, 我们可以轻易从项目角度去快速理解业务的上下文。
例如我需要一个类来专门管理这些订单的状态
根据上文中组织的项目结构,我们可以在 app/constants
中建立一个 OrderStatus.php
1 | php复制代码<?php |
用设计模式消除重复代码
重复的代码会让系统变得臃肿,难以维护,增加接手项目人员的负担
消除重复的方式无非是 封装
和抽象
我们站在工程的角度说明一下如何让一个充值的业务模块更直观从而减少重复
。
笔者之前接手过一个项目,其中充值部分包括 充值平台币
和 开通VIP
他们都需要支持 微信
支付宝
支付。
以下是项目中此业务的控制层代码 (部分代码经过处理)
1 | php复制代码<?php |
我相信大家已经看出了这段代码存在重复
并且不太符合 面向对象
的思想。
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
译: 软件架构的终极目标是,用最小的人力成本来满足构建和维护该系统的需求
站在工程化
的角度思考,就是我们该以何种方式去组织这一模块代码,让它 减少重复
并且符合 面向对象
的思想。
通过对业务的一些抽象, 为业务定义一个规范,并且遵守它。 形成一个上下游的概念。
这样我们就可以服务好我们上游的两个C Client
和 Controller
作为 Client 我们可以只用一个 充值
的接口就能调用我们所有下游业务提供的充值服务
首先我们需要一个 RechargeInterface.php
让充值业务都按照系统的标准去实现逻辑。
1 | php复制代码<?php |
接着我们根据业务建立两个类,分别是 VipRecharge.php
和 CoinRecharge.php
- VIP充值实现类
VipRecharge.php
1 | php复制代码<?php |
- 金币充值实现类
CoinRecharge.php
1 | php复制代码<?php |
最后我们需要一个充值服务对下游的业务进行管理。
1 | php复制代码<?php |
抽象永远是软件工程领域中最难的命题,因为他没有规则没有标准,甚至没有对错,只分好坏,只分是否适合。
这里仅以个人实际工作经验总结出来对代码工程化
的一些思考 。
如何更好的组织业务代码
Programs are meant to be read by humans and only incidentally for computers to execute
译: 代码始终是写给人看的,只是恰好能被计算机执行。
我相信,局部干净,核心逻辑简洁的代码一定是好的代码。
为什么提倡简洁? 对于我而言就是容易 单元测试
代码可控性高
试想一下一个业务逻辑里的代码冗余非常多的与该业务无关的代码,维护起来简直就是想开喷。
写到这一段时我首先需要感谢我的启蒙恩师 PIPO
, 是他在我初入这行时为我提供了不少宝贵经验,其中第一课就给我指导了代码工程的重要性,所以后期除了注重框架技术的学习,也更加注重代码工程的质量。
如何组织一个业务,让他能最小化的达到快速验收的目的?
分离业务中的主线和支线
在业务代码中,每个业务的主要逻辑都是一条主线,我们在编写每个业务逻辑时,应该要突出主线,分离支线,这样按照我们日常的思维才更容易去理解代码,如果你的支线代码变多,那么就会有种喧宾夺主的感觉,让我们无法轻易了解业务的内容。
分离业务主次方面我们可以通过
- 框架提供的中间件(Middleware)
- 事件(Event)
- AOP (面向切面去创建业务的连接点)
例如上面的充值服务
的充值方法中,我们就应该是 检查充值规则
, 抽取支付内容
, 发起支付
那么这个充值方法就应该只有简单的几行代码,而不应该在有诸如权限判断
, 支付方式实例判断
, 性能记录
等无关主线的代码。
分离业务代码和其他代码
业务代码通常是和业务逻辑相关的, 而诸如基础工具类代码, 日志记录代码, 这些应该和业务逻辑分开。
相同业务高内聚,不同业务低耦合
耦合是一种摩擦力, 太高的偶尔会使摩擦力变强,不易行走, 太低的摩擦力又无法正常行走, 所以根据你的业务控制耦合的高低也是做好业务代码组织的一种手段
就拿上面的充值模块
举例,充值服务是依赖于与支付服务
的,因为我们完成充值规则的校验和支付参数装配后,我们需要调用充值支付。
这时候我们可以通过依赖注入的方式,将 支付服务
注入到 充值服务
中
1 | php复制代码<?php |
这样做的好处是整个 RechargeService
我们可以轻易的做单元测试, 我们只需在单元测试的时候 Mock
支付服务类使其按要求返回结果即可。
1 | php复制代码<?php |
写在最后
一直没有时间好好输出一篇文章,之前一直考虑的问题是自己的表达能力和写作能力不到位,但是回过头来想想, 也只是输出自己的一些实际经验之谈, 算不上什么大作。
下一篇文章我会以这篇文章叙述的为基础,谈谈我是如何使用 PHP 来构建一个微服务。
用PHP
来谈微服务
总觉得有些格格不入, 主要是为了说明 PHP是世界上最好的语言
最好在写这篇文章的时候参考了
- 阿里技术号关于重拾面向对象的文章
- 腾讯技术关于业务代码实践的文章
两个业界标杆出品写的技术文章总是能让我从中学习到新的知识。
文章中的示例代码使用的是 Hyperf 框架,看了原作者做的Hyperf
教程视频,受益良多。
一杯咖啡,洋洋洒洒写了上千字, 好久没这么舒畅!
本文转载自: 掘金