Важно ли владение отдельным кодом? [закрыто]

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

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

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

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

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

Но, предлагая это своим коллегам, я получил массу откатов, конечно, гораздо больше, чем я ожидал.

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

Я считаю, что владение командой намного выгоднее в долгосрочной перспективе.

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

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

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

Тот факт, что у вас нет индивидуального владения разделами кода, поскольку вы его написали, не означает, что у вас не останется аспектов «гордости за свое творение» и т. Д. Я не верю, что владение коллективом сильно повлияет уменьшить любые личные чувства собственности написанного кода.

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

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

Я работал в командной среде, потому что люди не чувствовали чувства причастности к тому, что они написали, они не были вынуждены писать отличный код, а просто средний код.

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

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

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

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

Я не знаю, что владение отдельным кодом - хорошая идея. По крайней мере, в том смысле, что люди могут сказать: «Это мой код, и я сделаю с ним то, что хочу». Может быть, лучше сказать, что у вас должно быть индивидуальное управление кодом : код должен принадлежать команде, но есть один конкретный человек, которому команда делегирует ответственность и полномочия над ним.

Причиной этого является то, что если это ответственность каждого, то это не ответственность каждого.

Я бы поддержал владение командой над личностью по следующим причинам:

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

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

Я имею в виду, что отношение должно быть таково, что в команде есть ошибка, и никто не должен говорить, что «о, только X может коснуться этого кода, так что это не моя проблема». Если вы являетесь частью команды, вы также должны, если можете, исправлять ошибки во всей кодовой базе и делать это правильно. Человек Х может быть лучшим выбором для этого, но любой должен ожидать, что он должен был это сделать. Это , естественно , требует код , который будет записан таким образом , что позволяет и приглашает членов команды к работе с ним. Наличие грубого кода будет запрещать это, поэтому стремитесь к кристально чистому и простому коду, поскольку это позволяет большинству разработчиков работать с ним. Вы можете хотеть пойти с рецензированием, чтобы держать это таким образом.

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

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

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

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

Я думаю, что вам нужны оба, потому что между обоими подходами существует напряженность.

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

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

Я думаю, что коллективное владение кодом несравненно лучше, чем индивидуальное владение кодом.

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

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

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

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

Я не думаю, что владение командным кодом так же важно, как наличие нескольких участников, понимающих основную архитектуру преобладающих подсистем.

Например, в нашей команде есть несколько парней, которые делают административные веб-страницы для наших серверных продуктов. Мы создали собственный серверный скрипт-движок, чтобы мы могли вызывать на сервере функции C прямо из наших java-скриптов или html. Я думаю, что более важно, чтобы наши «веб-парни» понимали, как использовать этот движок, а не являлись совладельцами приложений веб-страниц друг друга.

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

Думайте больше ответственности и меньше собственности. В конце концов, тот, кто пишет чеки, в любом случае является настоящим владельцем.

Джим, я с тобой на все 100%. Я нахожусь в центре точно такой же битвы на моем рабочем месте - вот почему я наткнулся на ваш вопрос.

Я вижу это так: «когда всем это принадлежит, никто не владеет».

Для меня нет более важного фактора качества кода, чем владение и ответственность.

Пример из реальной жизни хорошо иллюстрирует это. что бы вы позаботились лучше: ваш частный газон или общественный парк? Довольно очевидно.

Между прочим, это не обязательно нужно менять на «командную гибкость». Это просто означает, что когда человек чем-то владеет, он СОБСТВЕННЫЙ - и хотя бы на день.

Для меня это зависит от динамики вашей команды.

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

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

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

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

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

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