Omstrukturering af software

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 25. september 2015; checks kræver 5 redigeringer .

Software reengineering er processen med at skabe ny funktionalitet eller rette fejl ved at foretage en revolutionerende ændring, men ved at bruge software,  der allerede er i brug . Reengineeringsprocessen er beskrevet af Chikowski og Cross i deres 1990 papir, [1] som "Undersøgelsen og ændringen af ​​et system for at rekonstituere det i en ny form". I mindre formelle termer er reengineering modifikation af et softwaresystem, efter at det er blevet omvendt manipuleret .

Kompleksiteten af ​​reengineering

Som regel hedder det, at "det er nemmere at udvikle et nyt softwareprodukt". Dette skyldes følgende problemer:

  1. reengineering er oftest dyrere end at udvikle ny software , da det er nødvendigt at fjerne begrænsningerne i tidligere versioner, samtidig med at kompatibiliteten med dem bevares ;
  2. reengineering kan ikke udføres af en programmør med lave og mellemstore kvalifikationer - selv fagfolk kan ofte ikke implementere det på en kvalitetsmåde, derfor kræves arbejdet fra programmører med stor erfaring i omarbejdning af programmer og viden om forskellige teknologier[ angiv ] ;
  3. det kan være svært for en udvikler at forstå en andens kildekode  - dette tvinger dem til at tilpasse sig opfattelsen af ​​en ukendt programmeringsstil , bruger tid på en omfattende analyse og mestring af koncepterne implementeret i projektet, tredjepartsbiblioteker brugt i det , kræver omhyggeligt at udforske funktionsprincippet for alle dårligt dokumenterede kodeafsnit - og alt dette komplicerer kun processen med produktovergang til nye arkitektoniske løsninger ;
  4. derudover kræver selve aktivitetens karakter yderligere motivation : sammenlignet med skabelsen af ​​nye produkter giver behandlingen af ​​eksisterende ikke altid de samme visuelle og imponerende resultater, tynger ofte byrden af ​​teknisk gæld og efterlader lidt plads til professionel selvudfoldelse.

På samme tid, hvis programmet oprindeligt havde en stram og klar arkitektur, så vil reengineering være en størrelsesorden lettere. Derfor, når man designer, analyseres det som regel, hvad der vil være mere rentabelt - at begynde at behandle materialerne fra det tidligere projekt eller at udvikle et lignende softwareprodukt fra bunden.

Se også

Noter

  1. ↑ Chikofsky, E. og Cross, J. 7(1) // = Reverse Engineering and Design Recovery: A Taxonomy. - IEEE Software, 1990. - S. 13-18.

Links