Синдром “придумано не нами”

Ваш код сегодняшний, коллега
Напоминает даунхил:
Среди деревьев и гов#@ща –
Велосипед и костыли ...
Народная мудрость

Пару лет назад я сделал небольшой цикл заметок о паттернах поведения: Технический долг, Синдром рефакторинга и Эффект второй системы. Пришло время обсудить еще один, наверное, самый известный и популярный паттерн поведения – синдром «Придумано не нами» (NIH, Not Invented Here).

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

У «забить на существующее и сделать по-своему» есть несколько причин.

Во-первых, разработка с нуля – это lot of fun! Сделать свою конкурентную коллекцию, собственный менеджер по обмену сообщениями, или собственный ORM, - это же интересно! Это действительно классный способ узнать что-то более детально. Вот, правда, поддерживать чужие творения подобного рода – удовольствие ниже среднего.

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

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

В-четвертых, ты можешь думать, что у тебя получиться лучше. Никто не может написать нормальную библиотеку конкурентных коллекций, а ты сможешь. Никто не может реализовать свой собственный Key-Value Store, но только не ты! Тут есть два варианта: ты изучил разные реализации, и четко понимаешь, в чем у них проблемы и как от них избавиться. В этом случае ты просто не берешь в новое решение весь багаж накопленных ошибок из старых решений, а начинаешь с чистого листа. Ты не используешь готовый код, но точно используешь накопленный тобой и другими опыт. В итоге может получиться что-то хорошее, полезное и для тебя, и для других (Roslyn – отличный пример такого подхода).

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

Повторное использование vs. Изобретение велосипеда – это типовой компромисс, на который идут индивидуальные разработчики, команды разработчиков и целые компании. В Microsoft есть 4 разных системы для сбора и анализа телеметрических данных, десяток клонов анализаторов IL-кода и сотни или даже тысячи реализации коллекций всех мастей. И так в любой компании.

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

Распространение NuGet-ов и других менеджеров пакетов упрощают потребление сторонних компонентов и делают полезное дело в плане повторного использования. Но это интересное сочетание программистского пессимизма («все делают всё плохо») и оптимизма («но я сделаю всё хорошо»), никогда не убъет синдром “Not Invented Here” полностью. Что, может быть, не так и плохо;)