Тантрическое программирование

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

Предисловие, или почему это не метафора

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

Речь пойдёт не о мистике ради мистики и не о том, как медитировать над pull request’ом. Речь о том, что великие инженерные традиции и великие духовные традиции описывают одну и ту же реальность — природу ума, встречающегося с задачей. И когда смотришь на них рядом, сходство оказывается пугающим по своей точности.

Тантра в своём исходном смысле — это не про экзотические ритуалы. Это система познания, в которой нет ничего запретного в качестве объекта изучения. Тантрик берёт любое явление — включая самое обыденное — и видит сквозь него структуру реальности. Программист, если он честен с собой, занимается ровно тем же.

* * *

Часть I. Два пути: дакшиначара и вамачара

Правая рука: когда порядок священен

В ведической традиции дакшиначара — путь правой руки — это путь через форму, ритуал, иерархию и строгое соблюдение правил. Каждое действие имеет своё место. Каждый элемент системы знает свою функцию. Отклонение от нормы не просто ошибка — это осквернение священного порядка.

В мире программирования этот путь воплощён в SOLID. Пять принципов, записанных как заповеди. Single Responsibility — каждый класс знает своё место в системе, как брахман знает свою варну. Open/Closed — написанный и освящённый код неприкосновенен; расширяй, но не оскверняй уже существующее. Liskov Substitution — наследники должны быть совместимы с предками; кастовая чистота линии обязательна. Interface Segregation — не навязывай лишнего, каждый интерфейс должен быть чист, как мантра. Dependency Inversion — опирайся на абстракции, а не на конкретные реализации; поклоняйся принципу, а не его воплощению.

Последователь правой руки строит архитектуру как храм. Каждый кирпич на своём месте. Тесты — это ежедневная пуджа, подтверждающая, что священный порядок не нарушен. Code review — это суд брахманов, следящих за чистотой ритуала.

И в этом есть подлинная красота. Система, построенная по правилам дакшиначара, поддаётся изменению. Новый разработчик приходит в неё как в упорядоченный монастырь: есть правила, есть традиция, есть карта. Он не тонет в хаосе — он учится у структуры.

Левая рука: когда цель важнее формы

Вамачара — путь левой руки — принципиально иной. Здесь практикующий намеренно нарушает обычные ограничения, чтобы обнаружить, что реальность не умещается ни в какую форму. Цель не в соблюдении ритуала, а в прямом контакте с тем, что есть.

В программировании этот путь — YAGNI (You Aren’t Gonna Need It) и KISS (Keep It Simple, Stupid). Не строй абстракцию, пока она не нужна. Не усложняй без причины. Реши задачу — именно ту задачу, которая перед тобой стоит, а не воображаемую задачу, которую ты додумал из принципа. Прямо сейчас. Этот код. Этот пользователь. Эта проблема.

Последователь левой руки смотрит на тщательно построенный храм SOLID и видит в нём потенциальную ловушку. Зачем три слоя абстракции для функции, которую вызовут дважды за всё время жизни системы? Зачем паттерн Repository, если это простое веб-приложение с одной базой данных, которая никогда не изменится? Священный порядок может стать тюрьмой, если его цель — сам порядок, а не то, ради чего он создавался.

* * *

Часть II. Пашу, вира и сиддха: три уровня практика

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

Пашу: животная привязанность

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

В программировании пашу-вамачарин пишет монолитный спагетти-код и называет это прагматизмом. «Зачем эти ваши паттерны? Надо просто решать задачи!» Но за этим риторическим вопросом скрывается не мудрость, а лень или непонимание. Он не выбирает простоту — он просто не умеет иначе.

Пашу-дакшиначарин — зеркальное отражение. Он строит четырнадцать слоёв абстракции для CRUD-приложения с тремя таблицами. Он отклоняет pull request, потому что там нарушен принцип инверсии зависимостей, хотя код решает задачу идеально. На его code review никто не хочет ходить, потому что встреча превращается в судебный процесс о чистоте архитектуры, где подсудимый — живая бизнес-задача.

Оба пашу страдают. Первый — от технического долга, который рано или поздно раздавит систему. Второй — от того, что его прекрасный храм стоит пустым, потому что бизнес умер раньше, чем архитектура была завершена.

Вира: осознанный нарушитель

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

Программист-вира знает SOLID наизусть. Он может объяснить, почему каждый принцип существует, какие проблемы он решает и что происходит, когда его нарушают. И именно поэтому он иногда его нарушает — когда видит, что в данном конкретном контексте цена соблюдения выше цены отступления.

«Да, я сделал здесь God Object», — говорит вира. — «Это прототип, у нас две недели до демонстрации инвесторам, и если мы не покажем работающий продукт, никакой архитектуры больше не будет вообще. Я поставил технический долг и знаю, что его надо отдать.»

Разница между пашу и вирой не в том, что они делают. Она в том, видят ли они то, что делают.

Сиддха: совершенный мастер

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

Опытный инженер, которого вы хотите в своей команде — это сиддха. Его не спрашивают «SOLID или YAGNI?» так же, как не спрашивают мастера дзен «дышать или не дышать?». Он смотрит на задачу — и код появляется соответствующий моменту. Без предварительного декрета о методологии, без холивара, без религиозного пыла.

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

* * *

Часть III. Майя технического долга

В веданте майя — это не просто «иллюзия» в примитивном смысле. Это сила, которая накладывает поверх реальности ментальные шаблоны и заставляет нас взаимодействовать со своими проекциями вместо того, что есть на самом деле.

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

Пашу видит технический долг и страдает. Вира видит технический долг и оценивает: когда и как его отдавать. Сиддха видит в техническом долге окаменевшую историю решений, каждое из которых было ответом на реальный вопрос в реальный момент. За каждым костылём — чей-то дедлайн. За каждым workaround’ом — чья-то растерянность перед задачей, которую не понимали до конца.

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

Скука как слепота

Есть один особый вид майи, характерный для программистов средней руки — это скука.

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

Пробуждённый взгляд не знает скуки не потому, что каждая задача объективно интересна. А потому что в каждой задаче — если смотреть по-настоящему — открывается бездна. Каждая строка легаси-кода — это археология. Здесь чей-то ум столкнулся с задачей и нашёл решение, казавшееся ему в тот момент лучшим. Здесь был страх. Здесь был дедлайн. Здесь была идея, которую не успели додумать.

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

Разработчик, которому скучно в легаси-коде, скорее всего не понял его по-настоящему.

* * *

Часть IV. Карма-йога и действие без привязанности к результату

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

Применительно к программированию это звучит провокационно. Как это — писать код и не думать о результате? Разве не ради результата мы здесь?

Но Кришна говорит не об отказе от результата как цели. Он говорит об отказе от результата как источника мотивации, которая искажает само действие. Программист, который пишет код из страха провала, пишет иначе, чем программист, который пишет из радости решения задачи. Программист, одержимый оценкой на code review, пишет иначе, чем тот, кто просто делает лучшее, что может в данный момент.

Карма-йога в коде — это когда чистота решения становится самоцелью не из принципиальности, а из естественной ясности ума. Мастер пишет хороший код не потому что боится технического долга, и не потому что менеджер смотрит в монитор. А потому что хороший код — это выражение ясного мышления, и ясное мышление приятно само по себе.

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

Фарисеи паттернов

Есть в Евангелии от Матфея один образ, который точнее всего описывает определённый тип архитектора. Это фарисеи — люди, которые так глубоко погрузились в Закон, что перестали видеть то, ради чего Закон существовал.

Когда принципы SOLID становятся самоцелью, они распинают бизнес-задачу. «Это нарушает принцип открытости-закрытости», — говорит архитектор, и задача отвергается. «Здесь нет слоя абстракции над репозиторием», — и рабочее решение признаётся негодным. Паттерн стал идолом. Буква убила дух. Как заметил апостол Павел в другом контексте: «буква убивает, а дух животворит».

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

Что характерно, фарисейство паттернов часто выглядит очень компетентно. Человек знает GoF наизусть. Он правильно использует терминологию. Он может провести впечатляющую лекцию о принципах чистой архитектуры. Но его системы не работают — или работают, несмотря на него, а не благодаря ему.

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

* * *

Часть V. Адвайта и различение: путь между двумя крайностями

Адвайта-веданта — недуалистическая философия — утверждает, что противоположности, которые мы воспринимаем как абсолютные, в конечном счёте разрешаются в единое. Это не значит, что противоположностей нет. Это значит, что они не являются последним словом о реальности.

Применительно к нашей теме: SOLID и YAGNI — не противоположные методологии, выбор между которыми определяет судьбу разработчика. Это два описания одной реальности с разных точек зрения. SOLID описывает, как структура кода влияет на его поддерживаемость. YAGNI описывает, как избыточная структура создаёт свои проблемы. Оба правы. Оба неполны. Мудрость — в их синтезе, а не в выборе между ними.

Ключевой инструмент для этого синтеза в ведической традиции называется вивека — различение. Это не свод правил и не интуиция в расплывчатом смысле. Это способность видеть контекст с достаточной ясностью, чтобы понимать, что здесь уместно.

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

Примечательно, что вивека не кодифицируется ни в какую методологию. Именно поэтому опытные инженеры так ценятся — и именно поэтому их опыт так трудно передать. Можно передать знание паттернов. Нельзя передать вивеку — только создать условия, в которых она развивается.

Пратибха: спонтанное творческое сознание

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

Это то состояние, которое программисты иногда называют потоком — flow. Когда решение появляется не как результат мучительного выбора между архитектурными паттернами, а как прямой ответ ума на задачу. Код течёт. Структура возникает сама, без насилия.

Характерно, что в состоянии потока хороший программист не думает ни о SOLID, ни о YAGNI. Он думает о задаче. Методологии становятся частью его интуиции — как грамматика для опытного писателя: она работает, но он не произносит её правила про себя в процессе написания.

Пратибха — это не мистическое состояние, доступное единицам. Это естественный результат достаточной практики в сочетании с достаточным присутствием. SOLID — это садхана, духовная практика, которая встраивает в ум правильные рефлексы. YAGNI — это напоминание, что садхана не цель. Пратибха — это когда оба растворились в действии.

* * *

Часть VI. Самадхи и освобождение

Самадхи в йогической традиции — это состояние, в котором субъект и объект познания перестают быть раздельными. Познающий и познаваемое сливаются в акте чистого познания.

В программировании это звучит метафорично, но имеет вполне конкретное содержание. Программист в состоянии самадхи — не тот, кто медитирует над клавиатурой. Это тот, кто настолько растворился в задаче, что перестал думать о себе как об отдельном от задачи существе. Исчез вопрос «как я выгляжу?», исчез страх оценки, исчезла привязанность к своему решению. Осталась только задача и её решение.

Такой программист может выбросить написанное им самим за день — без сожаления, если увидел, что это неправильно. Может принять чужое решение, которое лучше его собственного, — с радостью, а не со смирением. Потому что для него важна задача, а не его роль в её решении.

Дживан-муктти: освобождение при жизни

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

Применительно к нашей теме интересен дживан-муктти. Освобождённый не уходит в монастырь и не перестаёт писать код. Он продолжает делать то же, что делал раньше — но иначе. Он соблюдает ритуалы не потому, что нуждается в них, а потому что они полезны для тех, кто ещё на пути. Он следует конвенциям команды, даже если лично ему они кажутся избыточными, — потому что конвенция создаёт общее пространство понимания.

Мастер-программист пишет читаемый код не потому что боится review, и не потому что так написано в гайдлайнах. А потому что понимает: код читают люди, и их понимание — часть задачи. Он пишет тесты не потому что так правильно, а потому что тесты — это форма уважения к будущему, к тем, кто придёт после.

Действие без привязанности к результату — но с полной ответственностью за качество действия.

* * *

Часть VII. Практические следствия, или Зачем это всё

Эссе без практических следствий — это академическое упражнение. Поэтому несколько конкретных наблюдений.

О холиварах

Большинство споров о методологиях — SOLID vs YAGNI, монолит vs микросервисы, ООП vs функциональное программирование — это споры пашу. Каждая сторона защищает свою садхану, свою форму практики, как будто форма и есть истина.

Вира знает обе стороны и выбирает по ситуации. Сиддха не участвует в споре — не из равнодушия, а потому что вопрос «какая методология правильная?» для него так же странен, как для плотника вопрос «молоток или рубанок?». Зависит от задачи.

Если вы замечаете, что тратите много энергии на защиту своего архитектурного выбора — это сигнал. Не обязательно, что вы неправы. Но точно, что вы привязаны.

О коде review

Code review в идеале — это не судебный процесс и не экзамен. Это совместное рассмотрение задачи двумя умами. Когда review превращается в поиск нарушений принципов — что-то пошло не так.

Правильный вопрос на review не «нарушает ли этот код DIP?», а «решает ли этот код задачу, и можем ли мы поддерживать это решение?». DIP — инструмент ответа на второй вопрос, а не цель сама по себе.

О рефакторинге

Рефакторинг без понимания — это майя в действии. Прежде чем переписать легаси-код, стоит понять его. Не чтобы его оправдать — а чтобы не воспроизвести те же проблемы в новой, более красивой обёртке.

Лучшие рефакторинги — это те, после которых система работает лучше, но кода стало меньше. Худшие — те, после которых система работает одинаково, кода стало больше, но архитектура «чище».

О технических решениях

Каждое техническое решение — это осознанная ставка: что важнее сейчас, и что будет важнее потом? Правильного ответа не существует вне контекста. Существует честность в признании того, что вы выбираете.

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

* * *

Заключение: путь есть действие

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

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

Методологии — SOLID, YAGNI, KISS, DDD, TDD — это садхана. Духовная практика. Они работают на уровне тела: встраивают в ум правильные рефлексы, учат видеть определённые проблемы. Но как любая садхана, они — средство, а не цель. И мастер знает это.

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

Остальное — технический долг. В самом широком смысле.

* * *

Написано без привязанности к результату.