Когда используется совместное использование кода?

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

Как можно использовать совместное использование кода, чтобы избежать ловушек и по-прежнему пользоваться преимуществами? Может ли слишком много поваров испортить бульон?

ОТВЕТЫ

Ответ 1

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

  • Многие мозги лучше одного. Кодеры часто обнаруживают ошибки или задают странности в коде друг друга, тем самым улучшая общую надежность кода. Подумайте об этом как о непрерывном просмотре одноранговых кодов.
  • Снижает риск потери критических/ценных знаний, если разработчик попал в автобус или уходит в отставку.
  • Если разработчик находится в отпуске в течение недели, вам не нужно ждать неделю, чтобы ошибка была исправлена. Или вам не нужно объяснять сердитому кодеру, почему вы испортили "свой" код, пока его спина была повернута.
  • Распространяет знания о продуктах в команде. Парень, звонящий в библиотеку, сделает меньше ошибок, если он действительно работает над кодом в библиотеке и хорошо это понимает. Парень, называющий черный ящик, о котором он ничего не знает, займет больше времени и сделает больше ошибок.
  • Распространяет знания кодирования в команде. Все учатся трюкам и узорам от других (даже лучшие программисты иногда могут узнать что-то, чего они не знали от младшего).
  • Выражает стиль кодирования - люди имеют эго и склонны к началу религиозных войн, но если они работают на одной и той же кодовой базе, а менеджер применяет стандарты кодирования и вмешивается, чтобы "бороться" над стилем под контролем, через некоторое время команда начинает работать как согласованная группа, качество кода увеличивается, и поединки прекращаются.
  • Помогает каждому почувствовать, что они являются частью команды, без свободных пушек. Нет никаких примадонн, и каждый чувствует, что они равны, и их вклад ценится и стоит - это приводит к лучшей самооценке. Кроме того, когда команда достигает цели, каждый чувствует себя хорошо, и когда команда терпит неудачу, никто не чувствует полного веса индивидуальной ответственности.
  • Программисты больше общаются, что дает вам лучший командный дух и большую готовность помогать другим.
  • Это улучшает качество кода, потому что программисты знают, что другие будут читать их код, поэтому они, как правило, оставляют все это в гораздо более аккуратном состоянии, чтобы избежать embarrasment. Они также знают, что они должны сделать свой код легким для понимания другими, поэтому они начинают писать код для других, чтобы поддерживать, а не писать код для себя.

Возможные недостатки могут включать:

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

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

Ответ 2

В нижней части: -

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

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

Ответ 3

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

Во-первых, определите стандарты и попросите команду договориться о них (управление нарушает связи).

Во-вторых, используйте автоматизированные инструменты (предпочтительно с помощью IDE-перехватчиков) для обработки форматирования кода.

В-третьих, используйте инструменты автоматического статического анализа для проверки соответствия. Они могут выходить за рамки проверки форматирования и проверки показателей сложности кода, соглашений об именах, лучших практик и т.д. Лучшие из них можно настроить в соответствии с правилами вашей команды. Если возможно, найдите те, которые позволяют подавлять ненадлежащие предупреждения через метаданные (например, атрибуты). Большинство правил имеют исключения, и вы хотите скрыть "шум" ложных срабатываний.

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

Ответ 4

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

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

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

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

  • Проект объединяет две или более сложные подсистемы и эксперименты в каждой подсистеме, распределяется неравномерно среди членов команды.

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

Ответ 5

Я думаю, что исправления:

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

Вы также должны оценить себя. Существует естественная тенденция полагать, что действия, которые не согласуются, являются иррациональными. Довольно часто просто не хватает опыта, который мотивирует другого, и иногда приходится преодолевать свои собственные инвестиции в эго.

Ответ 6

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

Ответ 7

У меня был хороший и плохой опыт использования совместного использования кода.

Хорошо, когда:

  •  
  • Код используется несколькими людьми, такими как утилиты и интерфейсы.  
  • Программисты имеют сопоставимую квалификацию и уровень знаний.  
  • Все владельцы требуют что-то из общего кода.

Это плохо, когда:

  •  
  • Код нестабилен (при прототипировании или рефакторинге). Владелец должен сначала стабилизировать его.  
  • Насилие как политика. Команда будет имитировать его и ненавидеть исполнителя.  
  • Код плохо написан. Он должен быть исправлен, а не разделен.

В общем, совместное владение всем не является хорошей идеей. Лучше делиться, когда он чувствует себя естественно, и сохранить код для себя, когда он этого не делает.