Здравствуйте, я работаю в веб-разработке. Я несу ответственность за выполнение проекта. У меня есть джуниоры, которым я делегирую задачи, и они это делают. Этот поток кажется мне хорошим.
Но когда я смотрю в код, я нахожу некоторые вещи, которых там быть не должно. Некоторых практик там быть не должно. Я не кодер-ниндзя, но я могу распознать вредные привычки.
Под плохой практикой я не подразумеваю неправильность, код будет работать так, как ожидалось, но я в некотором роде обсессивно-компульсивное расстройство, и иногда это меня раздражает, потому что это может ограничить производительность приложения.
У меня есть два варианта решения этой проблемы:
Оставьте работу как есть, скажите им, чтобы они больше не повторялись, так как текущая версия работает нормально.
Исправьте все самостоятельно или поручите им исправить это, но этот подход займет некоторое время и приведет к задержке проекта.
Какой подход я должен использовать здесь или есть какое-либо другое решение для этого?
Подготовьте документ со стандартами кодирования для своей команды, указав, что приемлемо, а что нет.
Затем разрешите слияние кода с основной ветвью вашего репозитория исходного кода только после того, как этот код подвергся проверке кода. Вы можете использовать такие инструменты, как StyleCop, для автоматического применения определенных правил, но когда вы сидите и проводите проверку кода, вы становитесь более представительным в своей команде.
Так как вы руководитель группы....
Во-первых... были ли у вас какие-либо передовые методы кодирования? Если нет, плохой код — это ваша вина.
Во-вторых, вы проводите проверку кода, формальную или неформальную? Если нет, то плохой код опять ваша вина.
В-третьих... код на самом деле является плохой практикой, или это просто не ваш предпочтительный метод ведения дел? Поскольку вы сказали: «... потому что это МОЖЕТ ограничивать производительность приложения», похоже, это означает, что оно не сломано, просто не так, как вы этого хотите.
Независимо от того, чтобы ответить на ваш вопрос, НЕТ... вы не вносите изменения самостоятельно. Поговорите с PM и если есть время и реальная НАДО, то пусть разработчик, который писал код, внесет изменения и объяснит, зачем это нужно. Вы говорите как программист-перфекционист, так что честно посмотрите на код и на себя и спросите, не хотите ли вы, чтобы все было сделано по-вашему, или это действительно плохой код. Имейте в виду, что придираться к чьей-то работе только потому, что она сделана не так, как вы бы это сделали, — это верный способ потерять их уважение и желание слушать вас.
Хороший код и качественный продукт — не единственная ваша обязанность перед компанией; вы также должны обучать и продвигать свою команду.
Большинство программистов стремятся писать хороший код и имеют представление о том, как это сделать лучше всего. Они не всегда соглашаются друг с другом в этом. Цель не должна заключаться в том, чтобы заставить их делать это именно так, как вы говорите — кроме всего прочего, вы, несомненно, тоже можете учиться у своей команды.
Конечно, вы хотите придерживаться хороших стандартов, и это включает в себя то, что команда пишет код согласованным образом, а не занимается каждый своим делом. Как вы упомянули, некоторые практики технически лучше других, и вы захотите включить хорошие из них в свои рекомендации.
Это может быть достигнуто различными путями. Я бы предложил следующее:
Старайтесь, насколько это возможно, помогать вашей команде создавать высококачественный код. Они оценят уважение, которое это влечет за собой
Если у вас есть полномочия, вы можете установить правила кодирования и попросить младших выполнять их.
Если у вас нет полномочий, вы мало что можете сделать, вы можете исправить это самостоятельно или попросить менеджера поговорить с ними. Но если вы делаете последнее, у вас должны быть письменные инструкции, бесполезно говорить, что это неправильно, если вы не можете показать им «правильный» способ сделать это.
Как сказали другие, существует набор хороших практик, которые существуют практически для каждого языка/фреймворка и задокументированы в сети, и они являются инструментом, помогающим вам в проверке кода.
Если у вас есть полномочия, но нет надлежащих навыков для обеспечения соблюдения надлежащего документа с лучшими практиками, делегируйте его кому-нибудь. Я предпочитаю не применять лучшие практики, чем получать их от кого-то, кто на самом деле не понимает, о чем он говорит, особенно если речь идет о производительности .
Под плохой практикой я не подразумеваю неправильность, код будет работать так, как ожидалось, но я в некотором роде обсессивно-компульсивное расстройство, и иногда это меня раздражает, потому что это может ограничить производительность приложения.
Это касается только производительности?
Если это так, я предлагаю вам добавить в процесс проверки правильные тесты данных, если у вас их еще нет. Под правильными тестами данных я подразумеваю сгенерированные данные, объем которых соответствует ожидаемой реальности. Если вы делаете, например, веб-приложение, вы можете установить, что каждое основное действие должно занимать менее секунды, а сложная ночная работа - менее часа? Если тест провален, то есть что копать.
Наконец, если есть какой-то специальный фрагмент кода, который действительно выглядит неправильно для вас с точки зрения производительности, и высокоуровневого теста производительности вам недостаточно, изолируйте его в модульном тесте, запустите его на каком-то огромном сгенерированном наборе данных и убедитесь сами. результат.
Is that only about performance ?
Вероятно, он имеет в виду что-то вроде использования var myVariable = "abc";
вместо let myVariable = "abc";
или, возможно, что-то вроде хранения параметров в виде одной длинной строки вместо добавления разрыва строки после каждой запятой.it irritates me sometimes because it may limit the performance of the app
мне кажется довольно ясным.
Килиси
кешлам
Дирадж Вакчауре
Мог говорит восстановить Монику