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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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