[聚合文章] 拯救你的Go代码

.Net 2018-02-06 13 阅读

最近一直在参加开发公司新运营系统的引擎部分,写了很多很多代码,也逐渐产生了一些自己对此类业务的解决方案的简单想法。运营系统干的事,其实就是支持运营人员配置活动。所谓活动其实可以简单定义为: 一系列条件都满足就执行某个(些)动作 。对应到程序员的黑话就是: 一坨if else之后执行某(几)个函数

if else

说到写if else,大多数程序员可能都会会心一笑,毕竟不论写啥系统,代码里大部分语句还是if else。业务系统就是对PM的需求堆if else,基础服务就是对OS资源和网络问题堆if else。越来越多的需求造成了代码的膨胀,如何来管理这坨if else,就衍生出了 设计模式 :通过各种手段来把if else划分到更小的粒度。当然,还没有任何一套方法论可以解决if else复杂性的问题,因为if else反映的其实是真实业务的需求,它其实代表了业务的复杂性。就像鲁迅或者马云或者巴菲特说的:“不论用什么方法,if else不会凭空消失,只会从一个地方转移到另一个地方”。 但是 ,在面对 特定 的场景, 特定 的业务,代码的阅读性、可维护性以及扩展性是可以得到提升的。

规则引擎

规则引擎不是一个新东西,而且已经存在了很长时间了,市面上也有各种规则引擎。比如大家常用的iptables,就是一种规则引擎,crontab也是一种规则引擎。我们平时写的业务逻辑,其实也是规则引擎,只是用一种不那么明显的方式来体现。比如:“如果重置的密码没有包含大小写和标点符号,就不让提交”,“如果用户是抽奖送的VIP虽然不播广告但给他弹窗”……这些业务逻辑,无论怎么优化,要处理的代码分支是一定存在的。规则引擎通过自定义的一套语法(DSL),提供了编程语言所不具备的语法糖,来最大限度减少开发量。同时大部分规则都需要支持用户随意配置,因此DSL大多是解释执行。用户在后台配置一条规则比如,游戏中用户在线1000分钟后扣20的点卡:

When
        {
           ?customer: Customer(totalTime >=1000);
        }
        Then
        {
           execute {?customer.setAmount(getAmount()-20.00);
        }

市面上比较常用的几款规则引擎都属于非常重量级的,用户必须去学习它的DSL才能使用,当然基本上都是JAVA的包。这有一篇文章是几款规则引擎的比较。没有深度用过,我也没法对此进行评价,但由于其概念实在太多且使用场景受限,我觉得它始终是个临时方案,毕竟“大道至简”。而且DSL会越写越复杂,真正用到语法糖的地方还是少数,到最后变成另一种蹩脚的而且领域受限的编程语言了。虽然如此,但由于其规则可动态增加,老规则便于复用,对于提供通用解决方案的一些软件公司来说,规则引擎还是很有吸引力的。毕竟代码不需要动,加一些规则就能再次销售。

但是对于进行业务开发的RD来说,其实需求很简单,如果一个东西:

  • 正确
  • 简单
  • 能减少繁琐的工作

那么这便是一个有吸引力的解决方案,如果它能再快点儿,那就是一个绝妙的主意了。对于减少if else,我觉得Linq是一个非常好的方案。

Linq

Linq是C#中的一种常见技术,用过的都觉得爽。它就是一种语法糖,编译器会编译成真正的代码而不是在运行期解释执行,因此效率也很高。Linq代码大概就是这样:

// Specify the data source.
        int[] scores = new int[] { 97, 92, 81, 60 };

        // Define the query expression.
        IEnumerable<int> scoreQuery =
            from score in scores
            where score > 80
            select score;

可以看到,在代码中一些逻辑如果能这样表达,那代码将会变得非常简单。linq基本上就是把sql语句搬到了C#中,唯一的区别就是它把select放在了最后而sql是在前面。这其实也是因为IDE智能提示的需求,而不是查询结构本身要这么设计。把select放在最后,IDE就知道你前面用过哪些变量,就可以分析出你可以select什么从而进行提示。但是Linq是C#中的技术,和编译器是强相关的,想移植到别的语言,还是很不容易的。当然,社区也是有一些尝试的,比如go的移植版 linq-go 。然而,你懂的,由于go本身不支持泛型,编译器也不支持linq语法,因此使用起来当然还是比较蹩脚,而且肯定是interface{}和类型推断满天飞了……

sql

其实我们常用的sql中的where部分是完备的,Linq也是把sql搬到了C#中。换句话说,sql的where部分其实可以组合任意的布尔逻辑。所有RD都会使sql,而且是经常使sql,既然想从编译器的方向搞事情太麻烦(尤其是go是一门以简单著称的语言,官方对于加关键字是深恶痛绝的,更别说语法糖了),那么把mysql查询功能干掉,解释执行where比较的那部分功能做成一个函数提供出来呢,比如查询一个人是不是顶级程序员可以这么查:

sql := `sex='male' 
        and (
            dislike in ('girl', 'woman', 'female') 
            or 
            hobby in ('dress up', 'makeup')
        )`

但是由于没有表数据,那么真正用于比较的数据就需要业务方自己来提供了,以上功能可以写为:

func isTopProgrammer(userInfo User) bool {
    sql := `sex='male' 
        and (
            dislike in ('girl', 'woman', 'female') 
            or 
            hobby in ('dress up', 'makeup')
        )`
    ok,_ := yql.Match(sql, map[string]interface{}{
        "sex": userInfo.Sex,
        "dislike": userInfo.Dislike,
        "hobby": userInfo.Hobbies,
    })
    return ok
}

yql其实就是我最近搞的一个lib求star,求pr,求指导 ),帮你执行sql的比较。

如果这么搞,其实业务逻辑中经常变动的部分可以抽象到配置文件里,比如:

// 先定义好不同case的处理函数
type handleFunc func(map[string]interface{}) error
var handlers = map[int]handleFunc {
    1: sendEmail,
    2: sendCoupon,
    3: sendSms,
    4: sendAlert2Boss,
    5: runAway,
}
// 从当前请求中解析数据
data := resolveDataFromPostParams(request.Body)
// 从配置文件加载规则
rules := loadRuleFromConf()

//枚举每条规则进行匹配,如果匹配成功则执行对应handler
for _,rule := range rules {
    success,err := yql.Match(rule.SQL, data)
    if nil != err || !success {
        continue
    }
    handler := handlers[rule.ID]
    handler(data)
    break
}

当然这种方式也有利有弊,比如说,把规则分离到配置文件中,在debug时得几个文件之间跳来跳去地看代码,比较蛋疼(少写点bug就行了,哈哈)。优点之一比如说可以利用推送平台实时更新配置文件,从而达到代码热更新的目的。

最后

其实yql还有很多应用场景(我感觉),当然也有一些不足,比如功能还比较单一,解释执行,快不快其实也没和谁对比过……不过希望大家能够尝试尝试,如果能够提升工作效率,还是不错的。 求关注,求star

注:本文内容来自互联网,旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜,请你联系站长进行处理。