Opětovné použití kódu ( anglicky code reuse ) je metodika pro navrhování počítačových a jiných systémů, která spočívá v tom, že systém ( počítačový program , programový modul) by měl být částečně nebo zcela složen z částí, dříve napsaných komponent a/nebo částí jiného systému. systému a tyto komponenty je nutné použít vícekrát (pokud ne v rámci stejného projektu, tak alespoň různé). Opětovné použití je hlavní metodika, která se používá ke snížení mzdových nákladů při vývoji složitých systémů.
Nejběžnějším případem opětovného použití kódu jsou softwarové knihovny . Knihovny poskytují běžnou, poměrně univerzální funkcionalitu, která pokrývá vybranou oblast. Příklady: knihovna funkcí pro práci s komplexními čísly, knihovna funkcí pro práci s 3D grafikou, knihovna pro použití protokolu TCP / IP, knihovna pro práci s databázemi. Vývojáři nového programu mohou využít stávající knihovny k řešení svých problémů a ne „znovu objevovat kolo“.
Programátoři mají tendenci navrhovat své systémy tak, aby byly co nejvíce modulární. Jako abstrakce, na jejichž základě je možné budovat modularitu systému, mohou působit funkce , korutina , třída , protokol . Knihovna funkcí je dobrým příkladem abstrakce , která je užitečná pro implementaci modularity programu a následování opakovaně použitelné metodologie. Důležitým krokem k dosažení maximální modularity byl princip hierarchické konstrukce jmenného prostoru .
Příkladem úspěšné implementace modularity a principu opětovného použití jsou unixové shell nástroje a standardní Java třídy umístěné v hierarchii jmenného prostoru.
Šablony (viz C++ Standard Template Library STL ) pro funkce a třídy byly důležitým krokem v pokroku metodologie opětovného použití v průmyslově orientovaném programování .
Hierarchická modularita systému umožňuje implementovat efektivní metody řízení vývoje založené na konstrukci řídicích hierarchií odpovídajících hierarchii modulů samotného systému.
Někdy je opětovné použití kódu jednoduše zkopírováním nějakého kusu kódu z existujícího programu do jiného ( copy-paste ) . Toto je jeden z nejvíce nízkoúrovňových přístupů k opětovnému použití. Ale také se to děje, zejména pokud jde o opětovné použití kódu „v malém“ („opětovné použití v malém“).
Tento přístup se obvykle nedoporučuje používat, místo toho je opakující se fragment programu formátován jako podprogram nebo makro se sadou parametrů. Hlavním argumentem ve prospěch použití podprogramů namísto kopírování kódu je, že pokud dojde k chybě, musí být jednou opravena v těle podprogramu, jinak obecně musí být několik stejných fragmentů kódu umístěných na různých místech programu být opraven. Navíc při kopírování kódu většinou vzniká potřeba měnit názvy proměnných, což také často vede k mechanickým chybám. V případě použití podprogramů se lze takovému přejmenování vyhnout použitím lokálních proměnných.
Metoda opětovného použití kódu je důležitou součástí implementace principu metasystémového přechodu ve vývoji softwarového průmyslu. Implementace tohoto principu umožňuje vývojářům pracovat s koncepty na vysoké úrovni (zobrazit obrázek, odstranit tabulku z databáze, najít všechny kořeny rovnice, převést soubor atd.), spíše než s koncepty nízké úrovně (barva pixel červený, reset registru, přidání dvou čísel, načtení znaku ze souboru atd.).
Zvažte výhody a nevýhody na příkladu knihoven funkcí.
Používání hotových knihoven má řadu výhod. Za prvé, vývojář nového systému se zbaví starostí s implementací funkcionality vložené do této knihovny. Celý cyklus vývoje knihovny provádí vývojář této knihovny. Obvykle přebírá odpovědnost za údržbu knihovny: opravy chyb, vývoj a zlepšování práce, testování . Metoda opětovného použití kódu je mechanismus, který umožňuje vývojářům „stát na ramenou obrů“ [1] a rychle budovat nové komplexní systémy z již odladěných komponent. Druhou výhodou je samotné opakování používání kódu, což vede k výraznému zmenšení velikosti výsledného programu a v případě nedostatečného mediálního výkonu i k rychlosti.
Kromě několika, ale velmi důležitých výhod, má metoda opětovného použití kódu řadu nevýhod. Připojení knihoven třetích stran k projektu automaticky vede k nutnosti kontrolovat kompatibilitu verzí komponent vytvářeného systému a verzí používaných knihoven. Za nejtypičtější příklad takové chyby je považována nehoda nosné rakety Ariane-5 způsobená použitím softwarového modulu vyvinutého pro raketu Ariane-4 [2] .
Je také důležité poznamenat, že mnoho knihoven je komerčních a vyžaduje peníze (s rozvojem hnutí za svobodný software se to postupně stává méně relevantní). Knihovny navíc často nejsou dostatečně univerzální a neimplementují funkcionalitu, kterou vytvářený systém vyžaduje, nebo jsou naopak příliš univerzální a v důsledku toho jsou neefektivní, nepohodlné nebo obsahují mnoho nadbytečných ( pro daný projekt) funkčnost. Je možné, pokud to licence redistribuovatelné knihovny umožňuje, využívat její zdrojové kódy a upravovat je podle potřeby. Poté se ale zodpovědnost za podporu funkčnosti knihovny přesune na bedra vývojáře nového systému. Také použití nadměrné modularity může vést ke snížení rychlosti provádění programu, když rychlost provádění vlastní modulu nemůže pokrýt náklady na přístup k tomuto modulu.