Waarom is “kopiëren en plakken” van code gevaarlijk?

Soms klaagt mijn baas bij ons:

Waarom duurt het zo lang om een ​​functie te implementeren?

Eigenlijk is de functie al eerder in een andere toepassing geïmplementeerd, u hoeft alleen maar codes van daaruit te kopiëren en te plakken. De kosten zouden laag moeten zijn.

Het is echt een moeilijke vraag, omdat het kopiëren en plakken van codes in mijn ogen niet zo eenvoudig is.

Heb je goede redenen om dit uit te leggen aan je niet-technische baas?

Antwoord 1, autoriteit 100%

Als u een fout in uw kopieer-plakcode vindt, moet u deze overal repareren en hopen dat u ze allemaal kunt onthouden (dit geldt ook voor gewijzigde vereisten).

Als je logica op één plek bewaart, is het gemakkelijker om te veranderen wanneer dat nodig is (dus als je besluit dat de applicatie moet worden bijgewerkt, doe je dat maar op één plek).

Laat je baas lezen over het DRY-principe(Do not Repeat Yourself).

Wat u beschrijft, klinkt als het perfecte gebruik voor bibliotheken, waar u code deelt en deze slechts op één plaats bewaart.

Ik zou alleen code kopiëren en plakken als ik van plan was om het kort daarna te refactoren– en ervoor te zorgen dat ik later de algemene code uitpakte, zodat ik zoveel mogelijk logica kon hergebruiken. En met kort daarna bedoel ik minuten en uren later, niet dagen en weken.

Antwoord 2, autoriteit 14%

Je kunt de code veel beter delendoor een bibliotheek te bouwen in plaats van de code te kopiërendoor middel van kopiëren en plakken.

Je krijgt nog steeds een snelheidsvoordeel ten opzichte van herschrijven (zoek DRY op), maar je hebt maar één plek om de code te onderhouden.

Antwoord 3, autoriteit 7%

De voor de hand liggende reden is dat je een ‘schuld’ aangaat voor de toekomst: elke wijziging die je ooit in de code moet maken (niet alleen bugfixes, elke wijziging) zal nu twee keer zo duur zijn omdat je moet updaten twee plaatsen – en riskanter omdat je er uiteindelijk één ZULT vergeten. Met andere woorden, als u het nu sneller laat werken, wordt uw werk in de toekomst nog langzamer, wat kangoed zakelijk zijn, maar meestal niet.

Maar de belangrijkste reden is dat de aanname “dit is hetzelfde als dat” vaker wel dan niet subtiel verkeerd is. Wanneer uw code afhankelijk is van onuitgesproken aannames om correct te zijn, leidt het kopiëren naar een andere plaats tot fouten, tenzij deze aannames ook gelden op de nieuwe plaats. Daarom is de geplakte code vaak vanaf het begin verkeerd en niet pas na de volgende wijziging.

Antwoord 4, autoriteit 6%

Wat het ontwerp betreft, is gekopieerde code zeker een ramp, met het potentieel om in de toekomst veel problemen te veroorzaken. Maar je vraagt ​​je af waarom het je op dit momentzoveel werk kost, het antwoord is: omdat het nooit alleen maar kopiëren en plakken is.

Als de originele code is geschreven om opnieuw te worden gebruikt, als een redelijk onafhankelijke bibliotheek, met flexibiliteit en gebruik door de klant in gedachten, dan is dat prima, maar dat is geen kopiëren en plakken, dat is een codebibliotheek gebruiken. Echte code kopiëren en plakken gaat meestal meer als volgt:

• “Natuurlijk, ik heb al code die precies dat doet!”
• “Wacht, welke van deze vijf versies van code wil ik als bron gebruiken?”
• “Hmmm, wat doen al deze ‘util_func_023’-functies? Heb ik ze niet gedocumenteerd? Welke heb ik nu nodig?”
• “O ja, deze code gebruikt Code Base Y. Ik denk dat ik [een keuze moet maken:heel Code Base Y naar mijn nieuwe project kopiëren / een dag besteden aan het één functie die ik wil van Code Base Y / besteed een week aan het bevrijden van de enige functie die ik wil van Code Base Y].”
• “Ik heb alles gekopieerd, yay!”
• “Waarom werkt dit niet?”
• Dit is het punt waarop u uren/dagen/weken besteedt aan het debuggen van bestaande code die lijkt op wat u wilt, in plaats van de code te schrijven waarmee u eigenlijk wilt beginnen.

Kortom, bestaande code die niet direct kan worden gebruikt, kan op zijn best dienen als een goede referentie voor het schrijven van vergelijkbare code. Het kan zeker niet in zijn geheel worden opgetild en naar verwachting in een heel ander systeem werken. Over het algemeen is het een veilige veronderstelling dat er met elke code die is geschreven en voltooid, zo min mogelijk moet worden geknoeid – zelfs als het een kopie is en niet het origineel zelf.

Als u uw project wilt baseren op kopiëren en plakken, moet u om te beginnencoderen op een manier die gemakkelijk hergebruik mogelijk maakt, zonderdat te kopiëren originele code en rommelen ermee. Dat is de moeite waard om te doen, en als dat is wat je baas verwacht, dan moeten jullie er allebei voor zorgen dat dat is hoe je ontwerpt en werkt in de eerste plaats.

Antwoord 5, autoriteit 5%

kopiëren en plakken is een ramp die staat te gebeuren. Je baas zou de prijs van verzending vroeg moeten beoordelen met betrekking tot de prijs van het snel naar de eindgebruiker laten verzenden van gebroken code.

Antwoord 6, autoriteit 5%

Als je de functies al hebt geïmplementeerd en je moetkopiëren en plakken om ze opnieuw te gebruiken, klinkt het alsof je iets verkeerd hebt gedaan. Kun je deze functies niet in een bibliotheek plaatsen, zodat je ze opnieuw kunt gebruiken zonder te kopiëren/plakken?

Antwoord 7, autoriteit 5%

Het DRY-principe (Don’t Repeat Yourself):
DROGEN op wikipedia.

“Elk stukje kennis moet een enkele, ondubbelzinnige, gezaghebbende representatie hebben binnen een systeem.”

andere link.

Antwoord 8, autoriteit 4%

Het klinkt voor mij als de ergste misvatting die je niet-technische baas heeft, is dat je baan voornamelijk uit typen bestaat. Ze denken dat je veel tijd kunt besparen door typen te elimineren.

Ik denk dat de beste opleiding die u deze persoon kunt geven, is om u te wijzen op al het werk dat u doet dat niet is typen. Ook al gebeurt het meeste van dat werk meestal onzichtbaar, in je hoofd, terwijl je typt.

Natuurlijk, het elimineren van het typen zal wat tijd besparen. Maar dan wordt het veel grotere, niet typende, deel van je werk groter en kost het tijdwinst en nog veel meer.

Antwoord 9, autoriteit 2%

Weet je zeker dat je baas wil horen over het DRY-principe, bugs en andere technische dingen?

Dat soort opmerkingen hoor je meestal als je baas of bedrijf de tijd die nodig is om een ​​project af te ronden te onderschatten. En op basis van een verkeerde schatting werd een contract getekend, enz. In de meeste gevallen werden programmeurs niet betrokken bij schattingen.

Waarom gebeurt dit? Soms heeft een projectsponsor een te klein budget. Misschien is een bedrijfsproces dat u met software automatiseert uw teaminspanning niet waard. Managers zijn in dergelijke gevallen over het algemeen erg gesloten voor slecht nieuws. Aan het begin van het project is er sprake van wishful thinking. Dan proberen managers de programmeurs de schuld te geven. In jouw geval indirect via kopiëren en plakken. In extreme gevallen wordt dit een dodenmarsgenoemd.

Antwoord 10, autoriteit 2%

Het kopiëren en plakken van code leidt meestal tot Programmeren door toeval

Antwoord 11, autoriteit 2%

Ik denk dat “een andere toepassing” hier de sleutel is, als de andere toepassing al is getest en in gebruik is, moet deze niet worden gewijzigdom een ​​gemeenschappelijke bibliotheek te gebruiken, daarom je kunt er geen code mee delen.

Binnen de dezelfde applicatieis “kopiëren en plakken” slecht, maar tussen codebases die zijn ontwikkeld door verschillende teams of met verschillende releasecycli kan “kopiëren en plakken” de beste optie zijn.

Antwoord 12

Ik heb voor een soortgelijk bedrijf gewerkt. Als stagiair wist ik toen niet beter, dus toen ik aan een nieuw project begon, stelde mijn baas ook voor om de code ergens anders te plakken. Nou, zoals je misschien denkt, was de hele software nogal een puinhoop, tot het punt dat toen je probeerde een bug te repareren, er twee nieuwe bugs verschenen.

Antwoord 13

Zelfs als de andere toepassing al de functie heeft die u nodig hebt, kan de code voor die functie eenvoudigweg niet in uw huidige toepassing passen zonder een grote herschrijving. Het is alsof je de motor van een Ford neemt en probeert het in een Toyota te passen. Over het algemeen is er een vuistregel die als u meer dan 25% van de code die u kopieert, beter (goedkoper) moet wijzigen om het helemaal opnieuw te herschrijven.

De betreffende code uitpakken in een Bibliotheekgeluid die overtuigend is, maar het is misschien moeilijker dan het klinkt, afhankelijk van hoe dat andere systeem is gebouwd. B.v. De code voor die functie kan moeilijk zijn om te extraheren omdat deze veel andere code in onreine manieren bevat (bijvoorbeeld door toegang te krijgen tot veel globale variabelen enz.)

14

Ja, het grootste probleem is dat het niet alleen kopieert en plakt – het kopiëren en plakken dan enigszins wijzigen.

later wanneer een van de geplakte varianten een probleem heeft, wordt het veranderd. Vervolgens wordt een andere variant gewijzigd.

Dan ontdek je dat alle varianten moeten veranderen, want de originele kopie had bugs. Nu ben je goed en echt geschroefd omdat alle geplakte gebieden nu niet hetzelfde zijn.

en zou je het niet weten, dit soort waardeloze codering is meestal bijna volledig ongeldig van opmerkingen.

Naar mij is het verschil dat wanneer u meerdere exemplaren van de code hetzelfde doet, wat u heeft, wat u hebt is een stel code. Als je maar één stuk code hebt, doe je elk specifiek, dan heb je een systeem.

Gedrag van een systeem kan worden gewijzigd met modificaties van één punt vrij eenvoudig – het gedrag van een stel code veranderen vereist een heleboel code.

Ik hou van systemen, geen stel code.

15

Er zijn trade-offs tussen de snelheid van de ontwikkeling van de directe functionaliteit voor u (vooral wanneer de toepassing klein is), en onderhoudskosten op langere termijn als de toepassing groeit.

Kopiëren en plakken is sneller voor de directe functionaliteit, maar kost u in het bijzonder omdat de toepassing in omvang groeit, in termen van bevestigingsbugs en het maken van systeembrede wijzigingen en het handhaven van de werkstromen tussen verschillende componenten van de toepassing.

Dat is het argument dat bedrijfseigenaren moeten horen. Het is vergelijkbaar met de aanvaarde kosten van het handhaven van een vloot van voertuigen, maar met software zijn de kapotte aspecten van de softwarearchitectuur over het algemeen verborgen voor de businesszijde en kunnen alleen door ontwikkelaars worden gezien.

16

Hij is goed dat als het team eerder vergelijkbare functionaliteit heeft geïmplementeerd, het herhalen van het veel gemakkelijker de 2e keer is.

U moet echter waarschijnlijk uitleggen dat elke toepassing anders is. Alleen omdat je een deur in één huis hebt geïnstalleerd, wil nog niet zeggen dat je een andere deur in een ander huis kunt installeren in Geen tijd plat – je zult sneller zijn vanwege de ervaring (# deuren geïnstalleerd), maar het zal Neem nog steeds de tijd om je apparatuur te krijgen, de deur te monteren, zorg ervoor dat het loodgliet is en het in het frame in het frame schroeven.

17

In mijn bedrijf werken we altijd met klassen en methoden en maken we technische documentatie voor hen. Ik denk dat het de beste praktijken is als u uw eigen SVN-zoekadvertenties kunt gebruiken met goede sleutels om de methode-klasse te vinden die eerder wordt gebruikt 🙂