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

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Он чувствует себя хорошо, когда:

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

Он чувствует себя плохо, когда:

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

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

Answer 7

На нижней стороне: -

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

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

Answer 8

Вы должны это прочитать. Владение кодом не так хорошо, как вы думаете.

https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.ldlpppzh2