专做企业的p2p网站,wordpress 顶部图片,网址导航源码,网站端和移动端分开建设域名一样么背景
无论是前端代码还是后端代码#xff0c;都存在着定位困难#xff0c;不好抽离#xff0c;改造困难的问题#xff0c;造成代码开发越来越慢#xff0c;此外因为代码耦合较高#xff0c;总是出现改了一处地方#xff0c;然后影响其他地方#xff0c;要么就是要修改…背景
无论是前端代码还是后端代码都存在着定位困难不好抽离改造困难的问题造成代码开发越来越慢此外因为代码耦合较高总是出现改了一处地方然后影响其他地方要么就是要修改一个逻辑结果耗费了大量时间进行改造代码写得耦合较高造成这种情况的原因无非就是程序员本身没有管理者的思维喜欢取巧合并凑数偷懒造成的说白了想比做的少更多的是先动手去干而不是先想好过去/现在/未来三种情况再干这样撸着撸着就会将代码撸得让自己越来越反感越枯燥
新语法高阶语法无心尝试这些东西并非为了装逼用大佬创造他们并设为标准就是为了解决代码可能存在的问题。 问题一顺向思维
需求交接后并不对旧逻辑 新逻辑进行整合过滤而忙于添加一个 if...elseif 就着手开发了一个例子就是智能养号拿到需求后快速得出 3 个按钮的组合是 4 种可能实际上整体思考后会发现其中 团队开关开启和互养池开关开启 只走互养池逻辑也即 3 个逻辑。
以下是伪代码主要讲述主逻辑展示的必要性子逻辑仍然要遵循一条线法继续拆分函数直到最小颗粒度的函数体才去实现而函数体不应该超过 100 行否则很有必要继续拆分
router.post(/target-wid)
async def get_target_wid(user_id: int Depends(get_user_id),company_id: int Depends(get_company_id),item: TargetWhatsappIdGetParam Body()
):第一层代码纯主逻辑 绝无细节 未来还可能有更多主逻辑而未来追加新逻辑链路只是再加一行代码而已第一层逻辑绝无 elsif 因为要一条线到底if huyang.switch:return huyang.match_numbers()if team_huyang.switch:return team_huyang.match_numbers()return selfyang.match_numbers() 问题二不封装函数
无论是前端还是后端现在都已经有了面向对象的概念尤其是 ES6 的存在相同逻辑的东西可以封装成函数但是目前前端的代码封装密集度不够。仍然是面向过程的开发。 问题三面向对象
python 本身已支持面向对象而后端程序员都是科班出身同时又都学过 java但是代码写得不尽人意仍然是赤裸裸地面向过程更别提面向切面了连个装饰器都没有尝试写过真的不需要吗还是懒得去总结代码划分出来这些东西
model 是什么
model 是编程语言映射数据库字段的中转对象将 mysql 二进制字符对应转化为编程语言的类型每条记录对应一个 model model 是编程语言对象是对象除了属性还是有行为行为就是静态函数或者成员函数 静态函数往往处理本表的一些转换性操作例如创建对象时的前置数据处理保存对象前的前置处理获取对象后的后置处理都是静态成员函数的工作不针对于某个对象而是针对于所有对象的面向切面的操作 成员函数往往是对于从数据库查询了特定记录针对这一条记录进行数据的处理处理完成后返回某值或者入库 以上两个操作都是 model 的操作范畴
service 是什么
service 是针对功能模块下的一堆逻辑的操作集合它含有各种函数又可以将各种函数进行组合再构成新函数主要的目的就是将逻辑进行最大化的封装不暴露细节而细节都在私有函数里
举个例子我想下单那么就有 OrderServiceOrderService 对外提供一个 public 函数createOrder(orderInfo, userId),那么 OrderService.createOrder(orderInfo, userId),创建完订单后还要干什么那就是其他各种公共函数了createOrder 函数里面例如提取可用优惠券drawCanUseCoupons(userId)这个就是私有函数提取后还得计算优惠券的匹配情况 getMatchCoupons(orderInfo, coupons)等等各类私有函数这些私有函数在取消订单时也会用到但是你单独使用 drawCanUseCoupons(userId),例如用户卡券包这时你发现可以再抽出一个 UserService将drawCanUseCoupons(userId)挪过去因为这个跟订单信息无关跟用户信息有关这就是 Service
service 存在意义
service 存在意义是将需求主逻辑变得特别简洁易懂不暴露任何细节如图
这是一个巨复杂的创建订单的前置校验如果我直接将 createOrder 暴露出来这个代码得有 1000 行但是为了要保持函数代码的体积这里只将主逻辑呈现细节继续细化 而 createOrder 主逻辑也仅仅 40 行代码 createOrder 主体逻辑也是由大量其他 model 和 service 逻辑函数组合而成 这样写的好处就是主逻辑结构一直很清晰自己需要记忆的东西是分层的每次进入一个函数或者跳出一个函数都不用带着巨大的上下文来思考只需要集中在这个单元函数里保证单元函数的正确性即可整体逻辑组合在一起是不可能出现大差错的。
问题三重复函数的使用
程序员有个习惯尤其是面向过程的习惯
看一个 python 代码这里为了要承接上面代码最终结果的过滤就用了大量的 if...else 以及嵌套的 if...else 如果改造完了之后应该就是 3 个主逻辑函数分别调用 NurtureService.xxx1/2/3 三种逻辑每个函数都是 return针对 filter再各自调用 NurtureService.filter(numbers)如果 filter 里面还需要 if...else 判断则再将 filter 拆分为 filter1/2/3也即将逻辑改为一顺而下而非底层汇编语言的来回 jump每个 while 和每个 if 都是一次 jumpjump 计算机会中断人脑也会中断阅读识别都不方便
而函数对于计算机来说用完即焚会快速清理内存而上面这种面向过程的代码就很难做到清理内存if 过程中产生的变量都会存在内存里直到这个函数运行完毕。
代码重复一定要封装函数重复没问题函数名在底层就是 16 进制而且并不是重复存储所以大胆地将函数重复调用将代码逻辑实现完美解耦。
下面就是一个好例子 问题四善用文件夹
程序员养成了一个习惯就是通过命名前缀来区分代码文件加多了就造成命名冗长同时单个文件夹下的代码文件巨多看这里 OrderController我都用一个命名通过文件夹的方式进行区分任何语言都有命名空间的概念所以这样既能让代码命名简洁不来回乱起还能保持层次分明 问题五控制反转和反射机制
我们的习惯是一个类的处理逻辑必须由自己实现也即 order.createOrder实际上我们可以将这种权力交出去让其他对象来处理它例如
OrderService.createOrder(order),如果前面的 OrderService 可以通过上面的那种命名空间的方式用反射机制这种方式可以根据传入参数这种方式可有效减少 if...else 的使用但也造成了代码的不易读最好用 Factory 工厂模式通过传入参数显式地调用具体的类这样可读性就高了很多代码可维护性也提高了很多而且每个逻辑都是隔离的改动起来不会对其他逻辑产生任何影响
class_name api.OrderService
my_class globals()[class_name]# 创建对象实例
instance my_class()# 调用对象的方法
print(instance.createOrder(order))
问题六很少对单函数进行异常预测和收集
如果上面 5 个问题都得到了很好的处理那么剩下的就是异常的预测和收集每个单元函数都会出现异常go 语言就很好返回值总是resulterr xxxx()其中 err 就是一个错误错误产生后可以通过人为判断是否向上抛出或者自行消化再或者 push 到一个错误收集器里 顶级函数外层都会进行错误捕获和处理这里 PHP 做得比较粗糙了些
