Dlaczego „kopiowanie i wklejanie” kodu jest niebezpieczne? [Zamknięte]

130

Czasami mój szef narzeka nam:

Dlaczego potrzebujemy tak długiego czasu na wdrożenie funkcji?

Właściwie ta funkcja została już wcześniej zaimplementowana w innej aplikacji, wystarczy skopiować i wkleić stamtąd kody. Koszt powinien być niski.

To naprawdę trudne pytanie, ponieważ z mojego punktu widzenia kopiowanie i wklejanie kodów nie jest takie proste.

Czy masz jakieś dobre powody, aby wyjaśnić to swojemu nietechnicznemu szefowi?

Yigang Wu
źródło
19
wydaje się, że zamiast kopiować i wklejać kod z poprzednich aplikacji do nowej, ciągle przepisujesz tę samą funkcjonalność. Myślę, że zasada DRY jest bardziej ukierunkowana na brak powielania tej samej funkcjonalności w całym systemie, ale ponowne użycie kodu z innych aplikacji jest lepsze niż ponowne jego pisanie.
Carson Myers,
5
Ponieważ za każdym razem, gdy kopiujesz i wklejasz kod, foczka zostaje zabita.
DeadlyChambers
@CarsonMyers Tylko wtedy, gdy komponent jest wielokrotnego użytku. Ma to pasować do obecnego kontekstu.
Sreekanth Karumanaghat

Odpowiedzi:

171

Jeśli znajdziesz błąd w swoim kodzie kopiuj-wklej, będziesz musiał go naprawić w każdym miejscu, które zrobiłeś i mieć nadzieję, że możesz je wszystkie zapamiętać (dotyczy to również zmienionych wymagań).

Jeśli zachowasz logikę w jednym miejscu, łatwiej jest ją zmienić w razie potrzeby (więc jeśli uznasz, że aplikacja wymaga aktualizacji, robisz to tylko w jednym miejscu).

Poproś szefa o przeczytanie o zasadzie DRY (Don't Repeat Yourself).

To, co opisujesz, brzmi jak idealne zastosowanie dla bibliotek , gdzie udostępniasz kod i przechowujesz go tylko w jednym miejscu.

Kopiowałbym i wklejałbym kod tylko wtedy, gdybym wkrótce potem zamierzał go refaktoryzować - upewniając się, że później wyodrębniłem wspólny kod, aby móc ponownie wykorzystać jak najwięcej logiki. Wkrótce potem mam na myśli minuty i godziny później, a nie dni i tygodnie.

Oded
źródło
41
+1. Chodzi o to, że kopiowanie i wklejanie jest tanie w rozwiązaniu bezpośredniego problemu. Prawdziwym problemem jest to, że w perspektywie średnio / długoterminowej koszt utrzymania zduplikowanego kodu jest znacznie wyższy niż kod dobrze rozłożony na czynniki
Paolo
7
To nie jest tylko problem z błędem; wymagania programu mogą ulec zmianie. Zmieniłem cztery z pięciu miejsc, w których wcześniej trzeba było coś zmienić.
David Thornley,
1
Jeśli możesz kopiować i wklejać na żądanie i śledzić, gdzie duplikaty są łatwe do późniejszego wyodrębnienia lub zaktualizowania, kopiowanie i wklejanie nie jest złą rzeczą. Zobacz dyskusję na temat wykrywania klonów pod adresem www.semanticdesigns.com/Products/Clone, aby uzyskać dalsze szczegóły i narzędzia, które mogą to zrobić.
Ira Baxter
4
Jest ich dużo ifs, a większość narzędzi nie obsługuje obecnie wykrywania klonów.
Oded
2
Był sobie kiedyś programista, który pracował dla ESA . Pracował nad oprogramowaniem rakiety Ariane-5 i stosował metodę kopiuj-wklej. Wtedy ... się dzieje
Hauleth
25

Byłoby znacznie lepiej, gdybyś udostępnił kod, budując bibliotekę, zamiast kopiować kod za pomocą kopiowania i wklejania.

Nadal uzyskasz przewagę szybkości nad ponownym pisaniem (patrz DRY), ale będziesz mieć tylko jedno miejsce do utrzymania kodu.

CResults
źródło
1
Jestem po prostu ciekawy, dlaczego miałbyś „wycinać” kod, skoro wszystko, co musisz zrobić, to go skopiować?
dpp
Słuszna uwaga dpp. Edytowano!
CResults
12

Oczywistym powodem jest to, że zaciągasz `` dług '' na przyszłość: każda zmiana, jaką kiedykolwiek będziesz musiał wprowadzić w kodzie (nie tylko poprawki błędów, każda zmiana) będzie teraz dwa razy droższa, ponieważ musisz zaktualizować dwa miejsca - i bardziej ryzykowne, ponieważ w końcu zapomnisz o jednym z nich. Innymi słowy, przyspieszenie teraz pracy sprawi, że w przyszłości Twoja praca będzie jeszcze wolniejsza, co może mieć dobry sens biznesowy, ale zwykle nie jest.

Ale ważniejszym powodem jest to, że założenie „to jest to samo co tamto” jest najczęściej w subtelny sposób błędne. Ilekroć twój kod zależy od niewypowiedzianych założeń, aby był poprawny, skopiowanie go w inne miejsce skutkuje błędami, chyba że te założenia obowiązują również w nowym miejscu. Dlatego wklejony kod jest często nieprawidłowy od samego początku, a nie zaraz po kolejnej zmianie.

Kilian Foth
źródło
11

Z punktu widzenia projektu, kod wklejony do kopii jest z pewnością katastrofą, która może spowodować wiele problemów w przyszłości. Ale pytasz dlaczego zajmuje Ci dużo pracy teraz , odpowiedź brzmi: dlatego, że nigdy nie jest po prostu skopiowanie i wklejenie.

Jeśli oryginalny kod został napisany w celu ponownego wykorzystania, jako dość niezależna biblioteka, z myślą o elastyczności i obsłudze klienta - to świetnie, ale to nie jest kopiowanie i wklejanie, to użycie biblioteki kodu. Kopiowanie i wklejanie prawdziwego kodu zazwyczaj wygląda tak:

  • „Jasne, mam już kod, który dokładnie to robi!”
  • „Czekaj, która z tych pięciu wersji kodu jest tą, której chcę użyć jako źródła?”
  • „Hmmm, do czego służą te wszystkie funkcje 'util_func_023'? Czy ich nie udokumentowałem? Których z nich potrzebuję teraz?”
  • „O tak, ten kod korzysta z podstawy kodu Y. Chyba muszę [ wybierz jedną: skopiować całą bazę kodu Y do nowego projektu / spędzić dzień na wydobywaniu jednej funkcji, którą chcę z Podstawy kodu Y / spędzić tydzień na wydobywaniu potrzebna mi jedna funkcja z Code Base Y]. "
  • „Skopiowałem wszystko, tak!”
  • "Dlaczego to nie działa?"
  • To jest punkt, w którym spędzasz godziny / dni / tygodnie debugując istniejący kod, który jest podobny do tego, co chcesz, zamiast pisać kod, od którego faktycznie chcesz zacząć.

Podsumowując, istniejący kod, którego nie można użyć bezpośrednio, może w najlepszym przypadku służyć jako dobre odniesienie do pisania podobnego kodu. Z pewnością nie da się go podnieść w całości i oczekiwać, że będzie działał w zupełnie innym systemie. Ogólnie rzecz biorąc, jest to bezpieczne założenie, że każdy kod, który został napisany i ukończony, powinien zostać wprowadzony jak najmniejszym bałaganem - nawet jeśli jest to kopia, a nie sam oryginał.

Jeśli chcesz oprzeć swój projekt na kopiowaniu i wklejaniu, musisz zacząć od kodu w sposób, który umożliwi łatwe ponowne użycie, bez kopiowania oryginalnego kodu i majstrowania przy nim. Warto to zrobić, a jeśli tego oczekuje twój szef, to oboje musicie się upewnić, że właśnie w ten sposób projektujesz i pracujesz.

Ziv
źródło
9

kopiowanie i wklejanie to katastrofa, która czeka. Twój szef powinien wcześnie oszacować cenę wysyłki w odniesieniu do ceny za niedługo uszkodzony kod wysłany do użytkownika końcowego.

Stefano Borini
źródło
9

Jeśli masz już zaimplementowane funkcje i musisz je skopiować i wkleić, aby użyć ich ponownie, wygląda na to, że zrobiłeś coś złego. Nie możesz umieścić tych funkcji w bibliotece, aby móc ich ponownie używać bez kopiowania / wklejania?

Brian Rasmussen
źródło
8

Zasada DRY (Don't Repeat Yourself): DRY na Wikipedii .

„Każda część wiedzy musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie”.

inny link .

Gauthier
źródło
To tak, jakby powiedzieć „nigdy nie wkładaj noża do gardła mężczyzny”, co brzmi jak bardzo dobra zasada. Do czasu, gdy zdasz sobie sprawę, że lekarz MUSI złamać tę zasadę, aby wykonać trachiotomię, aby uratować życie mężczyzny (jeśli nie może oddychać, być może z powodu anafilaksji, skrajnej reakcji alergicznej). Każda reguła ma wyjątek (być może z wyjątkiem tej - że każda reguła ma wyjątek). Dlatego każda reguła musi zawierać „dlaczego” i „kiedy” oraz listę wyjątków, wszystkie dołączone, aby prawdziwa „inżynieryjna” rzeczywistość była taka, że ​​prawdziwa odpowiedź jest taka ...
MicroservicesOnDDD
Więc ... kiedy NIE podążasz za DRY? Ciągle zmagam się z tym w mojej obecnej pracy, która ma związek z oprogramowaniem sprzętowym, a odpowiedź jest taka, że ​​„rozwijamy pętle” i robimy inne rzeczy, ponieważ to „poprawia wydajność”. Mamy bardzo płytką hierarchię dziedziczenia i większość klas używamy bezpośrednio, zamiast tworzyć podklasy, i ... ... często używamy kopiowania i wklejania. I nienawidzę tego, ponieważ sprawia, że ​​nasza baza kodu jest trudniejsza do zrozumienia i trudniejsza w utrzymaniu. Ale mamy swoje powody i są to powody do przyjęcia. Nie jesteśmy jedynymi interesariuszami. A znalezienie odpowiedniej równowagi to raczej sztuka.
MicroservicesOnDDD
7

Wydaje mi się, że najgorszym błędnym przekonaniem, jakie ma twój nietechniczny szef, jest to, że twoja praca polega głównie na pisaniu na maszynie. Uważają, że możesz zaoszczędzić dużo czasu, eliminując pisanie.

Myślę, że najlepszą edukacją, jaką możesz dać tej osobie, jest wskazanie całej pracy, którą wykonujesz, a nie pisanie na maszynie. Nawet jeśli większość tej pracy zwykle dzieje się niewidocznie, w Twojej głowie, w tym samym czasie, co pisanie.

Jasne, wyeliminowanie wpisywania pozwoli zaoszczędzić trochę czasu. Ale wtedy znacznie większa część pracy, która nie polega na pisaniu na maszynie, staje się większa i pochłania każdą oszczędność czasu i nie tylko.

Jaskółka oknówka
źródło
4

Czy na pewno Twój szef chce usłyszeć o zasadzie DRY, błędach i innych sprawach technicznych?

Tego rodzaju uwagi zwykle słyszysz, gdy Twój szef lub firma nie docenili czasu potrzebnego na ukończenie jakiegoś projektu. W oparciu o błędne oszacowanie podpisano umowę itp. W większości przypadków programiści nie brali udziału w szacowaniu.

Dlaczego tak się dzieje? Czasami sponsor projektu ma zbyt mały budżet. Może proces biznesowy, który automatyzujesz za pomocą oprogramowania, nie jest wart wysiłku Twojego zespołu. W takich przypadkach menedżerowie są zazwyczaj bardzo zamknięci na złe wieści. Na początku projektu jest myślenie życzeniowe. Następnie menedżerowie próbują winić programistów. W twoim przypadku pośrednio poprzez kopiowanie i wklejanie. W skrajnych przypadkach nazywa się to marszem śmierci .

Greg Dan
źródło
3

Kopiowanie i wklejanie kodu zwykle prowadzi do programowania przez przypadek

Lucas Ayala
źródło
Uważam, że ten artykuł jest wyjątkowo źle napisany. Narracja pozostaje abstrakcyjna, więc nie rzuca światła na sprawę poza faktem, że Fred pracuje iteracyjnie. Jednym z oczywistych problemów Freda jest to, że nie ma dobrego pojęcia o ogólnej architekturze. Niestety, zdarza się to bardzo często, gdy pracujemy z nieudokumentowanym starym kodem, w którym następuje utrata know-how. Odniesienia do projektowania kontraktowego i programowania asertywnego są całkiem dobre, ale niestety nawet po nich przykłady / ćwiczenia pozostają niewyjaśnione.
mapto
3

Myślę, że kluczowa jest tutaj „ inna aplikacja ”, jeśli inna aplikacja jest już przetestowana i używana, nie należy jej zmieniać aby korzystała ze wspólnej biblioteki, dlatego nie można jej udostępniać kodu.

W ramach tej samej aplikacji „kopiuj i wklej” jest złe, ale pomiędzy bazami kodu opracowanymi przez różne zespoły lub z różnymi cyklami wydawania „kopiuj i wklej” może być najlepszą opcją.

Ian Ringrose
źródło
Chociaż widzę, że publikowanie aktualizacji innej aplikacji tylko po to, aby korzystać z biblioteki, nie ma sensu , prawdopodobnie dobrym pomysłem byłoby przynajmniej wprowadzenie niezbędnych zmian w gałęzi funkcji. Dałoby to pewność, że interfejs biblioteki był wystarczająco ogólny dla co najmniej dwóch aplikacji, o których mowa, i pozwoliłby na scalenie zmiany w odpowiednim momencie cyklu wydawania.
SamB
2

Pracowałem w podobnej firmie. Będąc stażystą nie wiedziałem wtedy lepiej, więc kiedy zaczynałem nowy projekt, mój szef również zasugerował wklejenie kodu z innego miejsca. Cóż, jak może się wydawać, całe oprogramowanie było dość bałagan, do tego stopnia, że ​​kiedy próbowałeś naprawić błąd, pojawiły się dwa nowe błędy.

helpermethod
źródło
2

Nawet jeśli inna aplikacja ma już potrzebną funkcję, kod tej funkcji może po prostu nie pasować do bieżącej aplikacji bez poważnego przepisania. To tak, jakby wziąć silnik forda i spróbować dopasować go do toyoty. Generalnie istnieje praktyczna zasada, że ​​jeśli musisz zmodyfikować więcej niż 25% kopiowanego kodu, lepiej (taniej) jest przepisać go od nowa.

Wyodrębnienie danego kodu do biblioteki brzmi atrakcyjnie, ale może być trudniejsze niż się wydaje, w zależności od tego, jak ten inny system jest zbudowany. Na przykład kod tej funkcji może być trudny do wyodrębnienia, ponieważ łączy on wiele innych kodów w nieczysty sposób (np. Uzyskując dostęp do wielu zmiennych globalnych itp.)

Erich Kitzmueller
źródło
1

Powiedz szefowi, że część nazwy każdej zmiennej zawiera nazwę starego projektu, a teraz musisz zmienić je wszystkie ręcznie. Jeśli twój szef nie wie (lub chce wiedzieć), dlaczego kopiowanie / wklejanie jest złe, równie dobrze może w to uwierzyć :)

Szymon
źródło
1

Tak, największym problemem jest to, że nie jest to tylko kopiowanie i wklejanie - jego kopiowanie, wklejanie, a następnie nieznaczna modyfikacja.

Później, gdy jeden z wklejonych wariantów ma problem, zostaje zmieniony. Później zmieniono inny wariant.

Następnie okazuje się, że wszystkie warianty muszą ulec zmianie, ponieważ oryginalna kopia zawiera błędy. Teraz jesteś dobrze i naprawdę załatwiony, ponieważ wszystkie wklejone obszary nie są teraz takie same.

I czy nie wiedziałbyś o tym, tego rodzaju kiepskie kodowanie jest zwykle prawie całkowicie pozbawione komentarzy.

Dla mnie różnica polega na tym, że kiedy masz wiele kopii kodu wykonujących to samo, to co masz jest kawałkiem kodu. Kiedy masz tylko jeden kawałek kodu wykonujący każdą konkretną rzecz, masz system.

Zachowanie systemu można dość łatwo zmienić za pomocą pojedynczych modyfikacji - zmiana zachowania zestawu kodu wymaga sporej ilości kodu.

Lubię systemy, a nie zbiór kodu.

Rodney P. Barbati
źródło
1

Istnieją kompromisy między szybkością rozwoju natychmiastowej funkcjonalności przed Tobą (zwłaszcza gdy aplikacja jest niewielka) a długoterminowymi kosztami utrzymania w miarę rozwoju aplikacji.

Kopiowanie i wklejanie jest szybsze w przypadku natychmiastowej funkcjonalności, ale będzie Cię drogo kosztować, gdy aplikacja będzie się rozrastać, jeśli chodzi o naprawianie błędów i wprowadzanie zmian w całym systemie oraz utrzymywanie przepływów pracy między różnymi komponentami aplikacji.

To jest argument, który właściciele firm powinni usłyszeć. Jest to podobne do akceptowanych kosztów utrzymania floty pojazdów, jednak w przypadku oprogramowania zepsute aspekty architektury oprogramowania są generalnie ukryte po stronie biznesowej i mogą być widoczne tylko przez programistów.

user2686692
źródło
0

Ma rację, że jeśli zespół wdrożył wcześniej podobną funkcjonalność, powtórzenia tego będzie dużo łatwiejsze za drugim razem.

Jednak prawdopodobnie powinieneś wyjaśnić, że każda aplikacja jest inna. Tylko dlatego, że zainstalowałeś drzwi w jednym domu, nie oznacza, że ​​możesz zainstalować kolejne drzwi w innym domu w krótkim czasie - będziesz szybszy dzięki doświadczeniu (liczba zainstalowanych drzwi), ale nadal zajmie trochę czasu, aby uzyskać sprzęt zamontuj drzwi, upewnij się, że są pionowe i przykręć je do ramy.

bobobobo
źródło
0

w mojej firmie zawsze pracujemy z klasami i metodami oraz wykonujemy dla nich dokumentację techniczną. Myślę, że to najlepsza praktyka, jeśli możesz użyć własnych aplikacji wyszukiwania svn z dobrymi kluczami, aby znaleźć klasę metody używaną wcześniej :)

Sebastian 506563
źródło