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

14

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

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

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

Ответы:

22

Я работаю с командой, которая выросла с 2 разработчиков до 10 менее чем за год. Я был номером 3 и первым поднял вопрос о стандартах кодирования. Два оригинальных разработчика работали бок о бок в течение нескольких лет, и они приняли общий стандарт, который казался мне чуждым. У нас были точно такие же проблемы, которые вы описываете.

То, что мы сделали, было:

Стандарты кодирования исследований

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

Мы втроем решили, что лучшими стандартами кодирования для установленного PHP-проекта были стандарты Zend Framework. К счастью, сотрудники Zend Framework предоставляют очень полный документ по стандартам кодирования .

Создание наших собственных стандартов кодирования

Конечно, применять к нашему проекту стандарты кодирования другого проекта не имеет смысла. Мы используем документ Zend Framework в качестве шаблона:

  • Сначала мы удалили все, что не относится к нашему проекту
  • Затем мы изменили все, что мы воспринимали как вопрос стиля, на наш стиль.
  • И наконец мы записали все

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

Оставаясь верным нашему обещанию

Наша кодовая база в то время составляла около 1 * 10 ^ 6 sloc. Мы знали, что с тех пор, как мы приняли формальные стандарты кодирования, нам пришлось начать рефакторинг нашего кода, но в то время мы столкнулись с другими проблемами. Поэтому мы решили просто провести рефакторинг наших основных библиотек, всего 5 * 10 ^ 3 sloc.

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

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

Общение с новым парнем

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

Поскольку я был мастером стандартов кодирования в то время, я должен был оценить его вклад и соответственно пересмотреть документ. Его предложения были:

  • Вопросы личного стиля (в общем уволены)
  • Стандарты, которые имели смысл для его фона Java, но не так много с PHP (отклонено)
  • Условные обозначения, которые он взял из своего краткого знакомства с PHP (некоторые были отклонены, но многие оказались популярными соглашениями, о которых мы никогда не думали и не обнаружили в нашем первоначальном исследовании)

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

  • Код должен быть относительно простым для тех, кто не знаком с нашей базой кода (и PHP в целом)
  • Код должен быть на том, что он был нанят, чтобы сделать

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

А потом появился еще один новый парень. Мы повторили процесс (другой мастер на этот раз), и он снова заработал. И опять.

В заключение

  1. Создайте документ по стандартам кодирования, но убедитесь, что ваши стандарты не являются исключительно вашими, но отражают общие стандарты в более широком сообществе вашей платформы.
  2. Назначьте аналогичную роль нашему мастеру по стандартам кодирования. Кто-то, чтобы отслеживать, по крайней мере, новый код, и особенно новый код от новых участников. Переработайте роль, так как она очень скучная.
  3. Всегда оценивайте вклад нового участника. Всегда пересматривайте свои стандарты, если это имеет смысл. Ваш документ по стандартам кодирования должен развиваться, но медленно. Вы не хотите реорганизовывать свою кодовую базу на каждой итерации.
  4. Выделите какое-то время каждому новому члену для изучения и адаптации к вашим стандартам и соглашениям. Учитесь, выполняя работу лучше всего в этих ситуациях.
  5. Вики творит чудеса для таких документов.
  6. Кодовые обзоры творит чудеса для любой ситуации!

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

Некоторые из них специфичны для PHP, но ответы относятся ко всем платформам.

Яннис
источник
Если бы на все практики управления развитием можно было ответить так хорошо ... спасибо!
jleach
3

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

Ваша команда должна сесть вместе и составить набор правил, стандартов кодирования , которые вам потребуется для выполнения каждого фрагмента проверенного кода.

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

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

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

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

littleadv
источник
Вот как мы это сделали в нашей команде: мы обсудили и утвердили стандартный документ по кодированию и используем проверки кода для каждой регистрации. Это работает довольно хорошо.
Джорджио
3
  1. Кто-то отвечает - они должны действовать как это.
  2. Если стиль кодирования так важен, почему это не было объяснено этому человеку, и пусть они знают, что у них не будет доступа к любому коду, пока они не изучат правила.
  3. Обзор кода - очевидно, у вас его нет или он очень слабый. Смотрите № 1.

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

,

JeffO
источник
1

Вот что можно сделать:

  1. Напишите документ, объясняющий требуемый стиль кодирования, и заставьте всех в команде изучить его. Сбор информации от каждого члена команды.
  2. Разделите задачи таким образом, чтобы каждый член команды отвечал за свою работу и мог определять соглашения этой части кода. Если какие-либо проблемы найдены, кто бы ни написал это, исправит проблемы.
  3. добавить автоматический инструмент для контроля версий, который исправляет отступы и другие вещи каждый раз, когда код передается в контроль версий
  4. Разные программисты всегда имеют разный стиль программирования, и позже это может быть трудно изменить. Лучший способ справиться с этим - делиться информацией между членами команды, чтобы каждый узнал, какие стили использовали люди. Если у вас есть член команды, который пишет другой код, у ваших членов команды есть шанс изучить новый стиль.
  5. Один хороший трюк - никогда не изменять существующий код. Вместо изменения кода напишите новый код, заменив пустые строки новым кодом. И как только код будет готов, внесите лишь небольшое количество изменений в существующую систему, чтобы использовать новый код. Это позволяет избежать настройки существующего кода, возможно, нарушая то, что уже работало нормально.

Вот чего следует избегать:

  1. решив, что чей-то код лучше или хуже других членов команды. Это просто так не работает - каждый знает определенное подмножество языка достаточно хорошо, чтобы использовать его в коде. Каждый программист выбрал разные подмножества для изучения, и если они не изучат это вместе, это будет выглядеть по-другому.
  2. Меняется, как кто-то пишет код. Все, что вы заставляете людей писать незнакомый стиль, это то, что вы получаете большое количество ошибок в коде. Люди просто не знают достаточно деталей о том, что они используют в первый раз. Программисты всегда выбирают подмножество языка и используют его в одиночку. Если ваши программисты написали тысячи строк кода, заполненных gotos, то gotos предоставит вам код с наименьшим количеством ошибок.
  3. Вы также не должны думать, что ваша существующая кодовая база - хороший, чистый, обслуживаемый материал. Всегда есть что улучшить. Но также каждое изменение стирает оригинальную идею дизайна, которая была написана ему. Старайтесь писать идеальный код с первого раза, чтобы изменения не понадобились позже. (новому парню не нужно будет «ломать» ваш идеальный код, если это было сделано правильно с первого раза)
ТР1
источник
поэтому, чтобы использовать ваш ответ в оригинальном контексте OP ... есть программист, который вставляет хаки, использует макросы и имеет другие вредные привычки кодирования, поэтому вы предлагаете вырезать часть продукта, отдать его ему и вместо того, чтобы называть его код «плохой», назовите его «другой». Я не мог не согласиться с этим больше. При работе в команде важны постоянные коммуникации, дискуссии и обзоры по дизайну / кодированию, и по мере взросления команды все члены вашей команды будут УВЕЛИЧЕНЫ в своем мастерстве, потому что, как вы указали, мы все начинаем с разных подмножеств, но разговаривая друг с другом, мы ...
ДХМ
... учить друг друга, так что навыки и компетенции всей вашей команды повышаются. В противном случае у вас будут хорошие части продукта, но у вас будет еще много частей, которые станут бесполезными мессами, и ваши «владельцы» этих беспорядков просто продолжат взламывать, исправляя эти ошибки по мере их появления. С этой моделью изоляции Я видел, как люди годами работали над тем же компонентом, который никогда не был сделан правильно.
ДХМ
1
Нет, проблема не в том, что кто-то использует плохие привычки кодирования. Реальная проблема заключается в том, что они уже решили, что должны изменить способ написания кода одним человеком, а остальная часть команды считает, что их собственный код идеален. Люди улучшат свой стиль кодирования, если вы дадите им шанс, но эти люди решили заставить кого-то быстро совершенствоваться, хотя они никогда не удосужились сделать то же самое.
tp1
@DXM Многие замечательные языковые функции называются «уродливые хаки и ярлыки» людьми, которые раньше их не видели и не использовали. Лучше всего говорить о стандартах, чем просто решить, что новый парень - хакер.
Кирк Бродхерст
мы могли бы основывать наши ответы на различном опыте здесь. Среди прочего, OP сказал «использование определяет повсюду». Если это вместо типизированных констант, не так уж и плохо, но можно улучшить. Но я видел, как люди #define кусок кода, потому что они были слишком ленивы (или не умели) правильно реорганизовать класс и поместить общий код в функцию, которую можно было бы отлаживать. Абсолютно ни за что, я бы никогда не посчитал это «другим стилем» и позволил бы им продолжать это делать. Кроме того, все остальные ответы направлены на сближение команды к общему стилю / соглашению. Этот ответ ...
ДХМ
1

Наша существующая кодовая база содержит в основном читаемый, чистый и обслуживаемый код

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

Тем не менее, новый парень должен соответствовать вашим стандартам, а не наоборот.

geoffjentry
источник
0

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

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

Онлайн vcs-системы, такие как bitbucket или github, поддерживают эту функциональность. Если вы предпочитаете локальный подход, тайник кажется лучшим выбором в настоящее время.

Эсбен Сков Педерсен
источник
0

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

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

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

А с другой стороны, существуют стандарты качества. Никогда не принимайте код, который не соответствует вашим стандартам качества.

gnasher729
источник