Я работаю в компании, которая разрабатывает веб-приложения для различных банков и некоторых небольших интернет-магазинов. У нас работает около 20 разработчиков, и в каждый момент времени у нас 4-5 проектов. Наши команды разработчиков мало общаются, и многие одни и те же проблемы решаются разными способами (от хорошего к плохому).
Мне было интересно, будет ли хорошей идеей для компании иметь команду программистов, которые будут заниматься исследованиями существующих структур и постоянно улучшать общую библиотеку функций и общую структуру для гораздо более быстрого и эффективного построения текущих и будущих проектов.
Насколько большой должна быть такая команда?
Также у него должны быть постоянные члены, которые обучают других, или это должно вращать людей?
Обновление: я думал о совместном проекте, над которым люди могут работать ради удовольствия, который может вызвать некоторый интерес. Кажется, что когда люди испытывают трудности с работой, решения, которые они предлагают, не самые лучшие.
источник
Ответы:
Важным моментом является то, что невозможно разработать хорошую основу в полной изоляции. Хорошие фреймворки органически растут : когда программист замечает, что ему нужна определенная функциональность, он добавляет его в фреймворк, и поэтому фреймворк постепенно растет - в отличие от разработки «идеальной фреймворк» заранее, которая никогда не работает, потому что архитектор не может знать обо всех возможных вариантах использования.
Конечно, у органически растущей основы есть и обратная сторона: ее внутренняя целостность может быть не слишком хорошей, и она превращается в спагетти. Если ваша команда поддерживает хорошую внутреннюю коммуникацию, вы можете объединить лучшее из двух миров: отдельная команда архитекторов, поддерживающая целостность инфраструктуры, но построенная для реальных потребностей конечных пользователей (разработчиков).
источник
Моих чувств нет.
Я подозреваю, что если вы это сделаете, вы обнаружите, что вместо того, чтобы иметь отдельные команды, производящие библиотеки, которые никто не использовал за пределами этой команды, у вас была бы специализированная команда, производящая библиотеки, которые никто не использовал за пределами команды (и делал это так). при значительных дополнительных затратах).
Есть разные проблемы с той командой, которую вы описываете, но для меня главное в том, что она не решает проблему, которая у вас есть на самом деле.
Проблема у вас не в том, кто создает библиотеки (судя по тому, что у вас уже есть много решений этих проблем, так как еще одна может помочь?), Это в том, что команды не разговаривают и не взаимодействуют.
Существуют веские причины, по которым команды не используют повторно код друг друга (например, проблемы, хотя они внешне схожи, незначительно отличаются, или что время проекта просто не учитывает дополнительную зависимость разработки чего-то вместе), но вам необходимо посмотрите, как вы можете заставить их взаимодействовать, когда это возможно.
Я бы предложил:
Я подозреваю, что команда библиотек будет наверху без пользы.
С точки зрения того, что это обычный проект, над которым разработчики работают ради удовольствия - ни одна компания не должна полагаться на программистов, работающих над вещами в свое время. Это просто неоплачиваемая сверхурочная работа, и в любом случае она не заслуживает доверия, так как, вероятно, будут большие периоды, когда никто не хочет работать над вещами.
Если вы говорите, что люди будут работать в компании между проектами, то, возможно, это сработает, но я все еще не думаю, что это настоящая проблема. Вам все еще нужно решить, как заставить людей использовать библиотеки. Как я уже сказал, у вас уже есть решения этих проблем, которые разрабатываются для каждого проекта, ваша проблема заключается в том, почему они не являются общими.
источник
Это работа архитектора .
Основные обязанности архитектора программного обеспечения включают в себя:
Узнайте больше о: - Архитектор программного обеспечения - Архитектор решений - Архитектор предприятия .
источник
Поговорка « Ешь свою собачью еду » решает эту проблему. Если ваш лучший крутой рок-звездный кодер рождает библиотеку, которую он никогда не использовал на практике, как он может сказать, что она хорошая?
Основными причинами развития функциональности в рамках являются
1. Это полезно для разработчика
2. Есть несколько случаев, когда это было полезно
3. Это может быть полезно для других
Когда вы нажмете 2, функциональность уже есть, как вы можете передать это кому-то еще?
источник
Я немного опоздал на игру, но я чувствовал, что никто не обращался к этому:
Ваши отдельные команды, которые решают различные проблемы по-разному, определенно выиграют от общей функциональности, и есть множество способов получить это таким образом, чтобы не посвятить ни одной команде его разработку, но я видел много мест, которые делают.
В большинстве случаев я вижу, что это называется «ядром» вашей продуктовой линейки, и иногда есть команда, отвечающая за его поддержку, во главе с (как предположил Амир) архитектором. Как правило, именно таким образом вы сможете найти способы использовать или создать структуру, которая соответствует самым строгим стандартам, установленным в вашей организации, но обеспечивает только самые простые функции, которые могут или не могут быть расширены в полноценных приложениях. что ваши отдельные продуктовые команды предлагают. Это позволяет вам получить выгоду от "собачьей поддержки" вашего основного кода, внедряя его в каждом отдельном месте, где вы его используете, а затем также переходя к разным продуктам, которые могут иметь совершенно разные реализации. Это позволяет всем вашим командам вносить свой вклад в основные библиотеки, но не загружать их функциональностью, которая нужна только им.
источник
Я думаю, что это НЕ ХОРОШАЯ ИДЕЯ , потому что для того, чтобы библиотеки были полезными, они должны помогать вам решать реальные проектные проблемы, а вы узнаете их только ... ну, работая в реальных проектах.
В противном случае вы можете закончить «теоретически» очень хорошей библиотекой!
источник
В одной компании, в которой я работал, действительно было похожее, похоже, это не сработало. Люди из внутренней команды придумывали аккуратную идею и создавали прототип, который в основном работал, затем он перешел через стену, и мы должны были превратить его в продукт.
Я ожидаю, что это произойдет в том случае, если группа инструментов запустит собственную маленькую программу, производящую функции, которые на самом деле не так уж полезны, но которые загромождают API и используются достаточно, чтобы их было нелегко удален. Они не будут документировать адекватно.
Если группа инструментов находилась в достаточной степени под системным архитектором, который был в постоянном контакте с людьми, фактически использующими инструменты, это могло бы сработать. Если группа инструментов часто вращалась (что мешало бы проводить много внешних исследований), это могло бы работать. Тем не менее, я бы боялся потерять контакт с людьми, выполняющими оплачиваемую работу.
источник
Сколько времени вы собираетесь потратить на обсуждение того, будет ли использование фреймворка полезным во всех случаях? Задерживается ли проект из-за ожидания обновления инфраструктуры? В какой-то момент использование структуры должно потребоваться, чтобы оправдать ее существование.
источник