Чому "копіювати та вставляти" код небезпечно? [зачинено]

Іноді мій начальник скаржиться на нас:

Чому нам потрібен такий довгий час, щоб реалізувати функцію?

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

Це справді важке запитання, оскільки копіювати та вставляти коди - це не така проста річ, на мій погляд.

Чи є у вас якісь вагомі причини пояснити це своєму нетехнічному начальнику?

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

Якщо ви зберігаєте логіку в одному місці, її легше змінити, коли потрібно (тому якщо ви вирішите, що додаток потребує оновлення, ви робите це лише в одному місці).

Попросіть свого начальника прочитати про принцип DRY (не повторюйте себе).

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

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

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

Ви все одно отримаєте перевагу в швидкості від переписування (шукайте DRY), але у вас буде лише одне місце для підтримки коду.

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

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

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

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

• "Звичайно, у мене вже є код, який робить саме це!"
• "Зачекайте, яку з цих п'яти версій коду я хочу використовувати як джерело?"
• "Гммм, що роблять усі ці функції 'util_func_023'? Не я їх документував? Яка з них мені зараз потрібна?"
• "О, так, цей код використовує Code Base Y. Зрозуміло, мені потрібно [ вибрати один: скопіювати всю базу коду Y у мій новий проект / провести день, вилучаючи одну функцію, яку я хочу з бази коду Y / витратити тиждень на видобуток одну функцію, яку я хочу отримати з бази коду Y]. "
• "Я все скопіював, так!"
• "Чому це не працює?"
• Це момент, коли ви проводите години / дні / тижні, налагоджуючи існуючий код, подібний до того, що ви хочете, замість того, щоб писати код, який ви насправді хочете почати.

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

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

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

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

Принцип DRY (не повторюй себе): DRY на wikipedia .

"Кожна частина знань повинна мати єдине, однозначне, авторитетне представлення в системі".

інше посилання .

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

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

Звичайно, усунення введення тексту дозволить заощадити деякий час. Але тоді значно більша частина, яка не набирає текст, частина вашої роботи стає більшою і з'їдає будь-яку економію часу та більше того.

Ви впевнені, що ваш начальник хоче дізнатися про принципи DRY, помилки та інші технічні речі?

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

Чому це відбувається? Іноді спонсор проекту має занадто малий бюджет. Можливо, бізнес-процес, який ви автоматизуєте за допомогою програмного забезпечення, не варти зусиль вашої команди. Як правило, менеджери, як правило, дуже закриті для поганих новин у таких випадках. На початку проекту є бажане мислення. Тоді менеджери намагаються звинувачувати програмістів. У вашому випадку непрямим способом скопіюйте та вставте. У крайньому випадку це називається маршем смерті .

Копіювання та вставлення коду зазвичай призводить до програмування за допомогою співпадіння

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

У тому ж додатку «копіювати та вставляти» погано, але між кодовими базами, розробленими різними командами або з різними циклами випуску, «скопіювати та вставити» може бути найкращим варіантом.

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

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

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

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

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

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

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

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

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

Поведінки системи можна змінити за допомогою одноточкових модифікацій досить легко - зміна поведінки купи коду вимагає купового коду.

Мені подобаються системи, а не купа коду.

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

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

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

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

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

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