Как исправить копию / вставить-образец?

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

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

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

Одна часть ответа - Рефакторинг .

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

Другая часть - это образование .

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

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

Вашей компании также может потребоваться пересмотреть стимулы и критерии приемлемости для консультантов - если им удастся написать небрежный код, они наверняка продолжат выбирать более легкий путь. Если компания продолжает ценить «быструю доставку» в течение длительного срока поддержки, ничего не изменится :-( Поэтому вам, возможно, придется обсудить это и с руководством. Один из способов дать им понять это: рефакторинг означает поддержание кода в чистоте, простота понимать и поддерживать. Отказ от рефакторинга подобен накоплению задолженности по вашей кредитной карте, Вы можете сойти с рук на некоторое время, но если вы не будете активно управлять своими покупательскими привычками и долгами, это неизбежно рухнет вам на плечи в один прекрасный день. В жизни программного проекта банкротство - это когда проект становится неуправляемым: его легче переписать с нуля, чем добавить новую функцию в существующую кодовую базу. Или пользователи настолько устали от низкого уровня поддержки и функций, что просто переключаются на конкурентов.

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

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

люди (консультанты) чувствуют себя вынужденными выпустить функции как можно быстрее

У вас нет технической проблемы, у вас есть социальная проблема. Действительно, у вас есть проблемы с управлением.

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

«Кодовая база открыта для всей компании» - не проблема. Не имеет значения

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

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

Ты должен

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

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

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

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

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

Сегодня мне пришлось добавить еще одну функцию, и я просто не мог ее больше использовать. Я создал новую библиотеку, объединил 100+ функций в 10 повторно вводимых функций, которые слегка изменяют их поведение на основе битовых флагов, а затем написал серию тестов, чтобы убедиться, что любые изменения в этой библиотеке не сломали ничего другого.

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

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

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

Я согласен с ответами, данными до сих пор. Вам следует:

• создать юнит-тесты
• рефакторинг
• воспитывать
• приложить усилия для разработки стандартов кодирования и выявления нарушений

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

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

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

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

прочитайте Руководство по проектированию фреймворка

Надеюсь это поможет.

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

Если вы сможете найти способы использовать более нюансированное отношение, сказать разработчикам не «это плохо!», А «это неполно, можете ли вы поработать со мной, чтобы завершить рефакторинг?», Тогда вы можете провести более конструктивные беседы.

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

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

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

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

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

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

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

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