В одной из дискуссий на RSDN был задан вопрос:
Бывало ли в вашей практике, что компания завязывала людей на собственные разработки, которые больше нигде не используются?
В связи с этим мне вот что подумалось: а ведь внутренний фреймворк X от компании "Рога и Ко" -- это же совсем не проблема для больших компаний. Ну, типа никого же из тех, кто стремится попасть в Google, Facebook или Яндекс не волнует то, что там придется работать с внутренними разработками компаний, которые нигде больше не используются (за исключением случаев, когда крупная компания выложила что-то в OpenSource).
Это для маленьких и средних компаний использование какой-то собственной внутренней технологии может быть проблемой: на рынке готовых специалистов, знакомых с этой технологией нет, имеющиеся на рынке кадры могут не захотеть идти на эту технологию (потому что потом этот опыт не пригодится), а если захотят, то попросят большую зарплату. Да и потом такие уникальные сотрудники будут неким "элементом неустойчивости" -- стоит паре-тройке ключевых разработчиков уйти, и "Рога и Ко" могут оказаться в весьма тяжелом положении, ведь продукт, который постоянно используется, нуждается в постоянном сопровождении (иногда больше, иногда меньше, но все-таки без присмотра не оставишь). Сопровождать нужно, а некому. И нет толпы страждущих соискателей, как на пороге Google или Яндекса.
Вот такая вот мысль. Внезапно, что называется.
И одно из следствий. Маленьким компаниям, если они используют собственные разработки, на рынке труда придется вести себя не так, как могут позволить себе крупные.
Это, в принципе, и так понятно. Но одно дело, когда компания ищет разработчиков со знанием каких-то общепризнанных инструментов (вроде Qt для C++). И совсем другое, когда у компаний какой-то свой условный userver, про который никто снаружи "Рога и Ко" даже и не знает.
6 комментариев:
Не то чтобы у меня была какая-то статистика, но по моим собственным ощущениям внутренние фреймвоки уходят в прошлое и по понятной причине, а именно, людей учат использовать готовое, а не писать своё.
Станислав, я бы сказал что тут два равноценных фактора: с одной стороны, растёт тренд на использование готового решения. А с другой стороны, эти "готовые решения" тоже стали куда более готовыми, и их интеграция вызывает в разы меньше головной боли. Да, сами решения стали сложнее, но если выводить параметр "количество боли на интегрируемую фичу", то жить явно стало проще и веселей.
Вспомним, как раньше надо было танцевать с компиляторами, бинарными форматами артефактов, переменными окружения, сигнатурами вызовов. И всё это - в рамках одной-единственной архитектуры!
А сейчас - хочешь ARM, хочешь Wintel, разрядность/endians/etc на выбор, а если есть какой пакетный менеджер, так вообще одна строчка, и готова интеграция. Гуманные контракты и сигнатуры, щедро сдобренные документацией... Если кажется, что это фантастика и на самом деле всё плохо - прошу пожаловать в Symbian OS или FoxPro :)
@Stanislav Mischenko
Ваши слова заставили меня задуматься. Фреймворки же можно разделить на общего назначения (типа Qt для C++ или Spring для Java) и специализированные. С фреймворками общего назначения все понятно. За то время, что я сам в программизме, для многих вещей разработка своих велосипедов (для тех же GUI) сменилась использованием готовых решений. Огромную роль здесь еще сыграло и движение OpenSource, мода на которое еще не прошла (да и вообще OpenSource никуда просто так не исчезнет).
А вот по поводу специализированных фреймворков... Тут вот какая мысль меня посетила: фреймворк -- это же инструмент для существенного упрощения какой-то задачи. А такое упрощение возможно для часто повторяющихся и более-менее однотипных задач. Т.е. когда регулярно приходится делать очень похожие виды работ.
И, наверное, далеко не у всех компаний есть потребность решать такого рода однотипные задачи. Как следствие и специализированных внутренних фреймворков так же должно быть немного.
Не особо владею ситуацией именно с фреймворками для программирования (хотя, на первый взгляд, там ровно такая же ситуация). Сейчас очень сильно развито опенсорс-движение. И уже готовых решений есть почти на все случаи жизни. И, получается, самый здоровый подход - не изобретать велосипед и использовать уже существующие и распространенные решения с известными проблемами и более-менее понятными решениями этих проблем.
Основная причина, почему крупные компании используют самописные решения - опенсорс "не вывозит". Неоднократно слышал эту историю именно от представителей этих самых крупных компаний. Часть из них, после изобретения своего велосипеда, отдает его в опенсорс. Часть - не отдает.
Так или иначе, всегда проще стартовать с опенсорса. Потом, при росте и масштабировании, когда будут уже настоящие проблемы - будут и альтернативы. Тем более, что для написания чего-то своего с нуля нужны действительно веские причины. Когда и все воркараунды не помогают уже, и опенсорс критично не умеет и не вывозит. Если честно, то в небольшой компании я такого не представляю.
Никогда, кстати, не понимал, почему люди боятся браться за какую-то специфическую область. Есть, конечно, гипотетические проблемы с наймом в будущем. Но есть прямо сейчас и другая тенденция - вот ты такой красивый, знаешь много чего из опенсорса, поверхностно потрогал еще больше этого самого опенсорса. И тебе все равно трудно найти работу. Потому что ищут с совпадением по технологиям и навыкам, близким к 100%. А учитывая размер этого зоопарка - такое совпадение найти ну прямо очень не просто. Еще есть отличный вариант "а нам надо 100% посещение офиса" - в 2023-м году, когда весь мир работает с распределенными командами. Я лично не могу понять, как можно взять не лучшего кандидата, а того, кто будет ходить в офис. Ну и комбо - два фактора сразу и обязательно. :)
@rkirilenko
Фреймворки (условно) можно разделить на две категории.
Первая -- это какие-то универсальные фреймворки, решающие некоторую общую задачу. Типа GUI фреймворка для рисования окошек, HTTP-сервера для приема HTTP-запросов, фреймворк для парсинга посредством PEG-грамматик или каких-нибудь LR(1) грамматик и т.д., фреймворк для работы с РСУБД (с поддержкой ORM), криптография и т.д., и т.п.
Эта первая категория уже плотно закрыта OpenSource.
Если какая-то компания все еще сидит на каком-то собственном фреймворке подобного рода, то это либо легаси, который проще поддерживать, чем выбросить (скажем, какой серьезный САПР написан на собственной GUI библиотеке), либо заточен под такие специфические условия, которые в открытых аналогах не найти.
А вот вторая категория -- это прикладные фреймворки, заточенные под какую-то специфическую задачу. По типу того, как в Интервэйле в свое время сделали инструмент для поддержки платежных транзакций или каркас для написания систем мобильного банкинга.
Вот фреймворки из второй категории вряд ли широко представлены в OpenSource. При этом грамотно сделанный фреймворк такого рода способен (по моему мнению) дать компании, которая его использует, существенное преимущество. Особенно если эта компания имеет какое-то полуготовое решение, которое нужно сильно кастомизировать под конкретного заказчика. Ну вот что-то по типу систем мобильного банка, которые Интервэйл делал.
ИМХО, такого рода фреймворки очень полезны, особенно небольшим компаниям на конкурентном рынке, у которых нет возможности решать проблемы тупо за счет количества рабочей силы.
@eao197,
От тут крыть особо нечем. :) Разве что добавить, что в реальной жизни перед компанией (особенно, если это стартап) довольно часто встает не проблема поддержки собственного фреймворка, а проблема продать решение на базе этого фреймворка. И если компания дожила до проблемы "поддержать" и "уникальных специалистов" - то честь ей и хвала.
Отправить комментарий