В нашей команде появился новый разработчик. В нашей компании используется гибкая методология . Но у разработчика есть другой опыт: он считает, что определенные части кода должны быть назначены конкретным разработчикам. Таким образом, если бы один разработчик создал программную процедуру или модуль, считалось бы нормальным, что все изменения процедуры / модуля будут выполняться только им.
С другой стороны, предположительно, благодаря предлагаемому подходу мы экономим общее время разработки, поскольку каждый разработчик хорошо знает свою часть кода и быстро исправляет ошибки. Недостатком является то, что разработчики не знают систему полностью.
Как вы думаете, подход будет хорошо работать для системы среднего размера (разработка сайта социальной сети)?
источник
Ответы:
Как и многие из этих вопросов, я думаю, что ответ:
По-разному
Есть основания полагать, что принятие позиции, согласно которой каждый программист должен знать каждую строку кода, ошибочно.
Если мы предположим на мгновение, что кто-то с глубоким пониманием фрагмента кода внесет изменения в 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. Обучение кого-то - трудоемкое занятие.
Оптимальным решением
Вот почему я думаю, что оптимальное решение должно основываться на таких вопросах, как:
Вот почему я думаю, что «это зависит». Вы не хотите разделять 20 модулей между двумя программистами прямо посередине (по 10 каждый), потому что тогда у вас нет гибкости, но вы также не хотите перекрестно обучать 10 программистов на всех 50 модулях, потому что вы теряете много эффективность, и вам не нужно так много избыточности.
источник
Это ужасная идея . Это может быть быстрее в краткосрочной перспективе, но это поощряет плохо документированный трудный для понимания код, поскольку только кодер, написавший его, отвечает за его поддержку. Когда кто-то покидает компанию или уходит в отпуск, весь план облажается. Это также делает очень трудным распределение рабочих нагрузок; что происходит, когда две срочные ошибки появляются с кодом, которым владеет один кодер?
Вы должны кодировать как команду . Людям, естественно, будут распределены задачи и они будут сосредоточены на определенных областях, но следует поощрять совместное использование рабочей нагрузки и совместную работу, а не препятствовать этому.
источник
Это зависит от предметной области проблемы.
Если это общие вещи (например, простые действия CRUD и т. Д.), То я согласен с Томом Сквайром (любой должен иметь возможность работать с ним и редактировать его).
Однако ...
Если рассматриваемое решение требует экспертных знаний в данной области (много времени было потрачено либо в прошлом, либо перед внедрением необходимо провести много исследований, как это было бы указано в требовании к работе в качестве специальных знаний, не все на проекте), то владелец должен обязательно быть назначен на ту часть кода. Сказав это, каждый должен иметь возможность вносить изменения в него по мере необходимости, но они должны всегда проверяться лицом, владеющим этой областью проекта.
Вы не хотите, чтобы вся ваша команда (или несколько человек в команде) изучали и изучали один и тот же предмет (потраченные впустую циклы). Назначьте владельца, но попросите его документировать свои знания и дизайн и, возможно, попросить их провести неофициальные (или не очень важные) тренинги по технологии.
источник
Это ужасная идея . Я работал в компании, которая использовала этот подход, и это в значительной степени рецепт кучи технического долга . Суть в том, что две головы почти всегда лучше, чем одна. Почему? Потому что, если вы не идиот, вы знаете, что вы не идеальный программист, и вы не поймете каждую ошибку, которую делаете. Вот почему вам нужна команда - больше глаз смотрит на один и тот же код с разных точек зрения.
Это сводится к одному: дисциплина . Сколько одиноких программистов вы знаете, кто действительно дисциплинирован в своем стиле кодирования? Когда вы не программируете с дисциплиной, вы берете ярлыки (потому что вы «исправите это позже»), и удобство сопровождения кода ухудшается. Мы все знаем, что «позже» никогда не наступит. Факт : Сложнее использовать ярлыки, когда вы сразу же подотчетны своим коллегам по команде. Почему? Потому что ваши решения будут поставлены под сомнение, и всегда будет сложнее оправдать ярлыки. Конечный результат? Вы создаете более качественный, более понятный код, который также является более надежным.
источник
Преимущество в том, что не всем нужно исследовать и понимать все. Недостатком является то, что это делает каждого человека необходимым для его собственной области кода, и никто больше не знает, как его поддерживать.
Компромиссом будет иметь как минимум 2 владельца для каждой области кода. Затем кто-то может уйти в отпуск, устроиться на новую работу или уйти в отставку, и еще есть кто-то, кто знает код (и может обучить нового второго человека). Не всем нужно изучать все, что немного эффективнее.
Не надо, чтобы 2 (или 3) человека все время работали вместе. Выключайте пары для разных областей, чтобы знания также передавались непреднамеренно при работе с другим человеком в соответствующей программной области.
источник
Да, это немного более эффективно, в краткосрочной перспективе. И там заканчивается польза. Это даже близко не перевешивает стоимость.
Что происходит, когда он в отпуске, или неожиданно болеет, или уезжает, или попадает в автобус из пословиц? Что происходит, когда вы хотите использовать ресурсы, чтобы получить одну работу быстрее, чем другую? Насколько эффективными могут быть проверки кода? Как менеджер, особенно тот, кто не находится в базе кода, может знать, работает ли разработчик усердно или натягивает шерсть на глаза? Кто заметит, если технический долг начнет увеличиваться?
По моему опыту, люди, которые любят работать таким образом, в лучшем случае охотники за славой, а в худшем - ленивые. Им нравится быть единственным человеком, к которому вы можете обратиться с данной проблемой, и им нравится, когда их код остается закрытым. И они часто любят быстро кодировать, не обращая внимания на удобочитаемость.
Это не значит, что в команде из 50 разработчиков каждый должен знать весь код, но команда из 5-7 человек должна иметь достаточно большой модуль, чтобы эти люди работали. Никто не должен владеть чем-либо.
источник
Есть по крайней мере три вопроса, на которые указывают другие ответы; но я хотел бы попробовать и относиться к ним обоим вместе. Два вопроса:
Когда тема является чисто экспертной, успех проекта может зависеть от высокого уровня знаний о предметной области; но это не зависит от знания конкретного эксперта в этой области. Эксперты, хотя, возможно, редкие и ценные, по-прежнему взаимозаменяемы; один опытный налоговый бухгалтер так же полезен для проекта программного обеспечения для налогового планирования, как и другой, с точки зрения знаний в своей области. Вопрос становится одним из того, насколько хорошо эксперт может передать свои знания в проект.
Когда тема является чисто лидерской, успех проекта зависит главным образом от последовательности и понимания решений, принятых руководителем проекта; хотя мы склонны отдавать предпочтение руководителям проектов, которые имеют опыт работы в данной области или зарекомендовали себя в качестве руководителей проектов, это иногда является второстепенным по отношению к роли. «Лидер» может меняться изо дня в день, если принятые решения являются последовательными от одного случая к другому, и каждая команда быстро выполняет каждое решение. Если это работает правильно; многие решения не должны быть «приняты» руководителем проекта, потому что команда уже понимает, какие решения будут приняты.
Я не думаю, что вопрос на самом деле касался кода без эго, но трудно говорить о владении кодом, не обсуждая также, насколько важна эта проблема. Поддержание проекта, вероятно, является большей частью цикла разработки. Чтобы понять эту проблему, стоит задуматься над тем, что произойдет, если некоторые разработчики немедленно покинут ее. Что будет, если заменить всю команду ? Если проект подвергается сомнению, потому что он зависит от некоторых ключевых игроков, то вы рискуете потерпеть неудачу. Даже если вы никогда не потеряете ни одного члена команды, тот простой факт, что для продвижения проекта требуется один или несколько разработчиков, означает, что вы, возможно, не будете работать так же эффективно, как могли бы, если бы в этом участвовало больше разработчиков.
источник
Владение кодом имеет тенденцию предотвращать рефакторинг, создавать узкие места в разработке и вызывать проблемы с эго, когда в коде есть проблемы, с которыми необходимо разобраться.
Я рекомендую проконсультироваться с авторами кода перед его изменением, хотя код высокого стандарта должен быть достаточно хорошо задокументирован, проверен модульно, протестирован на интеграцию и протестирован на систему, чтобы сделать это избыточным, и все же не помешает получить другое мнение.
источник
Это плохо по многим причинам, я работал в магазине, где они пытались перейти от этого к чему-то более разумному, и это было ужасно.
Причины, по которым это плохо:
Самые большие из них - это кадровые проблемы и документация. Этот человек однажды уйдет, и мальчик будет на несколько недель сдвигать расписание влево.
Лучший подход состоит в том, чтобы каждый был знаком с каждой частью базы кода (или полдюжиной частей или около того, если она действительно большая и разнообразная) до такой степени, что они могут
Каждый человек имеет тенденцию знать немного больше о некоторых вещах, чем другие, поэтому для сложных задач два или три могут объединиться, или эксперт по фактам может взять на себя это. Я работал в группах, где это было так, и это сработало очень хорошо. Мало того, что не было ни одного из перечисленных минусов, штатное расписание было намного более предсказуемым, так как мы не охотились за экспертами.
Преимущество единоличного владения кодом заключается в том, что «владелец кода», вероятно, может делать вещи быстрее, чем другие, но это справедливо только в том случае, если каждый является «владельцем кода» в непересекающихся проектах. Другими словами, если люди вращаются вокруг, преимущество «единственного владельца кода» исчезает.
источник
Посмотреть номер грузовика ака Bus Factor
источник
Как и во многих вещах, это большая «зависимость». Если это строгое «никто не может работать с кодом», это, вероятно, граничит с плохим. Если это «владелец должен выполнить проверку кода перед тем, как принять изменение», это означает, что в среднем все хорошо, в зависимости от того, насколько готов владелец принять внешние изменения.
источник
Недостаток серьезен; «номер грузовика» вашей команды в значительной степени становится 1.
Чтобы проверить, «номер грузовика» определяется просто как «сколько членов команды, в худшем случае, может быть сбито грузовиком до того, как знания, необходимые для выполнения какой-либо важной задачи, будут потеряны для команды».
Естественно, и в некоторой степени следует поощрять, чтобы разработчики фокусировались на под-дисциплинах; если бы все должны были знать все, что связано с проектом, ничего бы не было сделано, потому что все узнали бы, что все остальные сделали, почему он работает и как его можно изменить, не нарушая. Кроме того, если разработчики не выполняют разные задачи в разных областях, менее вероятно, что изменения столкнутся. Так что, как правило, хорошо иметь двух или трех разработчиков или пар разработчиков, которые работают в основном в определенной подсистеме проекта и хорошо это знают.
Однако, если только один человек когда-либо должен касаться определенной строки кода, то когда этот парень уходит, увольняется, уходит в отпуск или попадает в больницу, и эта строка кода демонстрируется как причина ошибки это должно быть исправлено, кто-то другой должен войти и понять код. Если никто, кроме парня, который написал это, никогда не видел этого, потребуется время, чтобы достичь уровня понимания, который позволяет разработчику вносить изменения, которые исправляют ошибку, не делая больше. TDD может помочь, но только сообщив разработчику, что он сделал «неправильное» изменение; Опять же, разработчик должен понимать, какие тесты выполняют, какой код, чтобы убедиться, что провальные тесты не пытаются сделать неправильные утверждения.
источник
Я не принимаю это до крайности, но я предпочитаю ответственность за код . Вы пишете неработающий код, вы должны это исправить. Это может быть сделано на индивидуальном, парном или командном уровне. Это предотвращает передачу вашего беспорядка кому-то другому для очистки. Это касается и изменений.
Проблемы с рабочей нагрузкой и расписанием перезапишут это. Было бы глупо откладывать исправление серьезной ошибки, поскольку виновник находится в двухнедельном отпуске.
Цель состоит не в том, чтобы ваша команда играла в «игру в вину» или не принимала слишком много ошибок (в любом случае они не равны). Основывайтесь на том, кто проверял код в прошлом или поручил руководителю принять решение и назначить его кому-либо, вместо того чтобы просматривать каждую часть каждой строки кода.
Лучшие программисты, вероятно, в конечном итоге исправят множество чужого кода независимо от того, как вы его назначаете.
источник