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

Ответ 1

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

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

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

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

Так ли работает? Я обычно [Вставьте, как вы заставили бы их выглядеть глупо]

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

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

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

Ответ 2

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

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

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

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

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

Mutable state. Как вы думаете, мы будем пытаться манипулировать этим из другого потока?

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

Прочитайте обзоры кода и начните с просмотра кода ВАШ.

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

Стандартная идея кода хорошая.

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

Ответ 12

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

Ответ 13

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

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

Назовите всех к нему. Разрешить обратную связь.

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

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

Ответ 14

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

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

У меня был опыт работы с кодером, который имел такое ужасное название функций, код был хуже, чем нечитаемый. Функции лгали о том, что они сделали, код был бессмыслен. И они были защитными/устойчивыми к тому, чтобы кто-то другой изменил свой код. когда они очень вежливо столкнулись, они признали, что он плохо назван, но хотели сохранить свою собственность на код и вернуться и исправить его "позже". Это уже в прошлом, но как вы справляетесь с ситуацией, когда они ошибаются, ПРИЗНАЕТСЯ, но затем защищены? Это продолжалось долгое время, и я понятия не имел, как преодолеть этот барьер.

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

Ответ 15

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

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

Ответ 16

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

Ответ 17

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

Ответ 18

Я действительно люблю код и никогда не имел никакого курса в моей жизни о чем-либо, связанном с информатикой, я начал очень плохо и начал учиться на примерах, но то, что я всегда помню и сохранял в виду, так как я читал "Gang Of Four" была:

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

имея в виду, в коде есть много чего;)

Ответ 19

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

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

Ответ 20

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

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

Ответ 21

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

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

Ответ 22

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

• Народы собственного опыта оставляют более сильное впечатление, чем то, что вы скажете.
• Некоторые люди не увлечены кодом, который они производят, и не будут слушать то, что вы говорите.
• Совместное программирование может помочь обмениваться идеями, но переключать тех, кто водит, или они просто будут проверять электронную почту на своем телефоне.
• Не торопите их слишком много, я обнаружил, что даже непрерывная интеграция должна быть объяснена несколько раз некоторым старым разработчикам.
• Получить их снова возбуждать, и они захотят учиться. Это может быть что-то простое, как программирование роботов в течение дня.
• TRUST YOUR TEAM, стандарты кодирования и инструменты, которые проверяют их во время сборки, часто никогда не читаются или не раздражают.
• Удалить право собственности на код, в некоторых проектах вы увидите силосы кода или холмы ant, где люди говорят, что это мой код, и вы не можете его изменить, это очень плохо, и вы можете использовать спаренное программирование, чтобы удалить это.

Ответ 23

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

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

Ответ 24

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

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

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

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

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

Удачи.

Ответ 25

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

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

Ответ 26

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

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

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

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

Вот что я буду делать, если бы я был вами: D

Ответ 27

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

Ответ 28

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

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

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

Ответ 29

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

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

Только тогда их ум щелкнет, и каждый сможет увидеть это:

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

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

Ответ 30

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