Блок 3 · Урок 2 из 5 · ≈ 8 минут · цель: не путать размер и простоту

Маленькое не всегда простое

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

Много частей: иногда больше переходов и больше контекста.

Простота: меньше обязательного знания для изменения.

Зачем это вам

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

Полезный вопрос: после дробления стало проще понять поведение или мы просто разложили одну мысль по нескольким местам?

Суть

Маленький модуль хорош, когда он имеет ясную ответственность и уменьшает внешнюю сложность.

Маленький модуль вреден, когда его интерфейс заставляет пользователя знать почти все детали порядка, состояния и ограничений.

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

Аналогия

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

Запомните одно

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

Фраза агента → что он имеет в виду

«Разобью на несколько функций»: Проверьте, каждая функция добавляет понятие или просто отражает один шаг исполнения.
«Так будет чище»: Попросите назвать, какая сложность стала скрытой и какое знание ушло из вызывающего кода.
«Соберу правила в одном месте»: Это хороший сигнал: дробление служит локальности, а не внешней аккуратности.

Мини-словарь

Shallow decomposition: Дробление, которое добавляет части, но не уменьшает сложность использования.
Local reasoning: Возможность понять изменение в одном месте без обхода всей цепочки.