Непрофессионально ли называть код «мусором»?

Что бы вы сделали из этого; Вы думаете, что мой язык был непрофессиональным?

Да.

Ваш комментарий перешел черту от исправления (которое обычно опирается на конкретные и конкретные комментарии) до оскорбления («это ужасно, и если мы продолжим в том же духе, мы обречены»).

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

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

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

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

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

1. Это было сделано публично, поэтому вас отвели в сторону (виртуально)
2. Это мешает команде.
3. Это порождает обиду.
4. Кодеры, как и художники, принимают критику ОЧЕНЬ лично.
5. Это было очень демотивирующей вещью. Продуктивность этого кодера пострадает.
6. Это делает других менее склонными к риску, чтобы они не были осмеяны.

Я должен самым решительным образом сказать, что это ПЛОХОЕ ДЕЛО . Этому поведению нет оправдания. Не повторяйте это.

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

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

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

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

Вы можете найти эту разницу между глобальной критикой и конкретной жалобой в литературе об отношениях. Объяснение Джона Готтмана (см. «Критика») является популярным примером.

Слова, которые вы выбираете, имеют значение, но контекст важнее. Совершенно нормально (в большинстве известных мне магазинов программного обеспечения) говорить «мусор на входе, мусор на выходе», потому что это имеет особое значение, и вы используете эту фразу, чтобы описать, почему конкретный дизайн не подходит. Иди разберись.

прямой, честный и прямолинейный.

Иначе говоря: резкий, резкий, недипломатичный.

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

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

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

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

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

Что бы вы сделали из этого; почему вы думаете, что мой язык был непрофессиональным?

Итак... вот в чем дело:

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

• Код — это работа разработчика; назвать это мусором в письменной форме на глазах у сверстников — это тяжелый удар.

Хорошо, это та часть, которая непосредственно касается вопроса. Ладно, хватит читать. Следующая часть... что вы могли бы сделать по-другому?

• Держите подробные предложения, это хорошо

• В разделе «Общие» скажите, что этот файл не соответствует рекомендациям в соответствии с подробными примечаниями ниже.

• Устройте перерыв, либо 1-1 с парнем, либо тренировку с командой, чтобы пройти лучшие практики. Другими словами, превратите эту ошибку в возможность

Всего два моих кусочка, йоу.

Это очень сильно зависит от корпоративной культуры. Тем не менее, есть некоторые общие вещи, которые следует учитывать. В основном есть две причины, по которым вызов кода мусора может считаться непрофессиональным:

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

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

Что касается 2), если код, на который вы ссылаетесь, является недавней фиксацией от определенного человека, этот человек может обидеться. Особенно, если у него были причины написать что-то объективно плохое, вроде нехватки времени, которые вы не принимаете во внимание. И часто то, что для вас является мусором, идеально подходит для кого-то другого, называя это мусором, вы просто добавляете эмоций в то, что в противном случае могло бы стать вполне обоснованным объективным обсуждением. На другом конце спектра — если вы берете на себя старую большую кодовую базу, которую никто в текущей команде уже не считает «своим кодом», довольно безлично называть эту большую кучу, вероятно, запутанным кодовым мусором (по-прежнему не адресует 1 .хотя и вам лучше подкрепить его). Другая проблема заключается в том, как вы произносите любую строку, содержащую ругательства. Чем эмоционально нагруженнее (и обвиняюще), тем хуже, беззаботнее,

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

Реагируют ли люди обижаться и считать вас (не)профессионалом исключительно на основании используемых вами слов, зависит от корпоративной культуры. Однако обычно люди будут судить о вас по тому, как вы используете свои слова. Если вы просто называете это мусором, не аргументируя свою точку зрения, не принимая доводы других разработчиков о том, почему код и так хорош, люди сочтут вас неразумным и осуждающим. А значит непрофессионально. Особенно, если вы явно или неявно обвиняете своих коллег в том, что считаете плохим кодом. Это верно независимо от того, употребляете вы ругательства или нет, т.е. говорить «этот код просто плохой», без дальнейших комментариев, тоже непрофессионально, но чем более эмоционально нагруженные слова вы используете (и чем более эмоционально нагружены вы их преподносите) , тем хуже это становится.

При этом, если вы разумно используете бранные слова, не адресуя их своим коллегам, а скорее как средство придать вес своим впечатлениям или выразить некоторое разочарование, это может быть совершенно нормально. Я работал в среде, где тон был очень прямым, игривым, а предложения часто были полны ругательств. Но, как правило, подобные ругательства были направлены на какие-то технические проблемы, на непредсказуемое поведение некоторых фреймворков или даже на собственный код («Посмотрите, какой мусор я там натворил, просто невероятно, что я это написал!»). С другой стороны, я редко видел команду, работающую так профессионально — уважающую друг друга, всегда ищущую, как решить проблему, а не как распределить вину.

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

Вы отправили этот комментарий не в ту сторону

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

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

Однако, похоже, что это было не то место, где был комментарий. Вместо того, чтобы бороться от имени вашей команды против руководства — удалять глупые метрики, которые, по мнению вашей команды, приводят к написанию мусора — вы сделали противоположное и поставили свою команду в режим «будь проклят, если будешь делать, будь проклят, если не будешь». "ситуация.

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

Сказать им, что код, который они пишут, — «мусор»; из-за системы, над которой они не властны, — это просто сигнал о том, что вы не прикрываете их спины и не хотите участвовать в их битвах.

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

Правильно, они выступили против вас в этом. Их ответ фактически «попробуйте обвинить в этом нас, и мы предельно ясно объясним, почему в этой ситуации виноваты вы».

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

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

Если улучшить показатель качества кода

Итак, общая цель — улучшить качество кода. Почему бы тогда не сказать: «Мы хотим улучшить качество кода»? Почему вы принимаете этот фрагмент кода как аргумент в пользу того, чтобы не улучшать качество кода.

Для меня (как для менее опытного разработчика, чем вы) это звучит как комментарий человека, привыкшего к своим старым привычкам и не приветствующего изменений (даже если это называется «качеством кода»).

мы должны ввести мусор, как показано ниже

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

ВЕДУЩИЙ разработчик с 15-летним стажем должен дать больше информации, чем назвать что-то "мусором" .

то у нас серьезные проблемы.

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

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

Относительно обновления 1 : если ваш полный комментарий был подробным и содержал всю указанную информацию. Зачем нужно было еще оскорблять разработчика (и ставить под сомнение цели вашей команды)?

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

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

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

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

Вы чувствовали, что этот код заслуживает более жесткой критики, потому что он исходил от инструмента, а не от человека, но вы не учли:

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

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

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

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