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

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

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

Я работаю с командой, которая выросла с 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 есть несколько интересных дискуссий по этому вопросу:

• SVN автоматическое форматирование кода при регистрации?
• Контроль версий и форматирование кодирования
• PHP codesniffer (phpcs) - как разрешить переопределение при использовании в качестве части svn pre-commit hook?
• Хук предварительной фиксации SVN, запускаемый для определенной папки
• Реализация стандартов кодирования PHP

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

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

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

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

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

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

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

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

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

,

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

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

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

1. решив, что чей-то код лучше или хуже других членов команды. Это просто так не работает - каждый знает определенное подмножество языка достаточно хорошо, чтобы использовать его в коде. Каждый программист выбрал разные подмножества для изучения, и если они не изучат это вместе, это будет выглядеть по-другому.
2. Меняется, как кто-то пишет код. Все, что вы заставляете людей писать незнакомый стиль, это то, что вы получаете большое количество ошибок в коде. Люди просто не знают достаточно деталей о том, что они используют в первый раз. Программисты всегда выбирают подмножество языка и используют его в одиночку. Если ваши программисты написали тысячи строк кода, заполненных gotos, то gotos предоставит вам код с наименьшим количеством ошибок.
3. Вы также не должны думать, что ваша существующая кодовая база - хороший, чистый, обслуживаемый материал. Всегда есть что улучшить. Но также каждое изменение стирает оригинальную идею дизайна, которая была написана ему. Старайтесь писать идеальный код с первого раза, чтобы изменения не понадобились позже. (новому парню не нужно будет «ломать» ваш идеальный код, если это было сделано правильно с первого раза)

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

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

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

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

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

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

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

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

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

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