Каждый разработчик начинает свой путь с набора «золотых правил». Чтобы упростить жизнь новичкам, я сам часто упаковываю эти правила в простые визуальные форматы — например, в такие карточки. Они отлично справляются со своей задачей: дают быструю и понятную выжимку основ.
Это — «уровень 1» понимания. Знать, что означают эти аббревиатуры.
Но дьявол, как всегда, в деталях. «Уровень 2» — это понимание того, что в реальном мире эти принципы постоянно конфликтуют друг с другом. Искусство хорошего программиста заключается не в том, чтобы слепо следовать каждому из них, а в том, чтобы мастерски дирижировать этим хаосом и находить правильный баланс.
Сегодня мы перейдем на «уровень 2» и посмотрим, как красивая теория с этих карточек разбивается о суровую реальность.
Фронт №1: DRY против KISS — битва с монстрами абстракций
Карточка говорит: «Не повторяйся» (DRY).
Реальность говорит: Благородное желание избавиться от дублирования кода часто приводит к созданию настолько сложных и универсальных конструкций, что они напрочь убивают простоту (KISS).
Представьте ситуацию: у вас есть две функции, делающие похожие, но не идентичные вещи. Новичок, вдохновленный карточкой про DRY, тут же бросится создавать одну «супер-функцию», которая умеет все. Она обрастает десятком аргументов-флагов, ветвится сложными if-else конструкциями и превращается в швейцарский нож, которым невозможно пользоваться.
Взвешенное решение: Здесь отлично работает «Правило трех».
- Увидели дублирование кода в двух местах? Смиритесь и живите с этим. Скорее всего, это мнимое дублирование, и логика этих частей со временем разойдется.
- Увидели дублирование в третий раз? Вот теперь пора остановиться и задуматься о рефакторинге. Вероятность того, что вы нашли общую закономерность, высока.
Преждевременная абстракция — худшее зло, чем осознанное дублирование. Две простые и понятные функции почти всегда лучше, чем одна сложная и запутанная.
Фронт №2: KISS против долгосрочного развития — ловушка простоты
Карточка говорит: «Делай проще, тупица» (KISS).
Реальность говорит: Увлекаясь идеей «сделать проще» сегодня, мы рискуем создать систему, которую будет невозможно развивать завтра. Это прямой путь к накоплению технического долга.
«Зачем нам какая-то архитектура? Напишу все в одной функции, так же проще!». «Зачем использовать готовую библиотеку? Я сам напишу пару строчек, это же просто!».
Такая «простота» — это мина замедленного действия. Сегодняшнее решение, написанное «на коленке», завтра потребует полного переписывания, когда бизнес-логика немного усложнится. Это не простота, а близорукость.
Взвешенное решение: Всегда задавайте себе вопрос: «Насколько вероятно, что эта часть системы будет меняться?». Если вероятность высока, стоит потратить немного больше времени и заложить чуть более гибкую структуру. Не нужно строить космолет (привет, YAGNI), но и собирать машину из палок и скотча тоже не стоит. Думайте о коде не как о сиюминутном решении, а как об инвестиции в будущее проекта.
Фронт №3: YAGNI против здравого смысла — апология хардкода
Карточка говорит: «Тебе это не понадобится» (YAGNI).
Реальность говорит: В крайнем своем проявлении этот принцип превращается в оправдание для написания хрупкого, негибкого кода.
«Зачем выносить этот параметр в конфиг? Нам же пока не нужно его менять. Захардкодим!». «Зачем предусматривать обработку разных типов данных? Мы же пока работаем только с одним».
Это приводит к тому, что когда функционал все-таки понадобился, его внедрение превращается в боль. Приходится перелопачивать код в десятках мест, вместо того чтобы поменять одну строчку в конфиге.
Взвешенное решение: YAGNI — это не про отказ от продумывания архитектуры. Это про отказ от реализации конкретных фич, которые не требуются прямо сейчас. Вынести магические числа в константы или настройки — это не фича, это гигиена кода. Заложить возможность для расширения, не реализуя само расширение, — это мудрая предусмотрительность, а не нарушение YAGNI.
Итог: Код — это искусство баланса
Не существует серебряной пули. Принципы с красивых картинок — не законы физики, а скорее полезные эвристики, компасы, которые помогают ориентироваться. Настоящее мастерство разработчика — это умение чувствовать контекст и понимать, каким компасом воспользоваться в данный момент, а какой лучше отложить в сторону.
Код должен быть не просто «простым» или «не повторяющимся». Он должен быть адекватным текущей задаче и будущим вызовам.
Хотите больше таких разборов и нюансов? Подписывайтесь на мой Telegram-канал PythonTalk.
