Как ваша организация обрабатывает общие компоненты?

Question

Общий компонент - это библиотека или какой-либо другой фрагмент кода, который создается и поддерживается одной группой и используется многими группами.

Некоторые проблемы, с которыми мы сталкиваемся, заключаются в следующем:

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

Как ваша организация обрабатывает общие компоненты?

Идеи, которые у меня есть:

• Относитесь к компоненту как к проекту с открытым исходным кодом и требуйте от команд отправки исправлений.
• Полностью запретить пользовательские модификации кода.
• ...

Answer 1

То, с чем вы здесь столкнулись, может быть проблемой человеческого фактора, а не технического характера.На самом деле это может быть в первую очередь проблемой обучения (в сочетании с типичным не изобретенным здесь синдромом).

Поработав в крупных компаниях, я понимаю, что новому человеку сложно разобраться во всех ресурсах (т.е.библиотеки общего кода), доступные ему, не говоря уже о том, как и когда их правильно использовать.

Когда вы нанимаете нового сотрудника, проходит ли он / она формальное обучение в вашей общей библиотеке компонентов?

Тогда возникает проблема с тем, за что людей вознаграждают.Вознаграждают ли менеджеры во время проверки сотрудников за использование общих компонентов, их улучшение и отправку улучшений обратно в библиотеку?Или менеджеры просто заботятся о своих собственных проектах.

Что касается вашей группы, которая ведет общую библиотеку, какую форму или рекомендации они предоставляют людям, которые находят время предложить или представить улучшения?Публикуются ли они в информационном бюллетене компании?Получите денежный бонус?Разместить их фотографию на доске объявлений bulliten?

Помните, что люди вряд ли станут делать что-то для компании, за что они не получат признания или вознаграждения.

Answer 2

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

Естественно, это работает лучше для некоторых типов компонентов (пример:недавно мы создали сервис создания PDF), чем другие (вероятно, излишество для утилиты для работы со строками).

Answer 3

Единственный успешный компонент, который я видел здесь, распространяется в скомпилированной версии (*.dll).Пользователи сообщают об ошибках и запрашивают функции непосредственно у команды владельцев, и те внедряют их самостоятельно.Существует API для написания ваших собственных плагинов для материалов, которые с наибольшей вероятностью изменятся, поэтому люди могут расширить функциональность во многих случаях.

Всегда есть компромисс, чтобы

• убедите людей использовать ваш компонент
• в то же время поддерживайте разумный уровень качества

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

Answer 4

Хороший способ - ввести периодические проверки кода.Во время них, если вы обнаружите, что колесо изобретено заново, вы можете воспользоваться возможностью либо рассказать разработчикам об использовании общего компонента, либо о том, почему они почувствовали необходимость изобрести его заново и согласовать свои рассуждения с исходным кодом.Таким образом, предъявляются требования к каждому, и компоненты улучшаются для всех.

Answer 5

Относитесь к ним так же, как к сторонним библиотекам.Я бы даже не позволил другим командам увидеть источник - это может привести к большой трате времени на критику и упреки в спину.

Answer 6

Насколько велика организация?Я видел, как этот материал очень хорошо обрабатывается в небольшой организации (всего несколько десятков программистов), где известно, что один или два человека владеют каждым компонентом и реагируют на запросы функций.

Проще отправиться в чей-нибудь офис (или отправить ему электронное письмо), объяснить, что вам нужно, и получить один из:

• ожидаемый способ сделать то, что вы хотите,
• согласие добавить требуемую функцию (или поручить миньону сделать это),
• разрешение на реализацию требуемой функции в общем компоненте,

Чем просто приступить к написанию обходных путей, запуску форка или написанию эквивалентного нового компонента.Если ваши программисты умны, они будут делать то, что, по их мнению, проще всего.Хитрость заключается в том, чтобы убедиться, что это то, что нужно.

Помимо действительно простых вещей, таких как связанные списки, переосмысления колес происходило не так уж много.Существовали, очень редко, частные форки для определенных продуктов, чаще всего для уменьшения размера кода путем его разделения.Но обычным способом сделать это было изменить исходный компонент, чтобы иметь больше возможностей сборки.