Что станет с вашим замечательным проектом в перспективе, если построить его на чужих технологиях? Многие подозревают, некоторые догадываются а я рассказываю.
Из первых рук и на личном опыте.
Фреймворк (Framework) — дословно «каркас», большая такая библиотека с окружением и утилитами, вокруг которой вы обязаны выстроить логику приложения по определенным правилам. Эдакий железный столб, на который намотано то что называется «собственной разработкой».
Любимые широкими массами Angular, React, Spring, Hibernate — те самые фреймворки.
Профит
Зайдем с козырей:
да, использование готовых фреймворков серьезно ускоряет разработку.
Особенно на начальном этапе и если вы работаете над проектом не один а в составе команды.
Еще фреймворки обычно создаются программистами более высокого уровня, чем те кто ими потом пользуется, поэтому сложные вещи, вроде авторизации, системы прав, валидации данных, обработки ошибок и подобного — в фреймворке будут реализованы лучше чем вы сможете сами и своими силами.
Также ввиду большего количества пользователей и сложного многоэтапного тестирования, фреймворк в большинстве случаев будет действительно надежнее, стабильнее и безопаснее чем ваш собственный софт.
К сожалению на этом все хорошее заканчивается и начинается бесконечное море проблем.
Проблемы и последствия
Самое очевидное и банальное, но одновременно слабо осознаваемое:
фреймворк — большой, сложный и не ваш.
Сколь‑нибудь серьезно повлиять на его развитие вы не сможете, предотвратить «поворот не туда» в его развитии, если такое вдруг случится — не получится, продолжить разработку вместо авторов у вас банально не хватит ресурсов, сил и времени.
Рассказы про «открытый код» и «возможность форка» на практике так рассказами и остаются (по большей части) — некому и некогда таким заниматься на обычном проекте в обычной компании.
Представьте масштаб работ по созданию полноценного форка с тестированием и последующей поддержкой акого‑нибудь Spring или Angular — годы работы для серьезной команды.
И это только «ширпотреб» — фреймворки общего назначения и широкого применения. А ведь еще есть нейросети, компьютерное зрение, распределенные вычисления, распознавание текста и прочие замечательные инструменты, со своей спецификой. Сделать форк например какого‑нибудь TensorFlow — задача вообще на грани реальности.
Резюмируя:
создавая проект на каком-нибудь Ангуляре вы
подписываете контракт с сатанойсоглашаетесь на последующие проблемы роста и возможное полное переписывание проекта ради начальной скорости разработки.
Вырезать из большого проекта Angular или React — очень непростое занятие.
Проблемы развития
Вспомните на минуту собственное детство, как вы росли, как росло и изменялось ваше тело — из младенца в ребенка, из ребенка — в подростка, из подростка в СИЗО во взрослую особь.
А теперь представьте, что в какой-то момент ваш скелет вдруг расти перестал:
Вот вам пять лет, спокойно себе бегаете кругами, затем вам 15, мыщцы, органы — все выросло, а скелет — нет.
Представили всю серьезность проблем и возможное влияние на будущее в таком случае?Вот нечто подобное происходит и с программами, если развитие одного из используемых ключевых фреймворков внезапно останавливается.
Полагаете, достаточно всегда придерживаться популярных решений, поскольку шансы на преждевременную кончину у известного фреймворка ничтожны?
Ознакомтесь с небольшим «списком павших»:
https://wiki.python.org/moin/WebFrameworks, раздел «1.5. Discontinued/Inactive Frameworks».
По каждой ссылке длинный такой список умерших проектов, многие из которых были когда‑то очень популярны. Так что преждевременная смерть в мире высоких технологий — обыденность, хотя к сожалению смерть это еще не самый плохой вариант.
Поворот не туда
Регулярно случается, что авторов вашего любимого фреймворка начинает спонсировать крупный вендор, который неизбежно начинает проталкивать в проект собственные интересы.
Ради которых авторы начинают удалять ненужный вендору функционал, убирать обратную совместимость, скрывать тесты или даже менять направление развития всего проекта.
Даже имея рычаги влияния (вроде спонсорского статуса), в такой ситуации мало чего можно сделать — если необходимый вам функционал авторы еще будут сопровождать на коммерческой основе, в долгосрочной перспективе это все равно не спасет.
В качестве примера:
однажды в проект JHipster пришел крупный спонсор Okta, у которого вся продуктовая линейка — про авторизацию и безопасность. С тех пор никаких вариантов авторизации через социальные сети в проекте нет — только через сервис Okta.
Весь функционал авторизации через социальные сети из JHipster был удален, с вполне официальной рекомендацией «используйте Okta», примеры также остались лишь с использованием сервисов Okta и Keycloak (еще один спонсор).
И никто из тысяч пользователей JHipster ничего с этим сделать не смог.
Лучшие мировые практики
Очевидно что данные концептуальные проблемы с чужими технологиями появились не вчера, но популярные проекты каким-то образом их все же решают.
Ниже описаны три известных автору подхода к решению, к сожалению все достаточно сложные, имеющие определенные риски и недостатки.
JIRA
Один из самых старых и известных багтрекеров, который видели наверное все, имеющие отношение к коммерческой разработке ПО.
Решение:
включить ключевой фреймворк целиком в состав своего проекта, затем развивать и поддерживать собственными силами.
Проект, основанный в далеком 2002м году двумя студентами на десять тысяч кредитных долларов, имел всего один вариант успешного развития: взять «что есть» из бесплатного и быстро‑быстро начать писать код.
Под рукой оказалось это:
Jira uses OpenSymphony’s WebWork 1 to process web requests submitted by users. Please note that WebWork 1, not 2, is used. WebWork 1 is a MVC framework similar to Struts. Each request is handled by a WebWork action which usually uses other objects, such as utility and Manager classes to accomplish a task.
Спустя 24 года, Atlassian Jira все также использует данный фреймворк, но разумеется уже сильно улучшенную и кастомизированную версию. Разработчики полностью интегрировали его в проект и поддерживают собственными силами.
Jenkins
Решение:
разработать собственный фреймворк, как часть проекта.
Jenkins (в девичестве — Hudson), этот знаменитый проект CI-сервера, с самого начала был построен на собственном веб-фреймворке. Спустя много лет, уже после достижения большого успеха и популярности, фреймворк вытащили наружу в виде отдельного проекта:
https://github.com/jenkinsci/stapler
Так что да, такой вариант тоже возможен.
Но стоит помнить, что Jenkins/Hudson создавался и долгое время поддерживался в одиночку, в качестве пет-проекта очень серьезным профессионалом с большим опытом, работавшим на тот момент в Sun Microsystems.
Поэтому у автора Jenkins получилось с этапа начальной разработки разделить логику между приложением и внутренним фреймворком — не было давления сверху, не было набора бизнес‑задач, как и ограничений по срокам и бюджету.
Насколько разумно повторять подобное в реалиях коммерческой разработки — очень большой вопрос, но прецеденты есть.
WildFly
Решение:
активное влияние на развитие всех используемых технологий, патчи в апстрим.
Wildfly — в прошлом JBoss, это такой сервер приложений, соответствующий спецификации Jakarta EE (ранее JEE и J2EE), очень популярный.
Разработкой данного проекта занимается компания Red Hat, когда‑то создавшая первый коммерческий дистрибутив Linux. Компания богатая, известная и имеющая серьезный вес в движении «Open Source».
Все это позволяет ей держать разработку используемых технологий под жестким контролем, фактически часть ключевых разработчиков используемых Wildfly библиотек и фреймворков (например Hibernate) — штатные сотрудники самой компании Red Hat.
Поэтому описанная чуть выше ситуация с JHipster, когда в ключевом фреймворке что‑то поменяется и затронет бизнес Red Hat — просто не может произойти.
В наших реалиях подобным образом могут поступать лишь очень немногие компании — попробуйте сами честно ответить на вопрос: кто из российских компаний имеет хоть какой-то вес в Open Source.
Личный опыт
Хотя автор и сталкивался на практике с описанными выше подходами и может подтвердить их работоспособность, вам врядли стоит считать их массовыми — продуктовая разработка все же очень индивидуальна и собственных программных продуктов в компаниях не так уж много.
Куда чаще проект является внутренним, либо неотделяемым сервисом, поэтому вопросы миграции и обновлений используемых библиотек и фреймворков разработчики стараются решать собственными силами, по мере накопления критических проблем.
Получается не всегда, временами объем накопленных проблем заставляет переписывать проект целиком с нуля, выкидывая предыдущую версию. Что в некотором смысле является нормой для современной разработки.
Некоторые примеры миграций и обновлений, которые автор проводил лично:
-
JQuery -> AngularJS -> Angular 2 -> Angular 5 -> Angular 8 -> Angular текущей версии
-
Java 1.2 -> 1.3 -> 1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8 -> 9 -> 11 -> 19 -> текущая версия
-
J2EE -> Spring
-
J2EE -> JEE -> Jakarta EE
-
MyBatis -> JPA
-
Swing -> JavaFX
-
Ant -> Maven -> Gradle
Исходя из данного опыта, могу поделиться с широкой аудиторией интересными выводами.
Cама миграция возможна практически всегда.
Ни монструозность размеры проекта, ни степень его устаревания не являются непреодолимым препятствием.
Основными ограничениями являются в первую очередь бюджет и время (что предсказуемо), а также направленность проекта — как уже упомянул выше, часто нет смысла мигрировать и обновлять внутренний проект, проще переписать с нуля.
Процесс миграции вполне предсказуем про срокам и по сложности.
Поскольку миграция на новую версию фреймворка это чисто техническая задача, она имеет однозначные границы и этапы. Ее даже вполне возможно встроить в обычный цикл разработки со спринтами, хотя и «со скрипом».
И в этом разительное отличие от популярного варианта «переписать все с нуля», который вам наверняка уже навязывали другие разработчики.
С переписыванием с нуля на самом деле все несколько сложнее и рисковее: таким переписыванием можно сломать «ощущение от использования» — набор паттернов поведения в системе, к которым пользователи привыкли:
кнопки определенного цвета и размера, расположение ключевых элементов и их внешний вид, переходы между экранами в определенной последовательности и так далее.
Что и случилось со знаменитым Skype — некогда пионером в задаче «позвонить через интернет» а ныне доживающим последние дни.
Эпилог
Процесс развития живого программного продукта сложен и неоднозначен, это по сути своей «марафон, а не спринт» — долгосрочный и многоэтапный процесс, при котором сиюминутные положительные результаты запросто могут навредить в долгосрочной перспективе.
Поэтому слепо ориентироваться на какую‑то «техническую моду» и непрерывно добавлять под капот вашего проекта новинки инженерии, когда есть живые пользователи и их потребности — не очень хорошая идея.
Фреймворки дают свой эффект лишь на начальном этапе, уже существующий большой проект они не спасут.
С другой стороны, победу вашего проекта на рынке и мировое доминирование предсказать невозможно, сможет ли он пробиться и найти место под солнцем — большой вопрос.
А пока такого не случилось, вполне разумно использовать любые «подручные материалы», в том числе те самые фреймворки — для сокращения издержек и ускорения разработки.
Как показывает опыт Facebook/Meta — если у вас есть миллиард, возможно мигрировать даже кодовую базу, созданную целиком на PHP.
P.S.
Это обновленная версия статьи, оригинал которой можно найти в нашем блоге.
Поскольку мы «собаку съели» и пару кошек на задачах миграции и обновления всевозможного legacy — в большинстве случаев сможем помочь и с вашим проектом, контакты в профиле.
ссылка на оригинал статьи https://habr.com/ru/articles/897656/
Добавить комментарий