`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Константин Введенский

Копия копии, сделанной с копии… (или пост-уроборос)

+33
голоса

Необходимость в новых разработчиках растет экспоненциально, число открытых вакансий скоро достигнет количества строк кода, которое генерируется каждый день. Замкнутый круг из двух больших «надо» - больше и кода - разрывается только повторным использованием компонентов. Повторное использование эволюционирует в открытый исходный код и сообщество разработчиков вокруг продукта. Кажется, вот оно, счастье?..

Внимательный читатель заметит, что пропущен один важный этап переиспользования кода – общие библиотеки. И последствия, которые он принёс в виде DLL hell. Понадобилось без малого лет 20, чтобы минимизировать его влияние и избавиться от проблем с зависимостями.

В современном мире ситуация чуть сложнее: непонятные сторонние библиотеки превратились в открытые продукты, разрабатываемые сообществом. В итоге вместо одного чёрного ящичка с небольшим API и относительно понятными багами надо использовать целый чёрный короб собираемый целой деревней. А развитие и гегемония Linux на серверах привела к популяризации *nix way – один инструмент на одну задачу.

Но в последнее десятилетие мир сместился в сторону DevOps и ощутил значительное влияние части со стороны разработчиков на операционную (и инструментальную). Простые, кажется, инструменты стали целыми framework`ами. Всё обросло API. Конечно же, RESTful, ибо SOAP сложен, избыточен и вообще Java жаба.

Продукты, разрабатываемые сообществом (с ударением) имеют и тёмную сторону медали: сообщество определяет всё. От видения продукта до манеры общения внутри и снаружи. Некоторые продукты, достигшие критической массы и при должном желании со стороны сообщества, переходят на следующий этап развития – более зрелый и корпоративный. Примеров таких много хотя они и очень разные: Kubernetes, ядро Linux, Apache (оба варианта), Python и т. д. Туда же можно добавить CNCF как питомник, школу и акселератор.

У всех этих продуктов одно интересное общее свойство: коммерческий продукт, выпускаемый на основе открытого ПО. Мне кажется, что в момент, когда видение развития продукта переходит с этапа я (автор) или мы (ядро сообщества, скорее всего близкое автору ментально) так вижу/видим на нужды внешних пользователей, происходит слом необходимый для дальнейшего развития продукта.

Например, возьмём тот же REST API. Не существует чёткого определения или стандарта - что такое RESTful API. Есть, выработанный годами, набор практик и подходов, огромное влияние на которые оказал AWS API. С помощью него AWS решала проблему заказчиков (читай - искал способ заработать) и на его примере показала, как именно удобно реализовать инструмент для всех. Не только для себя и не для решения собственных узконаправленных задач.

Почему простые продукты становятся framework`ами? Вопрос настолько же многогранный, как и почему не все продукты-фреймворки, в итоге, успешны.

Одна из причин форки. Форки сделанные или форки несделанные. Другая - количество и избыточность технологий. Решение своей чуть отличной от стандартной задачи своим чуть другим способом.

Когда сталкиваются протон и электрон происходит примерно то же что и при попытке сторонней компании развивать продукт, имеющий глубокие корни в community разработке. То есть форк. И его нужно развивать и поддерживать, на него требуются ресурсы и новые разработчики. А них открывают новые вакансии…

Вы можете подписаться на нашу страницу в LinkedIn!

+33
голоса

Напечатать Отправить другу

Читайте также

 
 

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT