Kuinka aloitat uuden projektin työskentelyn kehittäjänä…??

Kerää ensin joitain perusvaatimuksia ja sitten vaatimuksen perusteella aloitat ominaisuuden toteuttamisen yksitellen. Kun edistyt projektissasi ja opit siitä lisää, lisäät ja muutat koodia koodikantaasi. Myöhemmin muutat myös koodia virheiden ja reunatapausten korjaamiseksi.

Mutta mitä tapahtuu muutaman päivän tai kuukauden kuluttua…? Miltä koodisi näyttää...?? Onko se monimutkaista? Onko vaikea ymmärtää? Jos kyllä, et ehdottomasti kiinnittänyt huomiota koodin parantamiseen tai koodin uudelleenjärjestelyyn. Olet ehkä kirjoittanut päällekkäisen koodin katsomatta olemassa olevaa koodia tai olet ehkä kirjoittanut pidempiä menetelmiä/funktioita, suuria luokkia, liikaa parametreja, epäintuitiivisia muuttujien nimiä, koodin sijoittelua jne.

Koodin parantaminen tai päivittäminen muuttamatta ohjelmiston toimivuutta tai sovelluksen ulkoista toimintaa kutsutaan koodin uudelleenjärjestelyksi. Se vähentää teknisiä kustannuksia ja tekee koodista tehokkaamman ja ylläpidettävämmän. Jos et kiinnitä huomiota koodin uudelleenmuodostusprosessiin aikaisemmin, maksat koodisi virheistä myöhemmin. Älä siis sivuuta koodin puhdistamista.

Ohjelmistokehitysprosessissa eri kehittäjillä on erilaiset koodin kirjoitustyylit. He tekevät muutoksia, ylläpitävät koodia, laajentavat koodia ja suurimman osan ajasta jättävät koodin ilman jatkuvaa uudelleenkäsittelyä. Refaktoroimaton koodi yleensä koodi rot: paljon koodin sekaannus ja sekavuus, kuten päällekkäinen koodi, epäterveelliset riippuvuudet luokkien tai pakettien välillä, huono luokkavastuiden jako, liian monta vastuuta menetelmää tai luokkaa kohti jne. Kaikkien näiden ongelmien välttämiseksi on tärkeää jatkuva uudelleenmuodostus.

Nyt kysymys kuuluu… mitkä ovat tekniikat koodin refaktorointiin?

Keskustelemme joistakin suosituista ja yleisistä tekniikoista koodin uudelleenmuodostukseen, mutta ennen sitä keskustellaan muutamista nopeista vinkeistä…

Vinkkejä:

• Sinun on suoritettava koodin uudelleenmuodostus pienin askelin. Tee pieniä muutoksia ohjelmaan, jokainen pieni muutos tekee koodistasi hieman paremman ja jättää sovelluksen toimivaan tilaan.
• Suorita testi-TDD ja CI, kun olet tehnyt pieniä muutoksia refaktorointiprosessiin. Jos suoritat näitä testejä, luot virheiden tuomisen riskin.
• Älä luo uusia ominaisuuksia tai toimintoja uudelleenmuodostusprosessin aikana. Sinun tulee muuttaa koodi ennen kuin lisäät päivityksiä tai uusia ominaisuuksia olemassa olevaan koodiisi.
• Refaktorointiprosessi voi vaikuttaa testaustuloksiin, joten on hyvä saada laadunvarmistus- ja testaustiimi mukaan uudelleenfaktorointiprosessiin.
• Sinun on hyväksyttävä, että et ole täysin tyytyväinen koodiisi. Refaktoroitu koodisi on lähitulevaisuudessa vanhentunut, ja sinun on muutettava se uudelleen.

Yleisimmät koodin uudelleenmuodostustekniikat

On olemassa monia lähestymistapoja ja tekniikoita koodin uudelleenmuodostamiseen. Keskustellaan joistakin suosituista…

1. Red-Green Refaktoring

Red-Green on suosituin ja laajimmin käytetty koodin uudelleenmuodostustekniikka ketterissä ohjelmistokehitysprosessissa. Tämä tekniikka noudattaa suunnittelussa ja toteutuksessa testauslähtöistä lähestymistapaa, mikä luo perustan kaikenlaiselle uudelleenkäsittelyn muodolle. Kehittäjät ottavat aloitteen uudelleen huomioon ottamisesta testilähtöiseen kehityssykliin ja se toteutetaan kolmeen piirivaiheeseen.

• PUNAINEN: Ensimmäinen vaihe alkaa epäonnistuneen punaisen testin kirjoittamisella. Pysähdyt ja tarkistat, mitä pitäisi kehittää.
• Vihreä: Toisessa vaiheessa kirjoitat riittävän yksinkertaisin koodin ja hankit kehityspassin vihreän testauksen.
• Refaktori: Viimeisessä ja kolmannessa vaiheessa keskityt parantamaan ja parantamaan koodiasi, jotta testi pysyy vihreänä.

Joten pohjimmiltaan tässä tekniikassa on kaksi erillistä osaa: Ensimmäinen osa sisältää koodin kirjoittamisen, joka lisää järjestelmääsi uuden toiminnon, ja toisessa osassa on kyse tämän toiminnon suorittavan koodin uudelleenmuodostamisesta. Muista, että sinun ei pitäisi tehdä molempia samanaikaisesti työnkulun aikana.

2. Refaktorointi abstraktion avulla

Tätä tekniikkaa käyttävät enimmäkseen kehittäjät, kun on tarpeen tehdä suuri määrä refaktorointia. Käytämme pääasiassa tätä tekniikkaa redundanssin (kaksoistumisen) vähentämiseen koodissamme. Tämä sisältää luokkaperinnön, hierarkian, uusien luokkien ja rajapintojen luomisen, purkamisen, perinnän korvaamisen delegoinnilla ja päinvastoin.

Pull Up/Push-Down menetelmä on paras esimerkki tästä lähestymistavasta.

• Pull-up menetelmä: Se vetää koodiosat superluokkaan ja auttaa poistamaan koodin päällekkäisyyksiä.
• Push-down menetelmä: Se ottaa koodiosan superluokasta ja siirtää sen alaluokkiin.

Vedä rakentajan runko ylös, pura alaluokka, pura superluokka, kutista hierarkia, lomakemallimenetelmä, pura käyttöliittymä, korvaa perinnöllisyys delegoinnilla, korvaa delegointi perinnöllä, paina alas-kenttä kaikki nämä ovat muita esimerkkejä.

Pohjimmiltaan tässä tekniikassa rakennamme abstraktiokerroksen niille järjestelmän osille, jotka on muokattava uudelleen, ja vastineelle, joka lopulta korvaa sen. Alla on kaksi yleistä esimerkkiä…

Mark zuckerbergin koulutus

• Kapseloitu ala: Pakotamme koodin pääsemään kentälle getter- ja setter-menetelmillä.
• Yleistä tyyppi: Luomme yleisempiä tyyppejä sallimaan koodin jakamisen, korvaamme tyypintarkistuskoodin tilalla, korvaamme ehdollisen polymorfismilla jne.

3. Sävellysmenetelmä

Sovelluksen kehitysvaiheessa kirjoitamme monta kertaa pitkiä menetelmiä ohjelmaamme. Nämä pitkät menetelmät tekevät koodistasi erittäin vaikea ymmärtää ja vaikea muuttaa. Näissä tapauksissa käytetään enimmäkseen sävellysmenetelmää.

Tässä lähestymistavassa käytämme virtaviivaistavia menetelmiä vähentääksemme päällekkäisyyksiä koodissamme. Joitakin esimerkkejä ovat: pura menetelmä, poimi muuttuja, inline Temp, korvaa Temp kyselyllä, rivimenetelmä, väliaikainen muuttujan jakaminen, parametrien määrittelyjen poistaminen jne.

Poiminta: Jaamme koodin pienempiin osiin fragmentoitumisen löytämiseksi ja poimimiseksi. Tämän jälkeen luomme erilliset menetelmät näille paloille, ja sitten se korvataan kutsulla tälle uudelle menetelmälle. Poiminta sisältää luokan, käyttöliittymän ja paikalliset muuttujat.

Linjassa: Tämä lähestymistapa poistaa tarpeettomia menetelmiä ohjelmastamme. Etsimme kaikki menetelmien kutsut ja sitten korvaamme ne kaikki menetelmän sisällöllä. Tämän jälkeen poistamme menetelmän ohjelmastamme.

java scan.nextstring

4. Yksinkertaistavat menetelmät

Tähän lähestymistapaan liittyy kaksi tekniikkaa… keskustellaan niistä molemmista.

• Ehdollisten lausekkeiden uudelleenmuodostuksen yksinkertaistaminen: Ehdollinen lause ohjelmoinnissa muuttuu ajan myötä loogisemmaksi ja monimutkaisemmaksi. Sinun on yksinkertaistettava koodisi logiikkaa ymmärtääksesi koko ohjelman.
  On niin monia tapoja muokata koodia ja yksinkertaistaa logiikkaa. Jotkut niistä ovat: konsolidoida ehdollinen lauseke ja monistaa ehdollisia fragmentteja, hajottaa ehdollinen, korvata ehdollinen polymorfismilla, poistaa ohjauslippu, korvata sisäkkäiset ehtolausekkeet suojalauseilla jne.
• Yksinkertaistava menetelmä kutsuu uudelleenfaktorointia: Tällä lähestymistavalla teemme menetelmäkutsuista yksinkertaisempia ja helpompia ymmärtää. Työskentelemme luokkien välisen vuorovaikutuksen parissa ja yksinkertaistamme niiden rajapintoja.
  Esimerkkejä ovat: uusien parametrien lisääminen, poistaminen ja lisääminen, parametrin korvaaminen eksplisiittisellä menetelmällä ja metodikutsulla, parametrointimenetelmä, erillisen kyselyn tekeminen modifieristä, koko objektin säilyttäminen, asetustavan poistaminen jne.

5. Ominaisuuksien siirtäminen objektien välillä

Tällä tekniikalla luomme uusia luokkia ja siirrämme toiminnallisuutta turvallisesti vanhojen ja uusien luokkien välillä. Piilotamme toteutustiedot yleisöltä.

Nyt kysymys kuuluu… milloin toiminnallisuutta siirretään luokkien välillä tai miten tunnistaa, että on aika siirtää ominaisuuksia luokkien välillä?

Kun huomaat, että luokalla on niin paljon vastuita ja liikaa asioita on meneillään tai kun huomaat, että luokka on tarpeeton eikä tee mitään sovelluksessa, voit siirtää koodin tältä luokalta toiselle luokalle ja poistaa sen kokonaan.

Esimerkkejä ovat: siirrä kenttä, poimi luokka, siirrä menetelmä, inline-luokka, piilota delegaatti, ota käyttöön vieras menetelmä, poista välimies, ota käyttöön paikallinen laajennus jne.

6. Valmisteleva refaktorointi

Tätä lähestymistapaa on parasta käyttää, kun huomaat uudelleenjärjestelyn tarpeen lisättäessä joitain uusia ominaisuuksia sovellukseen. Joten periaatteessa se on osa ohjelmistopäivitystä, jossa on erillinen uudelleenjärjestelyprosessi. Säästät itsesi tulevilta teknisiltä veloilta, jos huomaat, että koodi on päivitettävä ominaisuuskehityksen aikaisemmissa vaiheissa.

Loppukäyttäjä ei näe tällaisia ​​insinööritiimin ponnisteluja silmästä silmään, mutta sovelluksen parissa työskentelevät kehittäjät huomaavat koodin uudelleenmuodostamisen arvon sovellusta rakentaessaan. He voivat säästää aikaa, rahaa ja muita resursseja, jos he vain viettävät aikaa koodin päivittämiseen aikaisemmin.

Tuntuu kuin haluaisin mennä 100 mailia itään, mutta sen sijaan että vain kiipeäisin metsässä, aion ajaa 20 mailia pohjoiseen moottoritielle ja sitten mennä 100 mailia itään kolme kertaa nopeammin kuin voisin saada, jos Menin vain suoraan sinne. Kun ihmiset painostavat sinua menemään suoraan sinne, sinun on joskus sanottava: 'Odota, minun on tarkistettava kartta ja löydettävä nopein reitti.' Valmisteleva refaktorointi tekee sen puolestani.

Jessica Kerr (Ohjelmistokehittäjä)

7. Käyttöliittymän uudelleenmuodostus

Voit tehdä yksinkertaisia ​​muutoksia käyttöliittymään ja muuttaa koodin. Esimerkiksi: tasaa syöttökenttä, käytä fonttia, muotoile uudelleen aktiivisella äänellä, ilmaise muoto, käytä yleistä painikkeen kokoa ja lisää värikontrastia jne.

Viimeiset sanat

Sinun on harkittava koodin uudelleenmuodostusprosessia järjestetyn talon siivoamisena. Tarpeeton sotku kotona voi luoda kaoottisen ja stressaavan ympäristön. Sama koskee kirjoitettua koodia. Puhdas ja hyvin organisoitu koodi on aina helppo vaihtaa, helppo ymmärtää ja helppo ylläpitää. Sinulla ei ole vaikeuksia myöhemmin, jos kiinnität huomiota koodin uudelleenmuodostusprosessiin aikaisemmin.

Kaksi vaikutusvaltaisimmista ohjelmistokehittäjistä Martin Fowler ja Kent Beck ovat omistaneet aikaansa koodin uudelleenmuodostusprosessin ja sen tekniikoiden selittämiseen. He ovat myös kirjoittaneet täydellisen kirjan tästä aiheesta Refaktorointi: Olemassa olevan koodin suunnittelun parantaminen . Tässä kirjassa kuvataan erilaisia ​​refaktorointitekniikoita, joissa on selkeä selitys näiden refaktorointiprosessien parissa työskentelemisestä. Suosittelemme tämän kirjan lukemista, jos haluat perehtyä koodin uudelleenmuodostusprosessiin.