Как вы стимулируете хороший код? - PullRequest
5 голосов
/ 24 сентября 2008

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

Ответы [ 15 ]

5 голосов
/ 24 сентября 2008

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

5 голосов
/ 24 сентября 2008

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

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

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

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

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

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

4 голосов
/ 24 сентября 2008

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

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

3 голосов
/ 24 сентября 2008

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

2 голосов
/ 24 сентября 2008

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

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

1 голос
/ 24 сентября 2008

Я согласен с Биллом Ящерицей. Но я хотел добавить к тому, что сказал Билл ...

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

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

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

Все это происходит из реального жизненного опыта, и мы продолжаем использовать этот подход на моей работе.

Надеюсь, это поможет, хороший вопрос!

1 голос
/ 24 сентября 2008

Вы избавляетесь от тех, кто не пишет хороший код.

Я совершенно серьезно.

1 голос
/ 24 сентября 2008

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

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

1 голос
/ 24 сентября 2008

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

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

1 голос
/ 24 сентября 2008

Это совет, направленный на вас, а не на вашего босса.

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

...