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

Question

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

Некоторые проблемы у нас:

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

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

У меня есть идеи:

• Рассматривайте компонент как проект с открытым исходным кодом и требуйте, чтобы команды отправляли исправления.
• Полностью запретить пользовательские изменения кода.
• ...

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Всегда есть компромисс к

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

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