80LevelElf about IT Записи Мои проекты Обо мне
Давно не писал не сюда - работа и личный проект не давали передышки. Но вот появилась минутка - а с ней и желание написать. ## И сегодня я напишу про "велосипедостроение" Начнем с теории. Две основные крайности в этом вопросе обозначают как: 1. Not invented here (изобретено не нами) - ситуация, при которой любое новшество отклоняется, так как было создано вне конкретной компании или команды. 2. Proudly found elsewhere (с городостью найдено в другом месте) - ситуация, когда любая внешняя разработка считается предпочтительнее внутренней, просто потому, что она внешняя. Если закрытые совковые организации явно тяготеют к "изобретено не нами", то стильные, модные и молодежные IT компании обычно находятся с другой стороны забора и посмеиваются над "созданием велосипедов". Но ведь оба пути - это крайность. В обоих случаях вы принимаете идеологически догмы в качестве простого ответа на сложный вопрос. Но так как современное коллективное бессознательное IT сообщества создается компаниями с западным мышлением, то доминирующая крайность - "не создай себе велосипед". И как вы уже поняли - я с этой позицией не согласен. ## Просто затащи serilog Несколько месяцев назад понадобилось для работы написать среднего размера мигратор данных. Вытащить данные из старой системы, положить в новую. Мы пришли к идее о том, что самым хорошим и простым решением будет CSV файлик как промежуточное звено между старой системой и новой: ![](https://i.imgur.com/WjWS664.jpg) > Маленькое отступление - использовать CSV было очень **дерьмовой** идеей, но сейчас не об этом Схема была простой - берем каждую строчку из CSV и пытаемся сохранить в нужном нам виде в новой системе. В случае падения - группировать ошибки. Например, строки 1, 6 и 9 CSV файла упали с одним и тем же исключением Х. Пишу на коленке LogManager из 100 строк, добавляю его в систему - готово. Конечно, после первого запуска что-то упало, но в целом на создание логов ушло меньше часа. Первой реакцией коллег было - почему бы просто не затащить serilog? И это ведь не глупый вопрос. Действительно - почему бы просто не затащить serilog? ## И все-таки не надо Первая проблема с которой мы сталкиваемся - это цена интеграции. Если мы выбираем ORM для всего бекенда, лишние пару часов не будут играть никакой роли. Но я ни раз видел, когда люди тратили на интеграцию чужой библиотеки больше времени, чем заняло бы самописное решение проблемы. Не ожидайте, что чужая библиотека будет работать как надо с первого раза. Вторая проблема - это цена поддержки. Каждый баг, который вы находите в чужой библиотеке - это огромная головная боль. Вы **никогда** не будете нормально ориентироваться в чужой библиотеке. Вы можете знать как она работает в теории, прочитать документацию вдоль и поперёк - но это вас не спасёт. Субъективно, проблема в чужой библиотеке обходиться где-то в 10 раз дороже проблемы в собственном коде. > Думаете, что все известные библиотеки содержат так мало багов, что вы на них никогда не нарветесь? А что если я скажу, что нарвался на [баг в коде самого Джона Скита](https://stackoverflow.com/questions/44087757/partly-negative-period-between-2-dates-with-nodatime)? ## И что теперь всегда писать велосипеды? Конечно нет. Нет смысла пытаться написать самому все - это глупо и экономически неэффективно. Написать свой брокер сообщений? Или даже библиотеку для работы с брокером сообщений? Нет ребята - это никогда не окупится. Для себя я вывел эмперическое правило - если что-то может быть написано за 3-4 дня, то это нужно написать самому. Если работа займет больше времени - стоит поискать готовое решение.
(11.11.2018)

blog comments powered by Disqus