Hoe begin je als ontwikkelaar aan een nieuw project…??

Eerst verzamelt u enkele basisvereisten en vervolgens begint u op basis van de vereiste de functie één voor één te implementeren. Naarmate u verder komt met uw project en er meer over leert, blijft u de code in uw codebase toevoegen en wijzigen. Later verander je ook de code om de bug- en randgevallen op te lossen.

Maar wat gebeurt er na een paar dagen of maanden…? Hoe ziet uw code eruit...?? Is het ingewikkeld? Is het moeilijk te begrijpen? Zo ja, dan heeft u zeker geen aandacht besteed aan het verbeteren van uw code of het herstructureren van uw code. Mogelijk hebt u dubbele code geschreven zonder naar de bestaande code te kijken, of heeft u mogelijk langere methoden/functies, grote klassen, te veel parameters, niet-intuïtieve variabelennamen, codeplaatsing, enz. geschreven.

Het verbeteren of bijwerken van de code zonder de functionaliteit van de software of het externe gedrag van de applicatie te veranderen, staat bekend als code-refactoring. Het verlaagt de technische kosten en maakt de code efficiënter en onderhoudbaarder. Als u niet eerder aandacht besteedt aan het refactoringproces van de code, betaalt u later voor fouten in uw code. Negeer dus niet het opschonen van de code.

In een softwareontwikkelingsproces hebben verschillende ontwikkelaars verschillende schrijfstijlen voor code. Ze brengen wijzigingen aan, onderhouden de code, breiden de code uit en meestal verlaten ze de code zonder voortdurende refactoring. Niet-gerefactoreerde code heeft de neiging dat wel te doen code rot: veel van verwarring en rommel in de code, zoals dubbele code, ongezonde afhankelijkheden tussen klassen of pakketten, slechte toewijzing van klassenverantwoordelijkheden, te veel verantwoordelijkheden per methode of klasse, enz. Om al deze problemen te voorkomen, is continue refactoring belangrijk.

Nu is de vraag… Wat zijn de technieken om de code te refactoren?

We zullen enkele populaire en veelgebruikte technieken bespreken om de code te herstructureren, maar laten we eerst enkele snelle tips bespreken...

Tips:

• U moet coderefactoring in kleine stappen uitvoeren. Breng kleine wijzigingen aan in uw programma, elk van de kleine wijzigingen maakt uw code iets beter en laat de applicatie in werkende staat.
• Voer de test TDD en CI uit nadat u kleine wijzigingen in het refactoringproces hebt aangebracht. Als u deze tests niet uitvoert, loopt u het risico dat er bugs worden geïntroduceerd.
• Creëer geen nieuwe functies of functionaliteit tijdens het refactoringproces. U moet de code herstructureren voordat u updates of nieuwe functies aan uw bestaande code toevoegt.
• Het refactoringproces kan de testresultaten beïnvloeden, dus het is goed om uw QA- en testteam bij het refactoringproces te betrekken.
• U moet accepteren dat u niet volledig tevreden zult zijn met uw code. Uw geherstructureerde code zal in de nabije toekomst verouderd zijn en u zult deze opnieuw moeten herstructureren.

Meest voorkomende technieken voor coderefactoring

Er zijn veel benaderingen en technieken om de code te refactoren. Laten we enkele populaire bespreken…

1. Rood-groen refactoring

Rood-Groen is de meest populaire en meest gebruikte code-refactoring-techniek in het Agile-softwareontwikkelingsproces. Deze techniek volgt de test-first benadering van ontwerp en implementatie, dit legt de basis voor alle vormen van refactoring. Ontwikkelaars nemen het initiatief voor de refactoring in de testgestuurde ontwikkelingscyclus en deze wordt uitgevoerd in de drie districtstappen.

• ROOD: De eerste stap begint met het schrijven van de falende roodtest. Je stopt en kijkt wat er ontwikkeld moet worden.
• Groente: In de tweede stap schrijft u de eenvoudigste code en krijgt u de ontwikkelingspas voor groene tests.
• Refactoring: In de laatste en derde stap concentreert u zich op het verbeteren en uitbreiden van uw code, zodat uw test groen blijft.

Dus eigenlijk bestaat deze techniek uit twee afzonderlijke delen: het eerste deel omvat het schrijven van code die een nieuwe functie aan uw systeem toevoegt, en het tweede deel gaat over het refactoren van de code die deze functie vervult. Houd er rekening mee dat het niet de bedoeling is dat u beide tegelijk doet tijdens de workflow.

2. Refactoring door abstractie

Deze techniek wordt meestal gebruikt door ontwikkelaars wanneer er een grote hoeveelheid refactoring nodig is. We gebruiken deze techniek voornamelijk om de redundantie (duplicatie) in onze code te verminderen. Dit omvat klassenovererving, hiërarchie, het creëren van nieuwe klassen en interfaces, extractie, het vervangen van overerving door de delegatie, en vice versa.

Optrekken / neerdrukken methode is het beste voorbeeld van deze aanpak.

• Pull-Up-methode: Het trekt codedelen in een superklasse en helpt bij het elimineren van codeduplicatie.
• Push-Down-methode: Het neemt het codegedeelte van een superklasse en verplaatst het naar beneden in de subklassen.

Haal de constructorbody op, extraheer subklasse, extraheer superklasse, vouw hiërarchie samen, formuliersjabloonmethode, extraheer interface, vervang overerving door de delegatie, vervang delegatie door overerving, duw het veld naar beneden, dit zijn allemaal andere voorbeelden.

Kortom, bij deze techniek bouwen we de abstractielaag voor die delen van het systeem die opnieuw moeten worden bewerkt en de tegenhanger die dit uiteindelijk gaat vervangen. Hieronder worden twee veelvoorkomende voorbeelden gegeven...

vetgedrukte tekst css

• Ingekapseld veld: We dwingen de code toegang te krijgen tot het veld met getter- en setter-methoden.
• Generaliseer type: We creëren meer algemene typen om het delen van code mogelijk te maken, vervangen typecontrolecode door de staat, vervangen voorwaardelijk door polymorfisme, enz.

3. Componeermethode

Tijdens de ontwikkelingsfase van een applicatie schrijven we vaak lange methoden in ons programma. Deze lange methoden maken uw code uiterst moeilijk te begrijpen en moeilijk te veranderen. In deze gevallen wordt meestal de compositiemethode gebruikt.

Bij deze aanpak gebruiken we gestroomlijnde methoden om duplicatie in onze code te verminderen. Enkele voorbeelden zijn: methode extraheren, een variabele extraheren, inline Temp, Temp vervangen door Query, inline-methode, tijdelijke variabele splitsen, toewijzingen aan parameters verwijderen, enz.

Extractie: We verdelen de code in kleinere stukjes om fragmentatie te vinden en te extraheren. Daarna maken we afzonderlijke methoden voor deze segmenten, en vervolgens wordt deze vervangen door een aanroep van deze nieuwe methode. Bij extractie zijn klasse-, interface- en lokale variabelen betrokken.

In lijn: Deze aanpak verwijdert het aantal onnodige methoden in ons programma. We vinden alle aanroepen van de methoden en vervangen ze allemaal door de inhoud van de methode. Daarna verwijderen we de methode uit ons programma.

tekenreeks toevoegen

4. Vereenvoudigende methoden

Er zijn twee technieken betrokken bij deze aanpak... laten we ze allebei bespreken.

• Vereenvoudiging van voorwaardelijke expressies Refactoring: Voorwaardelijke verklaring bij programmeren wordt in de loop van de tijd logischer en ingewikkelder. U moet de logica in uw code vereenvoudigen om het hele programma te begrijpen.
  Er zijn zoveel manieren om de code te herstructureren en de logica te vereenvoudigen. Sommigen daarvan zijn: voorwaardelijke expressie consolideren en voorwaardelijke fragmenten dupliceren, voorwaardelijk ontbinden, voorwaardelijk vervangen door polymorfisme, controlevlag verwijderen, geneste voorwaardelijk vervangen door bewakingsclausules, enz.
• Vereenvoudiging van methodeaanroepen Refactoring: Met deze aanpak maken we methodeaanroepen eenvoudiger en begrijpelijker. We werken aan de interactie tussen klassen en vereenvoudigen de interfaces ervoor.
  Voorbeelden zijn: het toevoegen, verwijderen en introduceren van nieuwe parameters, het vervangen van de parameter door de expliciete methode en methodeaanroep, het parametriseren van de methode, het maken van een aparte query van de modifier, het behouden van het hele object, het verwijderen van de instellingsmethode, enz.

5. Objecten tussen objecten verplaatsen

Bij deze techniek creëren we nieuwe klassen en verplaatsen we de functionaliteit veilig tussen oude en nieuwe klassen. We verbergen de implementatiedetails voor publieke toegang.

De vraag is nu... wanneer moet de functionaliteit tussen klassen worden verplaatst of hoe kan worden vastgesteld dat het tijd is om de functies tussen klassen te verplaatsen?

Wanneer u merkt dat een klasse zoveel verantwoordelijkheden heeft en er te veel gebeurt, of wanneer u merkt dat een klasse onnodig is en niets doet in een toepassing, kunt u de code van deze klasse naar een andere klasse verplaatsen en deze helemaal verwijderen.

Voorbeelden zijn: een veld verplaatsen, klasse extraheren, methode verplaatsen, inline klasse, delegatie verbergen, een buitenlandse methode introduceren, tussenpersoon verwijderen, lokale extensie introduceren, enz.

6. Voorbereidende refactoring

Deze aanpak kunt u het beste gebruiken als u merkt dat er behoefte is aan refactoring terwijl u nieuwe functies aan een toepassing toevoegt. Het is dus eigenlijk een onderdeel van een software-update met een afzonderlijk refactoringproces. U bespaart uzelf met toekomstige technische schulden als u merkt dat de code moet worden bijgewerkt tijdens de eerdere fasen van de functieontwikkeling.

De eindgebruiker kan dergelijke inspanningen van het technische team niet met eigen ogen zien, maar de ontwikkelaars die aan de applicatie werken, zullen de waarde inzien van het refactoren van de code tijdens het bouwen van de applicatie. Ze kunnen tijd, geld en andere middelen besparen als ze gewoon wat tijd besteden aan het eerder bijwerken van de code.

Het is alsof ik 160 kilometer naar het oosten wil, maar in plaats van alleen maar door het bos te slenteren, ga ik 32 kilometer naar het noorden rijden naar de snelweg en dan ga ik 160 kilometer naar het oosten met drie keer de snelheid die ik zou kunnen hebben als Ik ben er gewoon meteen naartoe gegaan. Als mensen je onder druk zetten om daar gewoon rechtdoor te gaan, moet je soms zeggen: ‘Wacht, ik moet op de kaart kijken en de snelste route vinden.’ Dat doet de voorbereidende refactoring voor mij.

Jessica Kerr (Software ontwikkelaar)

7. Refactoring van de gebruikersinterface

U kunt eenvoudige wijzigingen aanbrengen in de gebruikersinterface en de code refactoren. Bijvoorbeeld: lijn het invoerveld uit, pas het lettertype toe, herformuleer met actieve stem, geef het formaat aan, pas de algemene knopgrootte toe en verhoog het kleurcontrast, enz.

Laatste woorden

U moet het coderefactoringproces beschouwen als het opruimen van het ordelijke huis. Onnodige rommel in huis kan een chaotische en stressvolle omgeving creëren. Hetzelfde geldt voor geschreven code. Een schone en overzichtelijke code is altijd gemakkelijk te veranderen, gemakkelijk te begrijpen en gemakkelijk te onderhouden. U zult later geen problemen ondervinden als u eerder aandacht besteedt aan het refactoringproces van de code.

Twee van de meest invloedrijke softwareontwikkelaars Martin Fowler En Kent Beck hebben hun tijd besteed aan het uitleggen van het code-refactoring-proces en de technieken ervan. Ze hebben ook een compleet boek over dit onderwerp geschreven Refactoring: verbetering van het ontwerp van bestaande code . Dit boek beschrijft verschillende refactoringtechnieken met een duidelijke uitleg van het werken aan dit refactoringproces. We raden u aan dit boek te lezen als u dieper wilt ingaan op het proces van coderefactoring.