Як виправити шаблон копіювання / вставки?

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

Запобігти цьому непросто, оскільки база коду відкрита для всієї компанії. Над цим працює багато людей.

Тепер, коли безлад вже є, який найкращий спосіб прибрати ці надмірності, не порушуючи занадто багато?

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

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

Інша частина - освіта .

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

Ви можете зробити огляд групового коду, щоб відкрити дискусію про добрі та погані звички кодування та поширити переваги перших. Мало сказати, що "ви повинні (не) писати такий код", вам потрібно переконати людей у ​​логіці та важких фактах. На кшталт "якщо у вас є цей фрагмент методу, дубльований через кодову базу n разів, як ви вважаєте, що шанси на те, що якщо помилка буде знайдена в цьому методі, вона буде виправлена ​​у кожній копії коду методу?"

Можливо, Вашій компанії також доведеться переглянути стимули та критерії прийняття консультантів - якщо вони зможуть уникнути написання неохайного коду, вони неодмінно продовжуватимуть обирати більш простий шлях. Якщо компанія продовжує оцінювати "швидку доставку" протягом довгострокової ремонтоздатності, нічого не зміниться :-( Тож вам може знадобитися обговорити це також з керівництвом. Один із способів дати їм зрозуміти, це такий: рефакторинг означає зберегти код чистим, легко розуміти і підтримувати. Пропуск рефакторингу - це як накопичення боргу на вашій кредитній картці. Ви можете піти з цим на деякий час, але якщо ви активно не керуєте своїми звичками і боргами з покупки, це неминуче одного дня спаде на ваші плечі. В житті програмного проекту банкрутство - це коли проект стає неможливим: переписати його з нуля стає легше, ніж додати нову функцію до існуючої бази коду. Або користувачі настільки втомилися від нижчого рівня підтримки та можливостей, що вони просто переходять на конкуренцію.

У рамках освіти, на зразок @Peter, ви можете ввести детектор копіювання та вставки, як PMD, і використовувати його як частину циклу складання, щоб допомогти виконувати цю частину своїх стандартів кодування.

Переконайтеся, що стандарт кодування ваших проектів охоплює цю схему, щоб у вас була основна лінія, з якої можна почати обговорення.

люди (консультанти) відчувають тиск, щоб якнайшвидше випустити функції

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

Запобігти цьому непросто, оскільки база коду відкрита для всієї компанії. Над цим працює багато людей.

"Кодова база відкрита для всієї компанії" - це не проблема. Не має значення.

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

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

Ти мусиш

1. Почніть з верху, з менеджерами, які підсилюють нагороди. Ви повинні викрити існуючу практику та задокументувати витрати та ризики. Ви повинні запропонувати альтернативу, яка зменшує витрати та ризики.

2. Ви повинні безжально документувати та наражати кошти та ризик на весь час перебування у цій організації. Невгамовний. На основі фактів. Вартість та ризик. З кожним тижнем більше копіювання та вставки більше ризику.

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

Дуже важливо зменшити копіювання та вставлення. Але важко змінити культуру організації. Ви повинні надати безліч фактів, і вам доведеться переробляти справу знову і знову керівництву, який не згоден з вами.

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

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

Загальний витрачений час: 4 години. Я був готовий піти на 20-годинний марафон, якщо це було потрібно, і був здивований тим, як швидко я підвіз зростаючий безлад під контроль. Як бонус, було легше згодом виправити купу проблем із заголовком. Крім того, оскільки багато наших власних речей зараз є в статичних об'єктах для зв'язку, ми можемо надати клієнтам, які отримують доступ до вихідного коду більше, ніж ми раніше.

Моя порада: кусайте кулю і повторний фактор, який заплутався зараз перед тим, як зробити це, дійсно стає поганим . Мабуть, це не займе стільки, скільки ви думаєте, але створіть нову гілку для себе на всякий випадок.

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

Я згоден з відповідями, що даються до цього часу. Ти повинен:

• створити одиничні тести
• рефактор
• виховувати
• докладати зусиль до стандартів кодування та виявляти порушення

Але з іншого боку, ви повинні подивитися, що змушує людей копіювати пасту і виправляти це.

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

Тому я думаю, щоб зупинити шаблон копіювання / вставки, який вам потрібно полегшити повторне використання.

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

читайте Рамкові керівні принципи

Сподіваюсь, це допомагає.

Існує сильна позиція "копіювати пасту, що вважається шкідливою". Я думаю, що це добре, але йде занадто далеко. Скопіюйте пасту як вправу для виявлення подібності та відмінностей між двома методами чи класами - як крок у процесі тріангуляції - я думаю, що це здорово. Але зупинитись від повної триангуляції - усунення дублювання, запровадженого копіювальною пастою - справді шкідливо.

Якщо ви можете знайти способи використовувати це більш нюансове ставлення, щоб сказати розробникам не "це погано!", А, скоріше, "це неповно, чи можете ви працювати зі мною, щоб завершити рефакторинг?", То, можливо, ви зможете вести більш конструктивні розмови.

Я переживаю ту саму проблему, і я приймаю її за те, що не намагайтеся уникати її вперед, просто рефактор, коли вона стає занадто поганою.

Модуль, над яким я зараз працюю над стартетом, як копія іншого модуля, тепер я змінюю все, що має бути іншим. Після того, як це буде зроблено, і новий модуль буде закінчено, я порівняю його з оригінальним модулем і з’ясую, які частини є більш-менш незмінними і їх слід перемістити до бібліотеки, абстрактного батьківського класу тощо.

Хто відає, той винен. Від однієї людини не можна очікувати перегляду кожного рядка коду, але вони встановлюють стандарти та часові рамки.

Підрядники (або будь-хто, хто є короткостроковим у проекті), можуть бути поставлені на посаду, коли вони отримують лише компенсацію за те, щоб він працював уперше. Існує певний стимул, щоб зробити це якнайшвидше. Скопійований код, можливо, ніколи не буде потрібно змінювати, і якщо він його не буде, він не буде ним.

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

Єдиний спосіб усунути код копіювання / вставки - це огляди коду (IMHO), щоб людина (або, можливо, більше) перевірила код, і коли вони знайдуть код, який, здається, від дії копіювання / вставки, нехай програмує рефактор.

За пропозицією, це в основному проблема в організації. Спробуйте почати, навчаючи людей (не забувайте про прямий рівень управління над вашою посадою). Це дуже допомагає почати заводити одного або двох людей у ​​поїзд і нехай вірус пошириться. Коли більшість вважає, що це гарна ідея, опишіть її та спробуйте представити відгуки, щоб гарантувати, що вона залишається такою. Це дуже повільний і виснажливий процес, але він просто не може швидко змінитися. Спочатку це коштуватиме додатковий час, тому важливо, що управління знає та підтримує довгострокову мету.

@Anders K. Відгуки - хороший засіб для збереження практики. Коли люди змушують писати код, вони не вірять у це створює багато тертя. Вони потраплять назад у старе життя, як тільки зможуть. Я твердо вірю, що ви повинні почати з освіти, щоб набрати обертів.