В части тех технологий (языков программирования), где есть пакетные менеджеры и сообщество разработчиков, безвозмездно предлагающие OpenSource-решения, существует негласное правило клиентов, использующих открытый код: мы ничего сами не пишем, а берём готовые решения и строим из них систему. Как дом из кирпичей.
Отчасти это продиктовано не столько ленью разработчиков, а современным темпом написания информационных систем: вряд ли бизнес поймёт и оценит, если команда начнёт месяцами (или даже годами) писать свои собственные велосипеды, например, с нуля разрабатывать систему определения перцептивного хэша изображения или свою собственную ORM.
Казалось бы, всё просто: бери эти кирпичи и строй систему, оперируй лишь интерфейсами. Но данный путь похож на становление наркотической зависимости: сначала легко, просто и прикольно. Проходит время - и начинаются проблемы, вплоть до терминальной стадии проекта и нервной системы разработчиков.
Две основные проблемы "халявного" кода
I. Контрибьютеры, любящие переписывать архитектуру с нуля
Фреймворк или библиотека, которую используют тысячи людей, на функционале которой завязаны сотни серьезных продуктов, в один миг становится устаревшим решением с выходом новой версии. Интерфейсы и архитектура меняется контрибьюторами, причём настолько кардинально, что новый продукт B вообще не похож на старый продукт A. Как следствие:
-
На собеседованиях уже спрашивают именно про продукт версии B. То, что ты работал с продуктом версии A - никого не волнует. Тот самый временный характер капитала знаний - неявный и коварный минус половины IT-индустрии, о котором никто никогда не говорил на профильных IT-ресурсах десятилетиями, кроме нашего сайта.
-
Небольшие пакеты, которые писались под версию продукта A (назовём их AA) больше не поддерживаются их авторами - в первую очередь пропадает мотивация поддерживать код для уже устаревшего решения. Ну и авторы этих пакетов в течении последующих нескольких лет могут умереть, покинуть IT или переключиться на другой стек без какого-либо интереса к своей прошлой деятельности.
Зависимости (назовём их AAA), если таковые присутствуют в AA тоже изменяются, но в пакете AA жёстко зафиксирована связь со старыми версиями зависимостей AAA, в которых имеется куча старых багов и, возможно, несовместимостей с новой версией самого языка программирования.
- И самое главное - невозможность обновить продукт версии A до продукта версии B.
I. Контрибьютеры, "забивающие" на свои решения
Вот тут я искренне не понимаю, встречал такое много раз: библиотека имеет живого автора, который отвечает раз в 2 года. Пара десятков issue и столько же MR. Ну ты это... либо заархивируй проект, либо найди время и разберись. Люди тебе доверились, ты получил свои "звёзды", а когда всплыла куча проблем, то "ни себе ни людям" - и проблемы не решаются и MR не проходят...
Итог
Проект, который начинался на "модных молодёжных технологиях", с выходом новых версий ПО становится устаревшим за несколько лет. Обновить - не реально. Переписать - тем более. Даже каких-то мелких вендоров уже не прикрутить - всё ломается, сбоит и глючит. А потребность в вендорах в виду требований бизнеса не прекращается - то библиотеку для работы с PDF нужно внедрить, то читалку Excel-файлов.
Так зарождается т.н. legacy-код. Legacy - это неизбежный исход для любого проекта, технологическая база которого развивается непрерывно.
Ну и закончить статью хочется цитатой одного автора, который на заре существования этого сайта часто выдавал базу:
Если и идти в программирование, то какое направление и стэк технологий выбрать, чтобы была стабильность и не нужно было бы учиться всю жизнь.
Ты однозначно ошибся с профессией, если думаешь, что тут есть хоть намек на стабильность. Зайди лучше к сварщикам, у них все относительно стабильно.
Комментарии (252)