Сохраните свой код Go

Go

Немного вечеринки с заголовками, ноочень мало, чтобы увидеть

задний план

Недавно я участвовал в разработке движка новой операционной системы компании, писал много кода и постепенно придумал несколько простых идей для решения этого вида бизнеса. То, что делает операционная система, на самом деле заключается в поддержке операций по укомплектованию персоналом. На самом деле так называемая деятельность может быть просто определена как:Выполнение определенных действий при выполнении ряда условий. Сленг, соответствующий программисту:Выполнить некоторые (несколько) функций после кучи if else.

if else

Когда дело доходит до написания if else, большинство программистов могут понимающе улыбнуться, ведь независимо от того, какая система написана, большинство операторов в коде по-прежнему являются if else. Бизнес-система — это куча if else для требований PM, а базовый сервис — это куча if else для ресурсов ОС и проблем с сетью. Все больше и больше требований вызвали расширение кода.Как справиться с этим, если еще вытекаетШаблоны проектирования: Разделите if else на меньшую степень детализации различными способами. Конечно, не существует набора методологий, способных решить проблему сложности if else, потому что if else на самом деле отражает потребности реального бизнеса, что на самом деле представляет собой сложность бизнеса. Как сказал Лу Синь, или Ма Юнь, или Баффет: «Какой бы метод ни применялся, если иное не исчезнет из ниоткуда, а будет лишь перенесено из одного места в другое».но, перед лицомконкретныйместо действия,конкретныйЧитаемость, ремонтопригодность и расширяемость кода могут быть улучшены.

двигатель правил

Механизмы правил не новы и существуют уже давно, и на рынке существуют различные механизмы правил. Например, обычно используемый iptables является обработчиком правил, а crontab также является обработчиком правил. Бизнес-логика, которую мы обычно пишем, на самом деле является механизмом правил, но она отражается менее очевидным образом. Например: «Если пароль для сброса не содержит заглавных букв и знаков препинания, он не будет отправлен», «Если пользователь является VIP, которому повезло, он даст ему всплывающее окно, даже если оно не транслируется. реклама"... Эта бизнес-логика, как бы она ни была оптимизирована, Обрабатываемая ветвь кода должна существовать. Механизм правил предоставляет синтаксический сахар, недоступный в языках программирования, посредством пользовательского набора синтаксиса (DSL), чтобы минимизировать объем разработки. В то же время большинство правил должны поддерживать настройку пользователей по своему усмотрению, поэтому большинство DSL интерпретируются и выполняются. Пользователь настраивает правило в фоновом режиме, например, в игре пользователь будет снимать 20 баллов после 1000 минут онлайна:

        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 будет знать, какие переменные вы использовали ранее, и сможет проанализировать, что вы можете выбрать для подсказки. Однако Linq — это технология в C#, и она тесно связана с компилятором, поэтому ее непросто портировать на другие языки. Конечно, у сообщества также есть некоторые попытки, такие как портированная версия go.linq-go. Однако, знаете ли, так как сам go не поддерживает дженериков, а компилятор не поддерживает синтаксис linq, то пользоваться им, конечно, хромает, а интерфейс {} и вывод типов должны летать повсюду...

sql

Фактически, часть нашего часто используемого sql завершена, и Linq также переместил sql на C#. Другими словами, часть SQL может комбинировать произвольную логическую логику. Все RD будут использовать sql, и часто используют sql, так как слишком хлопотно делать что-то со стороны компилятора (особенно go — это язык, известный своей простотой, официальный ненавидит добавлять ключевые слова, не говоря уже о синтаксическом сахаре), затем убить функцию запроса mysql и предоставить функцию для объяснения той части, где выполняется сравнение.Например, чтобы проверить, является ли человек лучшим программистом, вы можете проверить это следующим образом:

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 на самом деле является библиотекой, над которой я недавно работал(Попросите звезду, попросите пр, попросите руководства), чтобы помочь вам выполнять сравнения 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
}

Конечно, у этого метода есть и преимущества, и недостатки, например, разделение правил на конфигурационные файлы и перескакивание между несколькими файлами для чтения кода во время отладки — заноза в заднице (просто пишите меньше багов, ха-ха). Одним из преимуществ, например, может быть использование push-платформы для обновления файла конфигурации в режиме реального времени, чтобы достичь цели горячего обновления кода.

В конце концов

На самом деле у yql еще много сценариев применения (я чувствую), и конечно есть некоторые недостатки, такие как функция относительно проста, объяснение и исполнение, скорость не быстрая или нет, но я не сравнивал ни с кем ... Но я надеюсь, что каждый может попробовать это, если это может повысить эффективность работы, неплохо.Попросите внимания, попросите звезду