Команда Spring АйО перевела статью одного из создателей Hibernate, в которой он объясняет, почему ему часто приходится отвергать новые и хорошие идеи, и почему это на самом деле не означает, что он является врагом всего нового.

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

Позвольте мне начать с того, что хорошие идеи стоят недорого. Каждую неделю я в среднем выдаю одну или две хорошие идеи о том, как улучшить Hibernate, или Jakarta Persistence, или Jakarta Data, а когда я нахожусь посреди одного из тех периодов, когда я действительно сфокусирован на всех этих штуках — что означает, что я думаю о persistence 24 часа в день, даже когда ем или сплю, и баланс между жизнью и работой приходится посылать куда подальше — тогда я выдаю ближе к десяти хороших идей в день.

Естественно, поразмыслив здраво, я понимаю, что девять из десяти моих “хороших” идей — это полный мусор. Если оценивать оптимистично, одна из десяти оставшихся рано или поздно реализуются в Hibernate. И из этих выживших я предлагаю менее десяти процентов для включения в спецификации Persistence или Data. Некоторые из этих предложений отвергаются остальными членами группы или превращаются во что-то почти неузнаваемое. Иначе говоря, я должен генерировать тысячи идей, чтобы добавить одну новинку в платформу, и процесс от “идеи” до изменения спецификации обычно занимает годы, а в особых случаях даже десятилетия (я сейчас смотрю на тебя, StatelessSession).

Итак, что происходит, когда участник сообщества приходит к мне, предлагая что-то новое в спецификацию, такую как Persistence или Data? Прежде всего, очень важно понимать, что это предложение вряд ли будет “новым” в том смысле, что мы никогда не думали об этом раньше; огромное количество предложений касается стандартизации какой-то функциональности, которая уже существует в Hibernate, или в EclipseLink, или где-то еще; второй по величине класс предложений состоит из вещей, о которых мы уже думали долго и глубоко, возможно, больше десяти лет назад, и решили отказаться от этой идеи в силу очень правильных, но, возможно, неочевидных причин.

Так что же случается с оставшимися, действительно “новыми”, идеями? Скажем так, им придется подставиться под довольно суровый допрос с пристрастием.

Первая проблема состоит в том, что предложение чаще всего подается как решение, то есть, конкретный новый API или что-то похожее. Но нам действительно нужно начинать с понимания проблемы. Что именно мотивирует искать решение для того, что ощущается как проблема? Является ли эта проблема частным случаем более широкой проблемы, чем человек подумал изначально? Входит ли эта проблема в сферу компетенции нашей спецификации или это вообще не наше дело? И если да, то пришло ли время заниматься ее решением?

Если предположить, что мы достигли понимания проблемы и думаем, что она стоит того, чтобы попытаться ее решить, мы должны затем ознакомиться со всеми возможными решениями, разобрав каждое по кусочкам. На этой стадии вещи иногда начинают выглядеть неприятно. Очень легко прикипеть сердцем к одному конкретному решению, либо потому, что человек знаком именно с ним, потому что уже использовал его в другом месте, либо он придумал его сам, либо потому, что оно очень хорошо подходит под его сценарий использования, либо тут присутствует комбинация всех упомянутых факторов. И когда твою любимую идею кладут под микроскоп, это может быть некомфортно, особенно когда с этим микроскопом работает кто-то вроде меня, кто-то кому иногда бывает наплевать на ваши чувства (извините!).

Как сделать так, чтобы этот процесс работал лучше?

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

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

И теперь мы приходим к тому, что я считаю главной обязанностью привратника: избегать преждевременного принятия локального оптимума. Написание спецификаций не похоже на написание кода. Не самый оптимальный код может быть вполне неплохим кодом, потому что код можно легко поменять. API и семантика, заданные в спецификации, становятся более или менее высечены из камня. Исправление ошибок в них стоит очень дорого. Очень больно бывает возвращаться обратно спустя десять лет и думать, “черт, лучше бы мы сделали вот так!”

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

Рискуя скатиться в бесцельную болтовню, я хотел бы закончить на этом, приведя напоследок более общее наставление. Некоторые из вас думают, что наличие “софт скиллов” означает, что вы становитесь более приятным человеком. И это правда, что более приятным в общении людям проще живется в рабочем пространстве, более того, если думать эгоистично, это зачастую самая безопасная стратегия. Но “софт скилл”, который я считаю важным — это брать на себя полную ответственность за пост-эффекты сделанного тобой выбора. Например, как минимум одна из ошибок в спецификации Persistence, о которой я сожалею очень сильно — я сейчас думаю об ошибке, которая все еще вызывает боль сегодня, и которая наверняка стоила за эти годы миллионов долларов в потерянной продуктивности — была прямым результатом моего согласия на то, что, как мне казалось, было не совсем правильно, но мне не хотелось из-за этого бороться. Быть приятным человеком легко, но если всегда соглашаться на какие-то вещи и не раскачивать лодку, это может обернуться плохими последствиями для всех. Поэтому стойте за то, во что верите, только не упирайтесь в одну конкретную реализацию своих убеждений.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Идеи ничего не стоят