Сначала разберитесь с бизнес-логикой, а потом пишите код

задняя часть

1. Бизнес-логика и код

Код — это форма представления логики требований.

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

Код обзора часто является логической проблемой

По опыту просмотра кода я обнаружил, что беспорядочный код — это не просто проблема навыков написания кода, а часто потому, что логика не разобрана четко. Логика испорчена, как и естественный код. Разбор бизнес-логики явно закладывает хорошую основу для кода.

Конечно, после того, как с бизнес-логикой разобрались, могут остаться проблемы с отображением бизнес-логики на код, что является проблемой, которую решают навыки программирования.

Вот простой пример, демонстрирующий этот процесс:

2. Пример бизнес-требований

Мы делаем одну вещь doSomething:

  • Первым шагом является выполнение A. Процесс A должен сначала выполнить a1, затем выполнить a2, а затем выполнить три подпроцесса a3.
  • Второй шаг — выполнить B. Процесс B должен выполнить два подпроцесса b1 и b2.

Графическое представление логики этого примера выглядит следующим образом: это дерево, содержащее корень, ветви и листья дерева.

业务表述.png

Примеры общие, и любой бизнес в реальном мире может быть представлен аналогичной древовидной структурой.

3. Правильная реализация кода

3.1 Кодовое дерево, сопоставленное логическому дереву

Правильная структура кода должна быть сопоставлена ​​с логикой.Структура кода выглядит следующим образом:

正确的代码实现.png

Когда мы на самом деле пишем код, мы обычно не пишем вышеприведенную структуру напрямую, а сначала пишем структуру «блок кода 3.2 + комментарий».

3.2 Блоки кода + разумные комментарии

Следующий код отображает логику через блоки кода, а подметоды на рисунке выше соответствуют комментариям в коде.

void doSomething(){
    //A
    a1逻辑伪代码.....;//a1
    a2逻辑伪代码.....;//a2
    a3逻辑伪代码.....;//a3

    //B
    b1逻辑伪代码;//b1
    b2逻辑伪代码;//b2
}

3.3 Извлечение малых методов

Это может быть лучше на основе вышеизложенного и извлечения небольших методов блоков кода, которые больше соответствуют описанию бизнеса (больше соответствуют древовидной структуре бизнеса).

void doSomething(){
    doA();
    doB();
}

void doA(){
    a1逻辑伪代码.....;
    a2逻辑伪代码.....;
    a3逻辑伪代码.....;
}
void doB(){
    b1逻辑伪代码;
    b2逻辑伪代码;
}

Конечно, вы также можете продолжать отображать a1, a2, a3, b1, b2 и другую маленькую логику в маленькие методы.Вышеупомянутые способы написания правильны.Что касается извлечения малых методов, последующие действия будет отдельно в разделе «Взаимосвязь между длиной кода и родным языком». Давайте посмотрим на неправильное написание ниже.

4. Неправильная реализация кода

Когда вы видите неправильный способ написания ниже, вы можете почувствовать себя невероятным, вы действительно можете написать такой код? Реальность такова: я видел много худшего кода в проектах, которые имеют перестановки и комбинации проблем, упомянутых ниже, а также проблемы с другими навыками программирования.

4.1 Первая проблема: асимметрия

Первая распространенная проблема не является серьезной, извлекается только часть логики, что приводит к неравномерному выполнению в методе, например, извлекается только логика b(), но эквивалентная логика a() не извлекается;

第一种问题不对等.png

void doSomething(){
   a1逻辑伪代码.....;
   a2逻辑伪代码.....;
   a3逻辑伪代码.....;
   doB();
}

void doB(){
   b1逻辑伪代码;
   b2逻辑伪代码;
}

Для метода улучшения, пожалуйста, обратитесь к правильному написанию Части 3 выше, по крайней мере, вdoB();Добавление пустой строки перед и добавление комментария к а1, а2, а3 тоже будет намного легче читать (конечно, это компромисс).

void doSomething(){
		//a逻辑
    a1逻辑伪代码.....;
    a2逻辑伪代码.....;
    a3逻辑伪代码.....;
    
    //b逻辑
    doB();
}

void doB(){
    b1逻辑伪代码;
    b2逻辑伪代码;
}

4.2 Вторая проблема: частичное извлечение

Во-вторых, извлечь часть логики из целого.Этот метод трудно назвать.Он даст неудовлетворительное имя или будет использовать общее имя.Это относительно серьезно и влияет на чтение и понимание кода.

Например, компьютер — это целое, и его можно назвать компьютером, если вам дана только часть (процессор, материнская плата, видеокарта), как вы можете назвать ее так, чтобы люди могли понять? Компьютерные комплектующие? Но некоторые части компьютера понять невозможно, потому что это не логический предмет. CPU — это логическое тело, которое инкапсулирует операции.

Как показано на рисунке ниже, извлекаются только a1 и a2, а затем имя по-прежнему называется a. Будет очень сложно увидеть код, а a3 явно принадлежит a.

第二种问题不对等部分抽取.png

void doSomething(){
    doA();
    a3逻辑伪代码.....;
    doB();
}
void doA(){
    a1逻辑伪代码.....;
    a2逻辑伪代码.....;
}

void doB(){
    b1逻辑伪代码;
    b2逻辑伪代码;
}

4.3 Третья проблема: ошибки извлечения

Третья — самая серьезная проблема, ошибки извлечения и логические несоответствия.

А именно: Часть логики A и часть логики B извлекаются вместе.

Если на этом основании дать извлеченной части непонятное имя (на самом деле у такого извлечения не может быть хорошего имени), а затем применить некоторые шаблоны проектирования для децентрализации кода (скрыть недостатки), то оно будет успешно завершено. , Только код, который вы можете понять сами (возможно, он отлично выглядит на поверхности).

第三种问题不对等抽取错误.png

В заключение, даже не думайте об извлечении небольших методов или применении шаблонов проектирования. Сначала напишем логический код.

Извлечение небольших методов и шаблонов проектирования не обязательно решают проблемы, они также могут скрывать проблемы.

Очень много трудночитаемого кода упаковано "Рефакторингом" и "Шаблонами проектирования". Некачественный код не страшен. Если еще раз извлечь и запаковать, то можно себе представить, насколько это ужасно.

5. Патч и образное мышление

Мышление кода патча, гниение кода

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

Не спешите использовать шаблоны проектирования, хорошо пишите базовый код

Процесс написания хорошего базового кода:

Сначала отсортируйте логическое дерево (древовидная структура, одноранговые сети на одном уровне), а затем приведите код в соответствие с логическим деревом (дерево кода естественным образом соответствует древовидной структуре, а методы одного уровня равный).

После закладки фундамента вы можете применять сложные средства (такие как шаблоны проектирования) для устранения болевых точек базового кода.О извлечении метода и длине метода мы поговорим в последующих отдельных статьях.

Категории