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

Почему этот метод такой длинный? Зачем вместо раннего return используется вложенный if? Что за названия переменных? И как всё это до сих пор работает? 🤬

Со своим кодом таких вопросов обычно не возникает, правда?

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

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

Однажды я разбирался с похожим участком кода и долго не мог понять, зачем перед обычным вызовом сервиса стояла дополнительная проверка. Хотелось её удалить, упростить метод и сделать всё «как надо».

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

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

Правда, работает это недолго. Открываешь свой класс через год, смотришь на него и думаешь: какой человек вообще мог такое написать?

Потом запускаешь Git blame - и расследование неожиданно заканчивается 😆