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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. Список в Википедии о повторяющихся кодах.

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

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

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

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

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

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

Удачи.

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

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

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

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

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

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

Если вы превосходите его, просто «попросите» его поступить по-вашему ...

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

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

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