Откуда берётся запутанный код

Попробую на маленьком примере показать откуда берётся запутанный код.

Получаем задание от менеджера, для простоты это будет просто логическая функция. И пытаемся написать лучший код.

Для упрощения написания маленькая буква будет означать что условие ложно, а большая - что истинно.

Представляем функцию в виде карты Карно, чтобы оптимизировать всё что можно:

   aaAA
   bBBb
cd 1101
cD 1101
CD 0000
Cd 1101

Естественно, пишем первый вариант.

А потом прибегает менеджер и говорит что нужно изменить самую малость, случай abcd = 0. Отражаем на карте:

   aaAA
   bBBb
cd 0101
cD 1101
CD 0000
Cd 1101

Если бы задание сразу было таким, то мы написали бы другой совершенный код:

Снова приходит менеджер. Условие C не нужно, его случайно добавили. Убираем половину карты:

  aaAA
  bBBb
d 0101
D 1101

Совершенный код был бы таким, если бы мы знали заранее:

Снова менеджер. Ещё одно изменение, ABd = 1, и можно отдавать заказчику:

  aaAA
  bBBb
d 0111
D 1101

Итог

Что хотел клиент: a&B|A&b|A&d|a&D

Что передано клиенту: (a|b|a&d|b&d)&(A|B|D)|A&B&d

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

Выводы

@Sau
02.10.2025 15:23 UTC
Первоисточник

Комментарии

@evgenyk
02.10.2025 11:07 UTC
+2

А почему не сделать таблицу? На питоне это будет словарь, значения - вызовы функций, ключи - логические выражения. Тогда при изменениях, просто добавляем или удаляем выражения в словарь.

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

@Sau
02.10.2025 11:38 UTC
+5

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

Вариант с таблицей для логических функций поддерживаю.

@anshdo
02.10.2025 14:44 UTC
+2

Ну, собственно, именно по-этому нужен регулярный рефакторинг.

@swame
03.10.2025 07:39 UTC
+5

Лучшая форма не самая краткая, а самая

  • Модифицируемая

  • Понятная

  • С возможностью просмотра в отладчике или логе, какое именно условие сработало

@menz1
03.10.2025 10:00 UTC
0

++Не самая долгая по трудозатратам

Настраиваемая/параметризуемая

Переиспользуемая

@izibrizi2
03.10.2025 08:15 UTC
+1

Элементы И-НЕ (NAND) и ИЛИ-НЕ (NOR) часто дешевле и универсальнее. Поэтому не всё так просто с картами Карно :)

@Sau
03.10.2025 09:49 UTC
+2

От изменяющихся условий задачи не помогут никакие элементы.

@andy_p
03.10.2025 11:24 UTC
-1

Не надо карты Карно использовать, пользуйтесь симметричными картами:

https://habr.com/ru/articles/358328

@martin_wanderer
03.10.2025 17:37 UTC
+1

Ну так идеальный код не самый компактный. И даже не самый понятный. А такой, который потребует минимум правок, когда менеджер прибежит с новыми требованиями . Про которые конечно же заранее ничего не известно. Хотя при желании можно попробовать спрогнозировать, в каких аспектах система будет меняться, а в каких - нет. И заложить в архитектуру то, что конечно же однажды все равно поменяется ;)