Автор: Sergey Teplyakov

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

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

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

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

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

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

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

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

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

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

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

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

Помогла статья? Оцените её!
0 из 5. Общее количество голосов - 0
 

You have no rights to post comments

Дмитрий Крикунов

Публикую статьи, обучающие курсы и новости по программированию: алгоритмам, языкам (С++, Java), параллельному программированию, паттернам и библиотекам (Qt, boost).