* Владелец кода * Система: это эффективный способ? [закрыто]

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

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

Как вы думаете, подход будет хорошо работать для системы среднего размера (разработка сайта социальной сети)?

Как и многие из этих вопросов, я думаю, что ответ:

По-разному

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

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

• Программист А: имеет глубокое понимание
• Программист Б: нет

Допустим, программист А получает 1 единицу работы в день. За 4 недели 5 рабочих дней он может выполнить 20 единиц работы.

Таким образом, программист B, начиная с 0,2 единицы работы в день и заканчивая 0,96 единицами работы в свой 20-й день (в 21-й день они так же хороши, как и программист A), выполнит 11,6 единиц работы за один и тот же день. 20-дневный период. В течение этого месяца программист B достиг 58% эффективности по сравнению с программистом A. Однако теперь у вас есть другой программист, который знает этот модуль так же, как и первый.

Конечно, в приличном проекте у вас может быть ... 50 модулей? Таким образом, знакомство со всеми из них занимает около 4 лет, а это означает, что обучающий программист в среднем работает с 58% -ной эффективностью по сравнению с программистом А ... ммм.

Итак, рассмотрим такой сценарий: одни и те же программисты, один и тот же проект (A знает все, а B ничего не знает). Допустим, в году 250 рабочих дней. Предположим, что рабочая нагрузка случайным образом распределена по 50 модулям. Если мы разделим обоих программистов равномерно, A и B получат по 5 рабочих дней на каждый модуль. A может выполнять 5 единиц работы над каждым модулем, но B, согласно моей маленькой симуляции Excel, получает только 1,4 единицы работы над каждым модулем. Итого (A + B) составляет 6,4 единицы работы на модуль. Это потому, что Б проводит большую часть своего времени без каких-либо навыков с модулем, над которым они работают.

В этой ситуации более оптимально, чтобы B фокусировался на меньшем подмножестве модулей. Если B фокусируется только на 25 модулях, они получают 10 дней на каждый, что составляет 3,8 единицы работы на каждом. Программист A мог бы затем потратить 7 дней каждый на 25 модулей, над которыми B не работает, и 3 дня каждый работал на тех же, что и B. Общая производительность колеблется от 6,8 до 7 единиц на модуль, в среднем 6,9, и это значительно выше. чем 6,4 единиц на модуль, мы сделали, когда A и B распределяли работу равномерно.

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

Тренировка

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

Оптимальным решением

Вот почему я думаю, что оптимальное решение должно основываться на таких вопросах, как:

• Насколько велика ваша команда? Имеет ли смысл проводить кросс-тренинг по каждой части, или если у нас есть команда из 10 человек, можем ли мы просто убедиться, что каждый модуль известен по крайней мере для 3 человек? (С 10 программистами и 50 модулями каждый программист должен знать 15 модулей, чтобы получить 3-кратное покрытие.)
• Как меняется текучесть кадров? Если вы переворачиваете сотрудников в среднем каждые 3 года, и для того, чтобы действительно знать каждый уголок системы, требуется больше времени, то они не будут достаточно долго, чтобы обучение окупалось.
• Вы действительно нуждаетесь в эксперте, чтобы диагностировать проблему? Многие люди используют оправдание «что если этот человек уходит в отпуск», но мне неоднократно звонили, чтобы диагностировать проблему в системе, с которой у меня не было опыта. Это может быть правдой, что опытный человек может найти это намного быстрее, но это не значит, что вы не можете жить без них в течение недели или двух. Немногие программные системы настолько критичны, что проблема должна быть диагностирована за 1 час, а не за 5 часов, иначе мир закончится. Вы должны взвесить эти риски.

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

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

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

Это зависит от предметной области проблемы.

Если это общие вещи (например, простые действия CRUD и т. Д.), То я согласен с Томом Сквайром (любой должен иметь возможность работать с ним и редактировать его).

Однако ...

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

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

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

Это сводится к одному: дисциплина . Сколько одиноких программистов вы знаете, кто действительно дисциплинирован в своем стиле кодирования? Когда вы не программируете с дисциплиной, вы берете ярлыки (потому что вы «исправите это позже»), и удобство сопровождения кода ухудшается. Мы все знаем, что «позже» никогда не наступит. Факт : Сложнее использовать ярлыки, когда вы сразу же подотчетны своим коллегам по команде. Почему? Потому что ваши решения будут поставлены под сомнение, и всегда будет сложнее оправдать ярлыки. Конечный результат? Вы создаете более качественный, более понятный код, который также является более надежным.

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

Компромиссом будет иметь как минимум 2 владельца для каждой области кода. Затем кто-то может уйти в отпуск, устроиться на новую работу или уйти в отставку, и еще есть кто-то, кто знает код (и может обучить нового второго человека). Не всем нужно изучать все, что немного эффективнее.

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

Да, это немного более эффективно, в краткосрочной перспективе. И там заканчивается польза. Это даже близко не перевешивает стоимость.

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

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

Это не значит, что в команде из 50 разработчиков каждый должен знать весь код, но команда из 5-7 человек должна иметь достаточно большой модуль, чтобы эти люди работали. Никто не должен владеть чем-либо.

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

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

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

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

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

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

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

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

Причины, по которым это плохо:

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

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

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

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

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

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

Посмотреть номер грузовика ака Bus Factor

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

«Попасть в автобус» может принимать разные формы. Это может быть человек, который берет новую работу, рожает ребенка, меняет свой образ жизни или жизненный статус, или буквально попадает в автобус: эффект будет тот же ...

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

Недостаток серьезен; «номер грузовика» вашей команды в значительной степени становится 1.

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

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

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

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

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

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

Лучшие программисты, вероятно, в конечном итоге исправят множество чужого кода независимо от того, как вы его назначаете.