В предыдущей статье я попробовала описать типы привязанности как сетевые протоколы, разобраться, как большинство из нас строит отношения. Было сделано предположение, что типы привязанности — те невидимые протоколы, по которым наше сердечко подключается к другим людям. Кто-то легко доверяет и остаётся на связи даже в шторм. Кто-то постоянно проверяет: «Ты ещё здесь?». А кто-то заранее закрывает порты, чтобы не рисковать.

И после возникает логичный вопрос: Если привязанность — это протокол, то кто его настроил?

От КАК к ПОЧЕМУ

Первая статья серии отвечала на вопрос «как» мы создаем связи с людьми и ведем себя в отношениях. Эта статья станет попыткой приоткрыть завесу и найти ответ на вопрос «почему».

Если представить вашу психику как приложение, то:

  • Привязанность — это то, как вы подключаетесь к другим.

  • Детство — это среда, где был написан исходный код.

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

Не для того, чтобы найти виноватых. Не для того, чтобы сказать: «Всё плохо, и это неисправимо». А для того, чтобы понять. Понимание — это уже половина свободы. Когда вы видите, откуда растёт ваш паттерн, он перестаёт быть «просто мной» и становится «кодом, который можно переписать».

Эта тема может задеть за живое. Может вызвать грусть, злость, сопротивление. Это нормально. Моя цель — дать вам подсказку, показать путь к тому, как можно стать Архитектором своей жизни. Не исполнителем чужих скриптов, а Автором своего кода.

  • Если вы читали первую часть и узнали себя — здесь вы, возможно, найдёте ответы на «откуда это во мне».

  • Если вы замечаете повторяющиеся сценарии в отношениях — поймёте, где они записаны.

  • Если вы хотите что-то изменить, но не знаете с чего начать — здесь будут инструменты.

  • Если у вас сложные отношения с родными — эта статья написана так, чтобы речь шла о функциях, а не о биологии. Без вины. С пониманием

  • Если у вас всё хорошо — здесь вы найдёте способы поддержать то, что уже работает. И передать следующему поколению более красивый (или чистый?) код.

Hello World — первый репозиторий

Представьте, что вы — приложение. У вас есть интерфейс (то, как вас видят другие), бэкенд (внутренние процессы) и API (способы взаимодействия с миром). У вас есть баги (паттерны, которые мешают) и фичи (сильные стороны). Вы регулярно получаете обновления (новый опыт) и иногда — критические уязвимости (травмы).

Вопрос: Где был написан ваш исходный код?

Если продолжить метафору — первая версия вас была разработана в детстве и чаще всего в семье. Это был ваш localhost, среда разработки, где вы провели первые 18+ лет. Там были созданы базовые скрипты:

  • Как доверять миру

  • Как строить отношения

  • Как обращаться с эмоциями

  • Чего ожидать от других

  • Кто вы вообще такой

И самое важное: вы не выбирали эту среду разработки. Вам выдали доступ к репозиторию значимых взрослых — со всем их legacy-кодом, недокументированными зависимостями и скрытыми багами.

Жизненные сценарии как реализация кода

В транзактном анализе есть такое понятие как жизненный сценарий. Это бессознательный план, по которому человек живёт свою жизнь каждый день. В ИТ-терминах:

Жизненный сценарий = Runtime-реализация вашего кода

Код написан в детстве, но исполняется всю жизнь. И если в коде есть ошибка — она будет воспроизводиться снова и снова, пока вы не найдёте и не исправите её.

Например, код мог быть записан в возрасте 10 лет, когда значимые взрослые хвалили только за пятёрки. Но исполняется он и в 30, когда вы горите на работе ради одобрения значимого для вас человека (тимлида).

# Сценарий: "Я должен быть идеальным"
def self_worth(achievement):
    if achievement.perfection_level >= 100:
        return "temporary_ok"
    else:
        return "shame"

# Запускается каждый раз, когда вы что-то делаете
# Результат: хроническое чувство "недостаточно хорош"

Как создается исходный код?

Код не пишется за один день. Это постепенное накопление коммитов на разных этапах взросления:

Возраст

Что записывается

IT-метафора

0–1 год

«Мир безопасен / опасен»

Boot Configuration

1–3 года

«Можно ли мне иметь границы?»

Permission System

3–6 лет

«Можно ли мне хотеть?»

Core Business Logic

6–12 лет

«Я компетентен / беспомощен»

Skill Tree

12–18 лет

«Кто я вне семьи?»

Fork / Identity

Каждое взаимодействие со значимыми взрослыми — это коммит в репозиторий. Некоторые коммиты задокументированы («мы тебя любим»), некоторые — нет (холодность, игнор, противоречивые сигналы).

И вот что важно: ребёнок не может выбрать, какой код будет записан. Он вынужденно адаптируется к среде. Если среда требует молчать — пишется код suppress_emotions(). Если среда требует быть идеальным — пишется код perfectionism_check(). Если среда непредсказуема — пишется код hypervigilance_monitor().

Это не баг. Это адаптация, способ выжить. И вот этот сложный код как-то работал в тестовой среде (в семье), а после вы выносите его в production (во взрослую жизнь).

Какие сценарии возможны?

Вот несколько типичных «сценарных скриптов», которые мы видим на практике:

Сценарий 1: «Спасатель»

def handle_relationships(problem):
    if problem.severity > 0:
        self.sacrifice()
        fix_for_other()
    return "worth_through_service"

Откуда: Ребёнок научился, что любовь = полезность.
Во взрослой жизни: Отношения через служение, выгорание, обиды.

Сценарий 2: «Недостаточно хорош»

def evaluate_self(achievement):
    if achievement < perfection_threshold:
        return "shame"
    else:
        return "temporary_relief"  # не радость, а облегчение

Откуда: Хвалили только за достижения, имеющие ценность для взрослых. Во взрослой жизни: Перфекционизм, прокрастинация, выгорание.

Сценарий 3: «Не доверяй никому»

def handle_intimacy(request):
    if request.type == "emotional":
        raise ConnectionRefusedError("Too risky")
    return "isolation"

Откуда: Эмоциональная недоступность значимых взрослых, они непредсказуемы. Во взрослой жизни: Избегающая привязанность, одиночество.

Сценарий 4: «Не обременяй»

def express_need(need):
    if need.intensity > "minimal":
        suppress()  # Подавить, чтобы не грузить систему
    return "invisibility"

Откуда: Значимые взрослые были перегружены: работа, выгорание, кризис, много детей. Во взрослой жизни: Гипернезависимость, трудности с просьбами о помощи, «я сам», невидимость для других.

Сценарий 5: «Исправь значимых взрослых»

def handle_caregiver_mood(mood):
    if mood == "bad":
        self.adjust_behavior()
        try_to_fix()
    return "responsibility_for_others"

Откуда: Парентификация (смена ролей в семье, ребенок вынужденно взял на себя ответственность за состояние взрослых), ребёнок стал эмоциональным контейнером. Во взрослой жизни: Отношения с «трудными» партнёрами, желание спасать.

Важное уточнение: семейные сценарии редко запускаются по одному. Чаще это набор микросервисов, которые работают параллельно: где-то срабатывает «не доверяй», где-то — «будь удобным», где-то — «справляйся сам».

Пока сценарий работает в фоне (background process), вы будете думать: «Это просто моя личность». Но это не совсем так и не только личность. Во всем этом есть и "код, который был когда-то написан".

И хорошая новость: код можно переписать. Не весь. Не сразу. Но можно:

  1. Найти проблемные скрипты (наблюдение)

  2. Понять, зачем они были нужны (контекст)

  3. Решить, работают ли они сейчас (аудит)

  4. Переписать те, что мешают (рефакторинг)

И да, идеальных семей, скорее всего, не существует. Как не бывает проекта без технического долга. У всех есть legacy. У всех есть баги, которые передались по наследству.

Core Dependencies: Значимые взрослые и другие сервисы

В программировании есть понятие dependency — внешний модуль, от которого зависит работа системы. Вы можете выбрать библиотеки для своего проекта. Но в детстве зависимости были прописаны принудительно.

Два основных сервиса, на которых держалась система в детстве:

  • Первичная забота → Primary Backend Service (в статье условно «Мать»)

  • Защита и социализация → Security Gateway / External API (в статье условно «Отец»)

Важное уточнение:

В этой статье термины «Мать» и «Отец» используются не как биологические роли, а как функциональные сервисы в системе развития ребенка. Эти сервисы могут предоставляться кем угодно:

Сервис

Функция

Кто может быть «провайдером»

Primary Backend

Забота, принятие, базовая безопасность и доверие миру

Биологическая мать, бабушка, отец-одиночка, приёмный родитель, няня, старший сиблинг

Security Gateway

Границы, социализация, защита от угроз

Биологический отец, мать, дедушка, тренер, учитель, наставник, любой значимый взрослый

Ключевой принцип: Психике важно не «кто по паспорту», а какую функцию выполняет человек. Если биологический отец отсутствует, но есть дедушка или дядя, который транслирует правила и защищает — дед (дядя) и есть Gateway для этой системы. Если значимый взрослый в депрессии, а заботу и любовь даёт бабушка — бабушка становится Primary Backend.

Primary Backend Service (условно «Мать»)

Британский педиатр и психоаналитик Дональд Винникотт ввёл понятие «достаточно хорошая мать». Это не идеальная мать, но ее роль наиболее важна в первые 3 года жизни ребенка, когда формируется базовое доверие к миру. Это значимый взрослый, который:

  • Отвечает на потребности ребёнка в большинстве случаев

  • Иногда ошибается — и это нормально

  • Восстанавливает связь после разрывов

В наших терминах:

Параметр

IT-метафора

Норма (Healthy)

Отклонение (Issue)

Доступность

Uptime SLA

~95%

100% (гиперопека) или <80% (недоступность)

Реактивность

Response Time

Чуткий ответ

Задержки или игнор

Предсказуемость

Consistent API

Стабильное поведение

Хаотичные ответы

Границы

API Rate Limit

Есть, но гибкие

Нет или слишком жёсткие

Восстановление

Auto-Reconnect

Разрыв → ремонт

Разрыв → тишина

Ключевая мысль

«Достаточно хороший значимый взрослый» — это не 100% uptime. Это сервис с разумным error handling.

Именно в моментах «разрыв → восстановление» ребёнок учится:

  1. Мир не рушится от ошибок

  2. Связь можно восстановить

  3. Я переживу фрустрацию

Если значимый взрослый всегда идеален (100% uptime) — ребёнок не учится справляться с фрустрацией. Если значимый взрослый всегда недоступен (<80% uptime) — ребёнок учится не доверять миру.

Типовые сбои Backend-сервиса

Сбой

IT-описание

Психологический аналог

Последствия

Hyperavailability

Uptime 100%

Гиперопека, слияние

Трудности с автономией, сепарацией

Silent Fail

Dropped Packets

Эмоциональная недоступность

«Мои потребности не важны»

Random Timeout

Inconsistent Response

Непредсказуемость

Тревожность, гипербдительность

Overloaded

High CPU Usage

Значимый взрослый в депрессии/выгорании

Ребёнок учится не беспокоить

Wrong Protocol

HTTP on FTP Port

Любовь через контроль

«Меня любят, когда я удобный»

Security Gateway / External API (условно «Отец»)

Если Primary Backend — это внутренняя среда (питание, забота, базовая безопасность), то Gateway — это шлюз между внутренней системой и внешним миром.

Функция

IT-метафора

Описание

Защита

Firewall

Защищает диаду caregiver-ребёнок от внешних угроз

Социализация

External API

Помогает выйти за пределы семьи

Правила

Business Logic

Транслирует нормы внешнего мира

Поддержка

Load Balancer

Распределяет нагрузку в системе

Ключевая мысль

Gateway — это не «второй значимый взрослый». Это отдельный сервис с собственной функцией.

Если Primary Backend учит доверять, то Gateway учит взаимодействовать с миром за пределами семьи.

Типовые сбои Gateway-сервиса

Сбой

IT-описание

Психологический аналог

Последствия

Gateway Missing

No Firewall

Фигура отца отсутствует физически/эмоционально

Нет защиты границ, уязвимость

Gateway Timeout

Connection Timeout

"Отец"эмоционально недоступен, хотя физически присутствует

Чувства — это что-то, на что нет ответа

DDoS Protection Too Aggressive

Overprotective Firewall

Чрезмерный контроль

Трудности с автономией, бунт

Wrong Routing

Misconfigured Routes

Ценности и правила, которые не соответствуют реальной среде

Когнитивный диссонанс, пересмотр ценностей во взрослом возрасте

Brute Force Attack

Aggressive Access

Насилие, критика

Внешний мир = угроза

Third-Party Services: Другие значимые фигуры детства

Довольно часто семья это не только два основных сервиса. Вот как выглядят другие фигуры в предложенном фрейме:

Фигура

IT-метафора

Функция

Бабушки/дедушки

Legacy Support

Поддержка старых версий, связь с историей семьи

Сиблинги (братья/сёстры)

Peer-to-Peer Network

Первые отношения с равными, тренировка социальных навыков

Учителя/наставники

Code Reviewers

Внешняя оценка кода, обратная связь

Друзья семьи

Trusted Certificates

Дополнительные доверенные узлы сети

Травмирующие фигуры

Malicious Packages

Внедряют вредоносный код (страхи, стыд)

Важное замечание

Не все зависимости должны быть активны в проде.

Некоторые third-party services были нужны в localhost (детстве), но во взрослой жизни их можно оставить как есть, а можно:

  • Отключить (disable dependency)

  • Заменить (swap provider)

  • Обновить (upgrade version)

Это и есть часть сепарации, развития и взросления каждого из нас.

Migration Guide: Как переписать код, не сломав систему

Принцип 1: Не вините разработчиков

Значимые взрослые действовали из своего legacy. Они передали то, что получили. Без вины, но с ответственностью

Метафора: Blameless Postmortem — разбор инцидента без поиска виноватых.

Принцип 2: Аудит кода

Прежде чем рефакторить — поймите, что работает, а что нет

Чек-лист:

  • Какие паттерны помогают мне в жизни?

  • Какие паттерны мешают?

  • Откуда они пришли?

  • Что я хочу сохранить?

Принцип 3: Постепенная миграция

Не делайте DROP DATABASE. Реализуйте постепенную миграцию.

Возможные стратегии вашей новой версии себя:

Стратегия

IT-метафора

Психологический аналог

Fork

Создать свою версию

Сепарация, своя семья

Patch

Точечные исправления

Терапия, работа с конкретными паттернами

Wrapper

Обёртка над legacy

Компенсаторные стратегии

Rewrite

Полная перепись

Глубокая трансформация (редко нужно)

Принцип 4: Тестирование

Прежде чем внедрять изменения в production — тестируйте.

Практика:

  • Пробуйте новые паттерны в безопасной среде (терапия, близкие отношения)

  • Отслеживайте error logs (тревога, вина, сопротивление)

  • Делайте rollback если слишком тяжело

Принцип 5: Документация

Запишите свои новые правила ❤️

# Personal Config v2.0
boundaries:
  caregivers: read-only access
  partner: full access with ACL
self_care:
  priority: high
  schedule: daily

Open Issues & Contributions

Эта статья, надеюсь, не останется монологом. Хотелось бы, чтобы текст стал началом разговора. И я приглашаю вас поучаствовать.

1. Оставьте лог в комментариях. Какой инсайт стал для вас самым неожиданным? Что «кликнуло» при чтении?

2. Предложите метафору. Как бы вы назвали свой процесс сепарации в терминах IT — Fork, Deploy, Migration, Refactor?

3. Запрос фичи для v1.3. Какую тему хотели бы разобрать следующей? Выгорание, команда, архетипы, синдром самозванца?

4. Поделитесь с тем, кому это нужно. Отправьте статью коллеге, другу или тому, кто сейчас в процессе «миграции» от родительской системы. Иногда один вовремя полученный код-ревью меняет всё.

Ключевая мысль статьи

Текст создан с целью понять архитектуру. Стать архитектором своей системы, а не исполнителем чужого кода.

Вы не можете переписать историю коммитов. Вы не можете выбрать репозиторий, в котором родились.

Но вы можете решить:

  • Какой код пойдёт в следующий релиз

  • Какие зависимости оставить, а какие — отключить

  • Кто будет иметь доступ к вашей системе

  • Какие протоколы использовать в отношениях

Это и есть свобода. Не в том, чтобы не иметь legacy. А в том, чтобы осознанно работать с ним.

Важное напоминание: Данная статья является метафорическим материалом для самоанализа и не заменяет профессиональную психотерапию. Тема может вызвать сильные эмоции. Если вы чувствуете сопротивление, гнев, грусть — это нормально. Иногда лучший рефакторинг происходит с внешним консультантом (терапевтом).