Как избежать плохих практик работы сотрудников

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

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

Так как вы руководитель группы....

Во-первых... были ли у вас какие-либо передовые методы кодирования? Если нет, плохой код — это ваша вина.

Во-вторых, вы проводите проверку кода, формальную или неформальную? Если нет, то плохой код опять ваша вина.

В-третьих... код на самом деле является плохой практикой, или это просто не ваш предпочтительный метод ведения дел? Поскольку вы сказали: «... потому что это МОЖЕТ ограничивать производительность приложения», похоже, это означает, что оно не сломано, просто не так, как вы этого хотите.

Независимо от того, чтобы ответить на ваш вопрос, НЕТ... вы не вносите изменения самостоятельно. Поговорите с PM и если есть время и реальная НАДО, то пусть разработчик, который писал код, внесет изменения и объяснит, зачем это нужно. Вы говорите как программист-перфекционист, так что честно посмотрите на код и на себя и спросите, не хотите ли вы, чтобы все было сделано по-вашему, или это действительно плохой код. Имейте в виду, что придираться к чьей-то работе только потому, что она сделана не так, как вы бы это сделали, — это верный способ потерять их уважение и желание слушать вас.

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

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

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

Это может быть достигнуто различными путями. Я бы предложил следующее:

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

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

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

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

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

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

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

Это касается только производительности?

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

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