Как убедить коллегу в том, что дублирование кода плохо?

Ответ 1

Спросите его, что он будет делать, когда найдет ошибку в своем коде. Сколько мест ему нужно будет исправить?

Вы также можете показать ему ответы на этот вопрос (почему "копировать и вставлять" кода опасно?).

Ответ 2

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

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

Ответ 3

Здесь есть два варианта:

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

• Он упрямая задница. Тогда вы не должны тратить на него энергию. Пойдите к его боссу и пусть босс позаботится об этом. Некоторые люди просто такие.

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

И, наконец, если ваш босс считает, что вы ошибаетесь, вы, вероятно, не в том месте.

Ответ 4

Дайте ему копию Рефакторинга.

Ответ 5

Улучшите свою версию кода настолько, что он расстроен ревностью, а затем скажите - если вы только что связались с моим кодом...

Ответ 6

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

Ответ 7

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

Вы можете запустить детектор клона над кодом и просто показать результаты его менеджеру.

См. Википедия о дублировании кода для списка.

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

Ответ 8

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

Ответ 9

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

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

Он может стыдиться и не делать этого в следующий раз (большой выигрыш). Я использовал это 4 раза, и он всегда работает!

Удачи.

Ответ 10

Есть много веских причин не дублировать код, а просто спросить... ваша команда хочет поддерживать 100K строк кода (с дублированием кода) или 50K строк кода? Может показаться, что дублирование кода на данный момент минимально, поэтому ваш коллега не видит важности концепции DRY, но представьте, если он/она дублирует все больше и больше кода на следующие 5 лет. Кто будет поддерживать этот код? Твоя команда? Что делать, если он однажды покинет работу? Ваша команда хочет сохранить это дерьмо?:) Если нет, то вы уже сделали очень убедительный случай, чтобы не дублировать код, не говоря уже о "более дублированиях" = "более склонны к большему количеству ошибок в будущем".

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

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

Если вы превосходите его, просто попросите его сделать свой путь...

Ответ 14

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

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

Это идея Ивара Якобсона энтропия программного обеспечения