Код становится сложным не из-за «неправильного языка», а из-за повторяющихся инженерных привычек. Ниже — несколько анти-паттернов, которые особенно дорого обходятся через год после запуска проекта.
1. Оптимизировать до измерения
Сначала получите profiler/metrics и найдите реальное узкое место. «Быстрый» сложный код в неважном участке только увеличивает стоимость поддержки.
2. Копировать одинаковую бизнес-логику
Два почти одинаковых куска со временем расходятся. Выносите повторяемое правило в одну тестируемую функцию или компонент.
3. Писать огромные функции
Если функция одновременно получает данные, валидирует, меняет БД, формирует HTML и отправляет письмо, её трудно тестировать и безопасно менять.
4. Маскировать ошибки
Пустой catch или бесконечный retry превращают понятную ошибку в загадочное повреждение данных. Логируйте контекст и определяйте, какие ошибки действительно можно повторить.
5. Добавлять зависимость ради одной функции
Каждая библиотека — это обновления, CVE, лицензия и supply-chain. Сравнивайте пользу зависимости с тем, сколько кода она реально экономит.
6. Не писать тест на найденный баг
Если баг уже случился, добавьте regression test. Иначе через полгода тот же дефект вернётся другим рефакторингом.
7. Делать «умный» код вместо понятного
Короткая однострочная конструкция не всегда проще. Код чаще читают, чем пишут — оптимизируйте его для следующего человека, который будет разбираться ночью во время инцидента.
Практическое правило
Сначала корректность, затем наблюдаемость и тестируемость, затем производительность — после измерения.
