Умный код — это, вероятно, худший код, который вы можете написать

«Умный» (clever) код почти всегда оказывается худшим выбором: он хуже читается, сложнее поддерживается и повышает стоимость ошибок. «Красивые» однострочники и трюки уместны как хобби (code golf), но вредны как повседневная инженерная практика.

Почему «умный» код вреден

1. Падает читаемость: Смысл прячется за приёмом, а не выражается прямо.
2. Дорожает отладка: Чем хитрее код, тем сложнее локализовать и исправить ошибку.
3. Тормозятся ревью и развитие: Труднее проверять изменения, безопасно рефакторить и расширять поведение.
4. Плохо масштабируется на команду и время: То, что «понятно автору сейчас», часто непонятно другим (и автору позже).

Что такое «понятный» код и почему его сложнее писать

Понятный код выглядит простым, потому что автор:

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

Стабильный путь — писать по ясному style guide и регулярно проходить строгие code review.

Использовать линтеры/форматтеры и стандарты — как инструменты снижения стоимости изменений.

Пример: «умно» vs «понятно» (JavaScript)

Задача: посчитать сумму цен активных товаров, которые есть в наличии.

Вариант A — «умно» (слишком много в одной строке)

const total = (items || []).filter(i => i?.active && i?.stock > 0).reduce((s, i) => s + (Number(i?.price) || 0), 0)

Минусы:

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

Вариант B — «понятно»

function calcTotal(items) {
	let total = 0

	for (const item of items || []) {
		if (!item) continue
		if (item.active !== true) continue
		if ((item.stock || 0) <= 0) continue

		const price = Number(item.price) || 0
		total += price
	}

	return total
}

Плюсы:

• правила читаются последовательно
• легко дебажить (price/total — отдельные шаги)
• просто расширять (скидка/налог)

---

Пример: «умно» vs «понятно» (PHP)

Та же задача.

Вариант A — «умно» (слишком функционально)

// Вложенные array_* читаются тяжело
$total = array_sum(array_map(
	fn($i) => (float)($i['price'] ?? 0),
	array_filter($items ?? [], fn($i) => ($i['active'] ?? false) && ($i['stock'] ?? 0) > 0)
));

Минусы:

• отладка и чтение хуже из-за вложенности
• трудно добавить промежуточные проверки/логи

Вариант B — «понятно»

function calc_total(array $items): float {
	$total = 0.0;

	foreach ($items as $item) {
		if (!is_array($item)) continue;
		if (($item['active'] ?? false) !== true) continue;
		if ((int)($item['stock'] ?? 0) <= 0) continue;

		$price = $item['price'] ?? 0;
		$total += is_numeric($price) ? (float)$price : 0.0;
	}

	return $total;
}

Плюсы:

• предсказуемые типы
• проще расширять (налоги/купоны/округления)

---

Ссылки и тезисы

1. John Carmack on inlined code (2007) http://number-none.com/blow/john_carmack_on_inlined_code.html → Длинное письмо Джона Кармака о стиле кодирования и инлайнинге кода (2007 год)
2. Google style guide https://engineercodex.substack.com/p/how-google-writes-clean-maintainable → Статья о том, как Google пишет чистый и поддерживаемый код, обзор их гайдлайна
3. Vercel style guide https://github.com/vercel/style-guide → Публичный гайдлайн по стилю кода от Vercel на GitHub
4. How Instagram scaled to 14 million https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million → Техническое исследование о том, как Instagram масштабировался до 14 миллионов пользователей
5. How one line of code caused a $60… https://engineercodex.substack.com/p/how-one-line-of-code-caused-a-60 → История о том, как одна строка кода вызвала простой (outage) с убытками в $60+ миллионов
6. How to burnout a software engineer https://engineercodex.substack.com/p/how-to-burnout-a-software-engineer → История о выгорании разработчиков в индустрии

Итого

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

— Брайан В. Керниган

Главная мысль: Хитроумный код (clever code) — это худший код, который можно написать. Ясный и читаемый код (clear code) сложнее в написании, но именно его пишут опытные инженеры.

• Выражай смысл, а не трюк: лучше 10 строк ясного кода, чем 1 строка «магии».
• Выноси условия и преобразования типов в именованные функции.
• Делай код дебажабельным: минимизируй неявные преобразования, оставляй точки для пошаговой проверки.
• Стандартизируй стиль: линтер/форматтер + строгие ревью.
• Оптимизируй только после измерений, и локально — не «умни» весь код заранее.

---

Оригинал статьи: https://read.engineerscodex.com/p/clever-code-is-probably-the-worst