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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удача с этим. Я чувствую Вашего брата боли.

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

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

с этим в памяти, существует много, чтобы быть сделанным в коде;)

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

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

Как @JesperE: сказанный, сфокусируйтесь на коде, не кодере.

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

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

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

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

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

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

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

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

Необходимо объяснить , почему путь лучше .

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

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

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

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

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

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

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

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

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

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

Имейте обзоры кода и запуститесь путем рассмотрения ВАШ код.

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

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

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

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

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

Patience. Эволюция, не оборот.

Удача.

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

Идея стандарта кода является хорошей.

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

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

Плохо именование методов: Всегда непростительный.

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

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

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

Запустите Wiki в своей сети с помощью некоторого программного обеспечения Wiki.

Запускают категорию на Вашем сайте, названном "лучшими практиками" или "кодированием стандартов" или чего-то.

Точка все к нему. Допускайте обратную связь.

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

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

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

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

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

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

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

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

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

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

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

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