Пшерги кодинг

Команда в Legacy проекте

2024-11-11T00:00:00Z

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

Работа над Legacy в проекте

Если проект над которым вы работаете содерджит много легаси (“опасно менять, но дорого удалить”), то это требует определённого навыка не только работы с кодом, но и планирования его развития. Невозможно же просто работать над чем-то новым и полностью игнорировать это чудовище в углу. Или можно? В конце концов, если проект опасно менять, то можно его “законсервировать” и просто не трогать - работает и не лезь.

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

Большие проекты давно не пишутся в одиночку

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

Да, для минимального прототипа вам достаточно вас самих, но каждый участник хакатонов вам подтвердит — с командой можно свернуть горы.

Команда это не просто N человек, бегущих в одну сторону. Слаженная команда это синергия, которой непросто добиться, но один из ключевых факторов её функционирования — общие ценности и общая цель. Тут конечно меня много кто поправит и добавит что в ключевые факторы функционирования команды также входит ещё вот это… и вот то…

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

Один в поле — воин?

Но бывает ведь так - вы фрилансите или может штат сократили и вот вы в команде — один. Стоит ли формировать все эти правила работы с этим богомерзким наследием предков? Зачем и для кого писать эти коментарии и документацию с наполеоновскими планами по поеданию слона по кусочкам?

Определённо стоит, и это даже важнее чем если вы работаете в “настоящей” команде. Потому что вы и есть вся ваша команда, но вместо пространства которое легко предолеть с помощью созвонов и мессенджеров, вас разделяет время и коммуникация здесь идёт только в одну сторону.

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

Слышали когда-нибудь эту цитату? Её автор, конечно, немного преувеличивает, но с очень большой вероятностью тот, кто будет читать ваш код в будущем — это вы сами, но с другим опытом, другими знаниями, даже другой мотивацией и другим настроением.

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

Чтобы не тянуть этот воз как лебедь, рак и щука в одном лице, но в разных временных линиях, наметьте план и придерживайтесь его.

Не высечен в камне

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

Чем это лучше, чем просто запомнить? Тем что наш мозг очень ленив и ненадёжен как инструмент. Он умеет подделывать воспоминания. Он эффективно срезает углы лишь бы не напрягаться. Он сметёт ваш план лавиной эмоций, переживаний и воспоминаний как нечего делать. Но любой сторонний артефакт игнорировать и подделывать сильно сложнее. Даже просто открыть план в гуглодоке и изменить его, сформулировав мысль, требует сильно больших трудозатрат, чем просто “передумать” или “забыть”.

План писать необходимо, плана нужно держаться, но при необходимости его можно и нужно менять.

Обновление glibc и сломанные индексы PotgreSQL

2024-07-22T00:00:00Z

Если вы используете PosgtreSQL в качестве СУБД, то не спешите обновлять ваши сервера: можете получить на ровном месте очень нетривиальные к отслеживанию ошибки.

Обновление glibc

Один из самых важных компонент при обновлении ОС это пакет glibc, который используется почти всем софтом в системе.

1 Августа 2018 года вышла версия 2.28, в которой среди крупных изменений числится:

The localization data for ISO 14651 is updated to match the 2016 Edition 4 release of the standard, this matches data provided by Unicode 9.0.0. This update introduces significant improvements to the collation of Unicode characters. This release deviates slightly from the standard in that the collation element ordering for lowercase and uppercase LATIN script characters is adjusted to ensure that regular expressions with ranges like [a-z] and [A-Z] don’t interleave e.g. A is not matched by [a-z]. With the update many locales have been updated to take advantage of the new collation information. The new collation information has increased the size of the compiled locale archive or binary locales.

Изменились порядок сортировки строк и особенности классификации некоторых символов, что соответственно напрямую отразилось на работе PostgreSQL с поддержкой правил сортировки строк (COLLATIONS).

Примеры сортировки в PostgreSQL с разными версиями (g)libc

Найти и проверить одинаковые версии PostgreSQL на дистрибутивах с разными версиями glibc мне не удалось, однако glibc это лишь реализация Standard C library. Другой реализацией является musl, используемый в дистрибутивах Alpine в Docker. Давайте проверим, отличаются ли реализации порядка сортировки между glibc и libc.

Создадим composer.yaml:

version: '3.9'

services:
  db_1:
    image: postgres:16.3
    user: postgres
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
  db_2:
    image: postgres:16.3-alpine
    user: postgres
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres

и поднимем контейнеры с помощью

docker compose up -d --force-recreate --renew-anon-volumes

и запустим psql в одном из них (для подключения к другому просто замените db_1 на db_2)

docker compose exec -ti db_1 psql

Теперь сделаем запросы и сравним результаты. Вариант сортировки в PostgeSQL, в дистрибутиве Debian:

postgres=# SELECT name FROM unnest(ARRAY[
    'а', 'д', 'е', 'ё', 'ж', 'я'
]) name ORDER BY name;
 name 
 ------
 а
 д
 е
 ё
 ж
 я
(6 rows)

Вариант сортровки в PostgreSQL, в дистрибутиве Alpine:

postgres=# SELECT name FROM unnest(ARRAY[
    'а', 'д', 'е', 'ё', 'ж', 'я'
]) name ORDER BY name COLLATE "C";
 name 
 ------
 а
 д
 е
 ж
 я
 ё
(6 rows)

Как видим, сортровка строк отличается в разных дистрибутивах с разными версиями стандартной библиотеки. Это только цветочки - на самом деле роль играет и сортировка строк установленная по умолчанию в системе, и сам алгоритм в версии стандартной библиотеки. Проблема однако гораздо серъёзнее, чем просто буква “ё” съехавшая в конец списка телефонной книги. Сортировка строк влияет как на запросы типа SELECT ... ORDER BY ..., так и на b-tree индексы на текстовых полях. Это значит, что существующие индексы перестают работать корректно: кроме снижения скорости запросов мы также можем получить неконсистентность данных, т.к. уникальность в таблицах реализована через UNIQUE INDEX.

Именно с этим мы и столкнулись - обновление серверов СУБД прошло корректно и без ошибок, однако мы заметили появившиеся ошибки вида Duplicate key violation. И действительно, при наличии UNIQUE INDEX данные всё же дублировались, причём далеко не все запросы показывали наличие дублирования!

Что делать?

Очевидное решение: ребилд индексов, затрагивающих текстовые поля. Сделать это нужно после того как репликация и синхронизация данных со старого сервера на новый прошла, но до того как пускать трафик на новый сервер.

А если поймали ошибки с дублированием строк? Очевидно, при перестроении индекса вы получите ошибку, т.к. фактически данные у вас дублируются. Тогда придётся сначала решить эту проблему, избавившись от дубликатов данных. Если трафика много, то лучшим решением будет полностью остановить трафик на БД и сначала решить проблему с данными, а затем уже пересобирать индекс. Будьте готовы к такому исходу, когда придётся полностью откатиться к последнему бэкапу (вы же делаете бэкапы?).

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

Как предотвратить?

Отработать процесс обновления БД

Учитывать подобный риск и проговаривать его с командой поддержки инфраструктуры

Не обновлять glibc

Доволно радикальный подход, который может означать отказ от обновления системы вообще. Такое подходит далеко не всем, но стоит держать его как один из действенных способов избежать проблем.

Перестать зависеть от glibc

Переключить PostgreSQL на ICU для работы с сортировкой строк. В этом случае вы будете также зависеть от сторонней библиотеки (libicu), но её обновление не требуется при обновлении всей системы.

Тип integer в колонке id как бомба замедленного действия

2023-12-25T00:00:00Z

Если вы работаете с Legacy проектом, то загляните в структуру ваших таблиц - возможно некоторые из них используют integer в качестве id поля, и это очень плохо.

В чём проблема

Тип integer имеет лимиты от -2147483648 до +2147483647 (от 1 до 2147483647 для serial) в PostgresQL. К этому лимиту довольно легко подойти, особенно если система была создана уже значительно время назад.

Особенность этой проблемы:

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

Как проверить

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

Можно проверить размерность всех id колонок во всех таблицах, однако в разное время даже в одном проекте могут использоваться разные конвенции именования, поэтому часть таблиц могут иметь колонки вроде product_id или rid и т.п.

Ещё один более масштабируемый вариант - проверить текущие значения в последовательностях используемых для автоинкрементных колонок. Для этого подойдёт такой запрос:

SELECT c.relname, nextval(c.relname::regclass) AS seq_val
FROM pg_class c
WHERE c.relkind = 'S'
  AND  nextval(c.relname::regclass) > 1000000000
ORDER BY seq_val desc;

В результате получим список последовательностей превысивших 1 млрд., отсортированных по убывающей. Верхний лимит integer как мы помним больше 2 млрд. поэтому значение в 1 млрд. выглядит как то, с чего стоит начать в первую очередь. По названию sequence можно довольно легко определить какая таблица её использует.

Не забываем про таблицы ссылающиеся на изменённые id в качестве внешних ключей для связи многие-к-одному или многие-ко-многим. Если foreign key constraint прописаны для таких таблиц, то их можно найти следующим запросом (здесь мы ищем внешние ключи ссылающиеся на my_table_name(id)):

SELECT la.attrelid::regclass AS referencing_table,
       la.attname AS referencing_column
FROM pg_constraint AS c
         JOIN pg_index AS i
              ON i.indexrelid = c.conindid
         JOIN pg_attribute AS la
              ON la.attrelid = c.conrelid
                  AND la.attnum = c.conkey[1]
         JOIN pg_attribute AS ra
              ON ra.attrelid = c.confrelid
                  AND ra.attnum = c.confkey[1]
WHERE c.confrelid = 'my_table_name'::regclass
  AND c.contype = 'f'
  AND ra.attname = 'id'
  AND cardinality(c.confkey) = 1;

Однако foreign key constraint есть не всегда (а порой его создание может быть вообще невозможным), поэтому стоит принять это во внимание - на этом автоматизация заканчивается и дальше придётся проверять руками и глазами.

На что заменить

Простым решением для текущего состояния будет перевести тип колонки из int в bigint - запаса прочности этого типа данных должно хватить.

Однако не стоит считать что bigint это серебряная пуля при выборе типа id колонки в новых таблицах - всё конечно же будет зависеть от ваших сценариев использования и предназначения таблицы, так что ответ здесь как всегда - it depends.

PHP Rector и как он вам [не] поможет

2023-10-23T00:00:00Z

Все, кто планировал переход на новые версии PHP слышали о проекте Rector для автоматизации рефакторинга и адаптации новых фич. Каждый кто завершал такой переход может рассказать пачку историй о том как и когда всё пошло не по плану.

Что такое Rector

Rector это инструмент автоматизации рефакторинга и апгрейда кодовой базы. Он поможет с базовыми вещами вроде добавления тайп-хинтов и конвертацией PhpDoc в аттрибуты. Более того, типичные сценарии объединены в наборы правил: например набор Php52 для миграции на PHP 5.2 содержит сразу два правила: ContinueToBreakInSwitchRector и VarToPublicPropertyRector, которые заменят continue на break в switch-конструкциях и заменят ключевое слово var на public в объявлении полей класса, соответственно. Удобно!

В чём подвох?

Давайте рассмотрим типичный пример апгрейда PHP между мажорными версиями - ведь именно это опаснее всего и именно в таких случаях мы хотим подстелить соломку. К примеру, пусть мы хотим обновить наш страшный legacy проект с PHP 5.6 на PHP 7.0. Смотрим на несовместимые изменения в PHP 7.0 и видим среди прочих:

Negative bitshifts теперь бросают эксепшен, однако в Rector нет правил на то, чтобы детектить такие случаи
Удалены все ext/mysql и ext/mssql функции - Rector также не подсветит вам что вы их испльзуете
Функции set_socket_blocking и set_magic_quotes_runtime (с алиасом magic_quotes_runtime) удалены - не обнаруживается Rector

и др.

Что лишнего в Rector?

В то же самое время в наборе правил Rector для Php70 есть следующие штуки:

Использование <=> вместо тернарных операторов
Замена if/else и тернарных операторов на оператор <=>
Замена if+isset и тернарных операторов на ??
Замена вложенных вызовов dirname() на один с указанием глубины

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

Какие есть альтернативы?

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

Важный урок, который я вынес из общения с этими инструментами: эти инструменты не сделают волшебно, бесшовно и безболезненно.

Некоторые автоматизированные правки могут прикрыть вам тыл, тогда как другие внесут ошибки ковариантности и контравариантности в наследовании. Такие ошибки интерпретатор отловит при первой же попытке запустить проект, но что если ошибки могут проявиться только в райнтайме? Например, добавленный declare(strict_types=1); сделает ваш код более строгим и там где раньше срабатывало приведение типов, теперь появится ошибка!

Так что делать-то?

В конечном итоге мы хотим без ошибок выкатить в продакшен код на новой версии языка.

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

Если тестами обкладываться сложно, долго и дорого (потому что у вас legacy) - найдите ключевой функционал и покройте тестами хотя бы его. Вероятно чтобы покрыть его тестами вам будет нужно сначала вручную критические части кода хорошенько отрефакторить и например уложить в классы с полноценным внедрением зависимостей, вынесением низкоуровневой работы с БД или сетью в отдельные классы, внедрением работы с интерфейсами и абстракцией вместо конкретных реализаций, и в целом обмазывании себя типизацией со всех сторон.

И все проблемы автоматических инструментов сводятся к тому что они могут быть лишь настолько умными, насколько это возможно. Если ваша функция работы с БД принимает аргумент $ref типа int[]|string[]|false|null|mixed, то поможет вам только собственный опыт в том как этот клубок распутать и что делать дальше, потому что применение автоматизации здесь совершенно невозможно.

В заключение

Может показаться что я утверждаю что такие инструменты как Rector, psalm и phpstan не нужны, однако это совершенно не так. Я лишь подсвечиваю тот момент, которому не всегда деляют много внимания в диферамбах о том, как быстро и легко обновить весь проект с егозависимостями.

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

Успешного вам обновления.

Объявляйте классы final по-умолчанию

2023-07-26T00:00:00Z

Ключевое слово final появилось в PHP вместе с понятием классов, однако зачастую им пренебрегают.

TL;DR: Всегда объявляйте класс как final, если все его публичные методы являются реализацией интерфейсов класса.

Принцип Open-closed

Вспомним принцип Open-Closed из аббревиатуры SOLID:

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

Закрытость для изменения в этом контексте означает что когда ваш код предоставляет какой-то интерфейс, этот интерфейс не должен меняться. В конце концов API это контракт, это обещание совместимости, это ответственность. Это не означает что реализация не может меняться — как раз наоборот!

Однако “открытость к расширению” не означает “открытость к наследованию”. Композиция, Стратегия, EventListener, обратные вызовы - всё это рабочие способы расширять поведение без использования наследования, которые чаще всего ещё и более предпочтительны. Часто наследование делает код только более сложным и менее гибким.

Наследование vs Интерфейсы

Если ваш класс изначально не подразумевает наследование, то стоит сразу объявить его final. Но как понять что наследование не потребуется в дальнейшем?

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

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

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

Таким образом получается что если ваш класс реализует интерфейс, то вполне уместно сразу же объявить его final.

Проблемы с тестированием

Тестовые фреймворки полагаются на возможность наследования классов для создания моков и заглушек. Как с этим быть?

Можно конечно вместо объявления класса как final добавить ему аннотацию (или phpdoc) @internal что пометит класс, как часть внутренней реализации и хотя технически его всё ещё можно будет наследовать, мы явно объявим о своей интенции и сделаем вид что всё хорошо.

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

Почему `final` это хорошо

Предотвращает формирования адских цепочек наследования вида MailDeliveryBot → Bot → Admin → User → Core → Db.
Подталкивает к использованию композиции. Скорее всего вам не нужно наследование при работе с этим классом, если изначально он не планировался как абстрактный класс.
Заставляет продумывать API библиотек и решений. Наследование нарушает инкапсуляцию. Если класс явно не создавался под наследование, то можно получить проблемы с совместимостью. Трижды думайте перед тем как использовать extends и используйте final чтобы не заставлять других ломать голову.
Подталкивает к сужению публичного API классов
При необходимости final можно убрать, но придётся привести веские доводы и принять это решение явно

В каких случаях применять `final`

Классы объявленные как final эффективно работают только в при соблюдении следующих условий:

Класс, объявленный final реализует некоторый набор интерфейсов
Все публичные методы класса покрыты этими интерфейсами

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

Бонус

Шаблон для создания PHP классов в PhpStorm:

<?php

declare(strict_types=1);

#if (${NAMESPACE})
namespace ${NAMESPACE};

#end
final class ${NAME}
{

}

Избегайте отрицательных условий

2023-07-19T00:00:00Z

Разберём на примерах известное правило избегания отрицаний в условиях. Какие бывают отрицания и чем они опасны.

Начнём с первоисточника

Как у Дяди Боба

G29: Избегайте отрицательных условий Отрицательные условия немного сложнее для понимания, чем положительные. Таким образом, по возможности старайтесь формулировать положительные условия. Например запись
if (buffer.shouldCompact())
предпочтительнее записи
if (!buffer.shouldNotCompact())

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

Что ж, давайте разбираться.

Операторы отрицания

Рассмотрим синтетический пример метода проверки авторизации пользователя и соответствующий вариант его использования:

class AnonymousAuthenticator:
  def is_authenticated(self, request: Request) -> bool:
    return True

class PublicController:
  def index_action(self, request: Request) -> str:
    authenticator = AnonymousAuthenticator()

    if not authenticator.is_authenticated(request):
      return "authentication required"

    # ...
    # do some business logic
    # ...

    return "Successfuly authenticated"

Классический ход - если пользователь не авторизован, то сразу же вернём ответ. Если предположить что Роберт Мартин имел ввиду избегать операторы отрицания, то какие у нас есть варианты?

Переписать условие так, чтобы не было оператора отрицания. В таком случае основная бизнес логика ляжет внутрь if is_authenticated, а негативный кейс уедет в самый конец, возможно, на пару экранов, где уже будет неясно какое условие там проверялось. Кроме того, весь код получит лишний уровень вложенности, что как известно негативно влияет на его восприятие.
Добавить метод is_not_authenticated в класс AnonymousAuthenticator. В таком случае мы либо получим дублирование логики с методом is_authenticated, которое приведёт к ошибкам в рассинхронизации двух вариантов реализации, либо отрицательное условие с вызовом is_authenticated переместится внутрь этого метода. Да ещё и отрицание теперь будет в названии метода.
Добавить метод is_forbidden в класс AnonymousAuthenticator. Проблемы те же что для предыдущего варианта, но имя уже как будто не содержит отрицания.

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

Отрицания в языке

Если бы в естественных языках отрицание выражалось только частицами “не” и “нет”, то это были бы очень скудные по выразительности языки.

Рассмотрим каким образом отрицания могут реализовываться в языках программаривания:

not - отрицание с помощью частиц no и not
disable, inactive - отрицание с помощью префиксов in-, un-, dis-
powerOff - отрицание с помощью фразовых глаголов (комбинации глагола и предлога, образующие цельную смысловую единицу)
forbid, reject - слова с очевидным или неочевидным отрицанием в их смысловой нагрузке, но формально не попадающие под предыдущие категории

Как ни странно, самый безобидный из этих вариантов - именно первый. Рассмотрим пример:

class EditorAccessCheck
{
  const ENABLED = 'enabled';

  public function isNotAllowed(User $user): bool
  {
    return !$user->isEditor();
  }
}

class NewsController
{
  public function editAction(Request $request, EditorAccessCheck $accessCheck): Response
  {
    if ($accessCheck->isNotAllowed()) {
      return AccessDeniedResponse();
    }

    return Response("Welcome to editor's club!");
  }
}

Использованием метода читается довольно просто и понятно, несмотря на отриание в названии. Заметим что условие, которое проверяется внутри самого метода также содержит отрицание через оператор !, однако и оно не мешает воспринимать код. Проблемы начнутся когда кто-нибудь решит воспользоваться EditorAccessCheck в ином контексте:


class EditorActionSubscriber extends EventSubscriber
{
  public function __construct(
    private EditorAccessCheck $accessCheck
  ) {}

  public function supports(): bool
  {
    return !$this->accessCheck->isNotAllowed();
  }

  public function onEvent(UserActionEvent $event): void
  {
    // React to $event
  }
}

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

Неявное двойное отрицание

Все довольно просто когда мы смотрим на переменные с частицами No и Not, однако то же самое касается и вариантов с неявным отрицанием:

if (!$disabled) {
  call_when_enabled();
}

или

if not inactive:
  call_when_active()

Оба варианта содержат двойное отрицание, которое сложно воспринимать, даже несмотря на то, что ни одна из переменных не имеет явного отрицания с частицами not.

Вывод

Сам по себе оператор отрицания не несёт в себе ничего плохого и не может рассматриваться как запах кода. Проблемы с пониманием кода возникают при двойном отрицании, которое можно легко исправить если отрицание не заложено — явно или неявно — в имена переменных и методов.

Some shit

Рассмотрим примеры из реальных проектов. Например, отрицание проверки отрицательного флага

if (!$widget->isFlagEnabled(ProductFlag::DISABLED)) {
    // do something
}

Чтобы каждый раз не пытаться понять что имелось ввиду, можно инкапсулировать эту логику в метод с понятным названием:

    public function isActive(): bool
    {
        return !$this->isFlagEnabled(ProductFlag::DISABLED);
    }

Хотя кажется правильней было бы ориентироваться на константу ProductFlag::ENABLED

Ещё один пример в коде, который пока нельзя назвать проблемой, но уже явно попахивает:

abstract class WidgetFlag
{
    public const DISABLED = 0x0001;

    public static function getList(): array
    {
        return [
            self::DISABLED => 'Выключено',
        ];
    }
}

Что мы видим:

Константа с неявным отрицательным смыслом;
Из значения 0x0001 можно сделать предположение, что есть, вероятно среди возможных значений хранящихся в БД или приходящих по API, ещё неявная положительная константа ACTIVE = 0x0000;

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

function isAdmin(user) {
  return ('admin' in user) ? !!user.admin : false
}

Прилагательное вместо глагола inactive -> deactivate / setInactive:

public function inactive(): void
{
    $this->isActive = false;
}

Вместо заключения

<input type="checkbox" disabled="disabled" />

Мы вероятно уже привыкли и это уже не исправить, но это отвратительно: двойное отрицание которое всё же отрицание