Как вы говорите кому-то, что они пишут плохой код? [закрыто]


217

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


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

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

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

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

1
Если вы читаете переполнение стека, вы хороший программист :-)
Мэтью Фарвелл

Ответы:


188

Введите вопросы, чтобы они поняли, что то, что они делают, неправильно. Например, задайте такие вопросы:

Почему вы решили сделать это глобальной переменной?

Почему вы дали ему это имя?

Это интересно. Я обычно делаю это так, потому что [Укажите причину, почему вы лучше]

Это работает? Я обычно [Укажите, как бы они выглядели глупо]

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

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

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


Это хорошая техника, и, вероятно, наиболее подходящая в профессиональной среде. Если ваш коллега легкомысленно отвечает на подобные вопросы вместо того, чтобы на самом деле их рассматривать, или у него неточные ответы, вполне вероятно, что они проигнорируют стандарт кода или другие «авторитеты».
Грег Д

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

24
Я думаю, что такие вопросы, как "Почему вы дали ему это имя?" близки, но не совсем правы. Это сразу заставляет меня задуматься о своих решениях. «Это интересно. Я обычно делаю это так, потому что [Укажите причину, почему вы лучше]» гораздо лучше, потому что это заставляет меня думать о путях других чем я уже решил. С последним тоном, я гораздо чаще вижу свет.
Билл Ящерица

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

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

85

Начните делать обзоры кода или парное программирование.

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

Как сказал @JesperE: сосредоточьтесь на коде, а не на кодере.

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

Globals : Как вы думаете, мы когда-нибудь захотим иметь более одного из них? Как вы думаете, мы хотим контролировать доступ к этому?

Изменяемое состояние : как вы думаете, мы хотим манипулировать этим из другого потока?

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

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

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

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


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

2
Если ваши коллеги хорошо реагируют на такие вещи, они добрее, чем мои. Когда я пытаюсь получить такие комментарии, мне обычно говорят, что нужно с этим справляться. Или, возможно, обращались к многостраничному монологу о том, что их путь - единственный путь. Несмотря на то, что в .Net встроен разбор строк в целые числа, dangit.
Грег Д

@ Грег: Ой. Жесткая толпа у вас там!
Джей Базузи

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

LOL @ "эмоционально привязан к коду." если у вас есть такие проблемы в вашей команде, по моему мнению, пришло время найти другую команду для работы.
DTC

45

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


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

1
Один из лучших и простых способов обеспечить его соблюдение.
Скотт Дорман

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

2
@ Скотт Дурман: «Весь код должен выглядеть так, как будто он написан одним человеком за один присест» ... LOL !!! ;-)
Galwegian

5
@Galwegian: Во-первых, если вы собираетесь использовать мое полное имя, по крайней мере, правильно пишите его. :) Почему это утверждение смешно для вас? Как я уже сказал, это идеал стандарта кода. Я никогда не говорил, что это вполне достижимо, но оно дает ясную, четко определенную цель для работы на башнях.
Скотт Дорман

23

Вы должны объяснить, почему ваш путь лучше .

Объясните, почему функция лучше, чем вырезание и вставка.

Объясните, почему массив лучше, чем $ foo1, $ foo2, $ foo3.

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

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


1
Я думаю, что это относится практически ко всем возможным заповедям (не только к программированию).
Дмитрий С.

«вычеркнуть стандарт кодирования и сказать« сделай это »бесполезно» - во-первых, хороший письменный документ по стандартам кодирования должен содержать обоснование для каждого пункта, который он делает, во-вторых, даже без этого обоснования он вряд ли бесполезен - его все равно можно использовать как ссылочный пункт, если согласовано командой, когда найден какой-то код, который не следует ему, чтобы избежать бесконечных дискуссий на тему "но мне это нравится так!"
Иоганн Герелл

14

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

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

Другой вариант - принести технические книги в офис (Code Complete, Effective C ++, Pragmatic Programmer ...) и предложить одолжить их другим («Эй, я с этим покончил, кто-нибудь хотел бы одолжить их?» )


12

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


10

Предложите лучшую альтернативу без конфронтации.

«Эй, я думаю, что этот способ тоже сработает. Что вы, ребята, думаете?» [Жест явно лучшего кода на вашем экране]


10

Имейте обзоры кода, и начните с обзора ВАШЕГО кода.

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


8

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


О, это, конечно, правда! «Почему вы используете класс для хранения строки, в то время как вы можете использовать низкоуровневые подпрограммы C для выполнения строковых манипуляций (включая выделение / освобождение памяти и ручное добавление 0-терминатора)?» И действительно, эти программисты часто использовали свой стиль программирования для успешного завершения больших проектов, странно, но верно.
Дмитрий С.

7

К примеру. Покажите им правильный путь.

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


7

Идея кода стандартная.

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


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

7
"Это просто код"? Это просто результат ваших усилий, вашего профессионального лица, вашего вклада в компанию или человечество в целом. Кого волнует, хорошо это или плохо? Бьюсь об заклад, ваши коллеги яростно читают эту тему, пытаясь понять, как сказать, что ваш «просто код» - это мусор.

4
Это просто код? Helloooo обслуживание кошмар.
MetalMikester

6

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


5

Плохая практика именования: всегда непростительно.

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

У меня был опыт работы с кодером, у которого было такое ужасное именование функций, код был хуже, чем нечитаемый. Функции лгали о том, что они сделали, код был бессмысленным. И они были защитными / устойчивыми к тому, чтобы кто-то еще изменил их код. когда они были очень вежливы, они признали, что он плохо назван, но хотели сохранить право собственности на код и вернутся и исправят его «позднее». Это уже в прошлом, но как вы справляетесь с ситуацией, когда они ошибаются, но затем защищаются? Это продолжалось долго, и я понятия не имел, как преодолеть этот барьер.

Глобальные переменные: я сам не люблю глобальные переменные, но я знаю несколько отличных программистов, которые их любят ОЧЕНЬ много. Настолько, что я пришел к выводу, что на самом деле они не так уж и плохи во многих ситуациях, поскольку они обеспечивают ясность и простоту отладки. (пожалуйста, не говорите мне плачевно / недооценивайте :)) Все сводится к тому, что я видел много очень хорошего, эффективного кода без ошибок, в котором использовались глобальные переменные (я не вставил это!) и много ошибок, невозможно прочитать / сохранить / исправить код, который тщательно использовал правильные шаблоны. Может быть , есть IS место (хотя сокращение возможно) для глобальных переменных? Я подумываю переосмыслить свою позицию, основываясь на доказательствах.


5

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

Создайте категорию на своем сайте под названием «лучшие практики» или «стандарты кодирования» или что-то в этом роде.

Укажи всем на это. Разрешить для обратной связи.

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

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


4

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

Если у вас нет формата кодирования, сейчас самое время его установить. Что-то вроде ответов на этот вопрос может быть полезным: /programming/4121/team-coding-styles


4

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


3

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


3

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

«Каждый может написать код, понятный машине, но не все могут написать код, понятный человеку»

Имея это в виду, в коде многое предстоит сделать;)


Я обнаружил, что это тоже правда. Приятное чтение: вещи, которые вы никогда не должны делать, часть I. Автор Joel Spolsky joelonsoftware.com/articles/fog0000000069.html Он говорит это своими словами: «Код читать сложнее, чем писать».
MJN

3

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

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

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

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

Терпение. Эволюция, а не революция.

Удачи.


3

Я надеваю тогу и открываю банку сократовского метода.

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


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

2

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

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


2

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

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


2

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

  • Собственный опыт людей оставляет более сильное впечатление, чем то, что вы скажете.
  • Некоторые люди не в восторге от кода, который они создают, и не будут слушать то, что вы говорите
  • Парное программирование может помочь поделиться идеями, но поменять, кто за рулем, или они просто будут проверять электронную почту на своем телефоне
  • Не топите их слишком много, я обнаружил, что даже непрерывную интеграцию нужно было объяснить несколько раз некоторым старшим разработчикам
  • Разбудите их снова, и они захотят учиться. Это может быть что-то простое, как программирование роботов на один день
  • ДОВЕРЯЙТЕ СВОЕЙ КОМАНДЕ, стандарты кодирования и инструменты, которые проверяют их во время сборки, часто никогда не читаются и не раздражают.
  • Удалите владение кодом, в некоторых проектах вы увидите хранилища кода или муравейники, где люди говорят, что это мой код, а вы не можете его изменить, это очень плохо, и вы можете использовать парное программирование, чтобы удалить это.

1
Я полагаю, что преднамеренное невежество можно назвать глупым? Это то же самое, что не желать учиться.
Адам Нейлор

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

2

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

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


Еще лучше: попросите их поддерживать код других разработчиков. Это также может помочь улучшить связь между ними ...
Mjn

Это также намного менее антагонистично :-)
JDrago

2

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

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


2

У меня похожий сенарио с парнями, с которыми я работаю. Они не так подвержены кодированию, как они, но они все еще полезны при кодировании.

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

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

  1. Обсудить.
  2. Покажите им, почему
  3. Даже не думайте, что вы всегда правы. Иногда даже они научат вас чему-то новому.

Вот что бы я сделал на твоем месте: D


1

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


1

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

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

Только тогда их разум сломается, и любой сможет увидеть, что:

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

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


1

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


1

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

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

Удачи с этим. Я чувствую твою боль, брат.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.