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

16

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

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

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

LennyProgrammers
источник
3
Самое неприятное, когда код копируется / вставляется с какого-либо сайта, а затем даже комментарии не удаляются. Так что вы можете найти: «// Спасибо за это Карло» ... И когда вы указываете им, они просто смеются и говорят: «Оставьте это!))». Это не профессионально и грустно !!!
CoffeeCode
2
это не только консультанты
AndersK

Ответы:

14

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

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

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

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

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

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

Петер Тёрёк
источник
4
«Во-первых, начните писать модульные тесты, чтобы убедиться, что вы случайно не нарушите свои изменения». Вау, прокачай тормоза там. Мне действительно не нравится, как все на сайтах SE так небрежно бросают эту строчку в своем ответе. Это очень трудно понять, и это не так случайно, как 99% пользователей, которые предлагают это сделать.
@ Sergio Tapia - правда, но вы не можете рефакторинг без него. Добро пожаловать в реальность, около 2011 года.
Скотт Уитлок
1
@ Серджио, если ты имеешь в виду, что модульное тестирование унаследованного кода сложно, я не могу согласиться с этим. Я рад расширить цитируемое предложение следующим образом: «Во-первых, вы должны приступить к трудной и напряженной задаче написания модульных тестов ...» :-) Однако, если вы имеете в виду, что, поскольку модульное тестирование является сложным, следует попытаться обойтись без с этим я категорически не согласен (исходя из практического опыта, а не теории). Нет никакой королевской дороги к поддержанию унаследованного кода.
Петер Тёрёк
9

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

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

RSP
источник
1
Мне нравится это, хороший!
Оз
Можно ли требовать соблюдения стандарта кодирования в контракте подрядчика?
Арманд
1
@ Алисон Вы можете требовать соблюдения того, что вам нравится, если вы заявляете заранее, у вас не должно быть проблем. Как подрядчик, я придерживаюсь любых требований развития, которые требуются компаниям, в которых я работаю, и одна из них соответствует их стандартам кодирования. Проверка кода перед отправкой в ​​транк также может помочь решить эту проблему
DBlackborough
Спасибо, после вашего поста я также нашел clonedigger.sourceforge.net для Python / Java.
LennyProgrammers
@ G3D имеет смысл; Вам нравится работать со стандартом кодирования? Моя проблема с проверками кода как формой признания заключается в том, что как подрядчик я был бы обеспокоен тем, что код может быть отклонен по произвольным причинам (например, политика или изменения в бюджете)
Арманд,
8

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

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

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

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

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

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

Ты должен

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

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

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

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

С. Лотт
источник
1
+1 специально для «Вы должны помочь менеджерам взять кредит на новый подход, который заставит их хорошо выглядеть, и вас будут игнорировать». Лучше быть готовым к тому, что слишком часто это становится реальностью :-(
Петер Тёрёк
@ Петер Török: Слишком много людей отказаться от этого. Они либо не собирают факты о проблемах, вызванных копированием / вставкой, либо не продолжают доводить дело до сведения руководства.
S.Lott
Я знаю, что здесь есть более глубокая, нетехническая проблема. Но это проблема, которую никто не может решить в ближайшее время. Это похоже на ошибку в сторонней библиотеке, которую нужно обойти.
LennyProgrammers
@ Lenny222: Ваш комментарий не имеет большого смысла. «Это проблема, которую никто не может решить в скором времени» - это ясно из вопроса. Что означает этот комментарий? Чего не хватает в ответе? Что еще тебе нужно?
S.Lott
Это будет непрерывный образовательный процесс.
JeffO
5

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

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

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

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

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

Тим Пост
источник
Любопытно, вы нашли что-нибудь идентичное?
JeffO
@Джефф - Да, несколько. Но в основном шаблон показал, что дублирование было результатом того, что кто-то хотел, чтобы какой-то (должен быть) код библиотеки делал что-то немного другое.
Тим Пост
5

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

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

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

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

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

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

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

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

KeesDijk
источник
3

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

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

Карл Манастер
источник
2

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

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

user281377
источник
2

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

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

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

JeffO
источник
Я согласен. Дело в том, что у менеджеров проектов нет стимула платить больше за хорошо разработанный код. Если мне придется потратить неделю, они не взимаются.
LennyProgrammers
@ Lenny222 - то, к чему вы можете стремиться, это выбрать ваши места в проекте, чтобы сделать код лучше. Торговая точка для премьер-министра не произойдет, пока они не вернутся (обычно с хвостом между ног) и нуждаются в том, что, по их мнению, станет серьезным изменением только для того, чтобы услышать ваш ответ «не беспокойтесь, мы сделали эту часть более гибкой» , В конце концов они могут узнать, что есть верный способ сделать что-то и управлять ожиданиями клиента. Все хотят качественное программное обеспечение, но мало кто знает, сколько оно на самом деле стоит.
JeffO
1

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

AndersK
источник
1

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

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

refro
источник