Refaktiranje: kod, vrijeme, aplikacija

Refaktoring je vrsta reorganizacije. Tehnički, on polazi od matematike, kada se izraz ekvivalentnost stavlja - faktori su čišći načini izražavanja iste tvrdnje. Kod refactoringa podrazumijeva ekvivalentnost, početni i konačni proizvodi moraju biti funkcionalno identični. U praksi, on čini kod jasnijim i čišćim, jednostavnim i elegantnim. Primjer je raspon od preimenovanja varijable do unosa metode u klasu treće strane, za koju programer nema prava.

Analiza i refactoring za stvaranje čistog koda

To jednostavno znači poboljšanje dizajna postojećeg koda bez promjene vidljivog ponašanja. U početku osmišljen u Smalltalk zajednici, sada je postao glavna tehnologija razvoja. Iako alati za refactoring omogućuju da se vrlo lako primijeniti. Važno je da programer razumije što radi i zašto će pomoći, na primjer, u situaciji u kojoj je potrebno dopustiti ponovnu upotrebu ponovljenog bloka koda.


Svako prerađivanje je jednostavan proces koji čini jednu logičnu promjenu u strukturi koda. Ako promijenite veliki broj koda odjednom, moguće je da su unesene pogreške. Ali kada i gdje su napravljene pogreške, teško je reći. Ako se promjene provode u malim koracima, a provjere se obavljaju nakon svakog koraka, u probnom radu vjerojatno se javlja pogreška čim se kod unese u sustav. obavljanjeKod refactoringa moguće je provjeriti ovaj korak, a nakon što je korak otkazan, može se podijeliti na još manje korake kako bi se identificirali kvarovi. To je prednost sveobuhvatnih modularnih testova u sustavu, zaštićenih ekstremnim programiranjem. Oni daju programerima i menadžerima povjerenje da refactoring nije prekršio sustav, kod će se ponašati na isti način kao i prije.


Postupak poboljšanja koda odvija se otprilike u sljedećim fazama:

Akcija



Pitanja koja treba postaviti, radnje


Identifikacija problema



Postoji li problem? U čemu je problem?



Karakteristike problema



Zašto moram nešto promijeniti? Koje su prednosti? Postoje li rizici?



Razvoj rješenja



Što bi trebalo biti "ciljno stanje" koda? Koja vrsta pretvorbe koda pretvara kod u željeno stanje?



Promjena koda



Koraci koji će preraditi kod.

Obično se provodi u malim koracima. Nakon svakog takvog koraka developer obično ostaje u radnom sustavu koji ne funkcionira programski. Stručnjaci izmjenjuju ispravke grešaka i nadopunjuju kod između tih koraka. Dakle, refactoring ne isključuje mogućnost promjene funkcionalnosti, on jednostavno kaže da je to još jedna aktivnost povezana s ponovnim uređivanjem koda.

Kontinuirani proces upravljanja kvalitetom

U idealnom slučaju, refactoring će biti dio kontinuiranog procesa poboljšanja kvalitete. Drugim riječima, lako će se ispreplesti s drugimasvakodnevne radnje svakog programera.
Stvaranje čistog koda s analizom i refaktoringom korisno je kada dođe do pogreške i problem treba popraviti ili kod treba proširiti. Proces istovremenog servisiranja ili dodavanja novih značajki također omogućuje rukovoditeljima i programerima veću vjerojatnost da riješe problem, jer to neće zahtijevati dodatnu fazu testiranja.
Ako je razvojni inženjer koji je odgovoran za razumijevanje koda teško, postavit će pitanja i početi dokumentirati nejasan dio, što će biti dobra polazna točka za primjenu novih metoda. Često, vrijeme čišćenja ne dopušta da odmah donesete dobru odluku. Moguće je da je funkcija dodana u žurbi, a ne bug ispravljen. U tim slučajevima, odgovarajući kôd treba označiti s napomenom FIXME tako da se može preraditi kada je dopušteno vrijeme. Takve okolnosti zahtijevaju preradu kako bi se poboljšao postojeći kod ne za pojedine elemente, već za cijeli projekt. Kada dođe vrijeme za rješavanje nagomilanih problema, skenirajte FIXME i TODO. Na bazi koda bit će problema za pregled. Tada se mogu reorganizirati u odgovarajući prioritet. Refactoring je dobra stvar, jer složeni izrazi obično su izgrađeni od jednostavnijih, kompaktnijih komponenti. Pruža jednostavnije komponente ili ih smanjuje na učinkovitije složene izraze, ovisno o tome kako će programer djelovati. Na primjer, učinkovitost refactoring postojećeg kodaBroj članova i operateri: (x - 1) * (x + 1) = x 2 - 1. Četiri izraza u odnosu na tri. Tri operatera protiv dva. Međutim, izraz na lijevoj strani je lakše razumjeti, jer koristi jednostavnije operacije. Osim toga, daje više informacija o strukturi funkcije f (x) = x 2 - 1, budući da su korijeni +/- 1, što bi bilo teško odrediti, jednostavno "gledati" na desnoj strani.

Područja djelovanja

Softver za refaktoriranje za poboljšanje postojećeg koda je mali u mreži, ali je veći dio dobro osmišljen. Tijekom vremena, veličina vlastitog softvera i njegova složenost raste, s povećanjem pogrešaka, a time i pouzdanošću koda. Programeri softvera, pogotovo kada nisu izvorni autori, sve teže održavaju i proširuju kod. Baza koda, koja u bilo kojoj softverskoj tvrtki treba biti vrijedna imovina, u nekom trenutku može postati preopterećena. Ovi negativni procesi mogu uzrokovati prerano starenje softvera, kao što je objašnjeno u radu Martina Fowlera "Refactoring: Poboljšanje postojećeg koda".
Strateški važna je pozornost rukovoditelja softvera i razvojnih inženjera. S praktične strane, primjena razvojnih metoda usporit će ovo starenje. Refactoring može eliminirati ovo starenje uz pravilnu primjenu, po mogućnosti s dobrim softverskim alatima koji pomažu u identificiranju, analiziranju i opisivanju problema, te naposljetku dopuštajući da ih se popravi.

Često kopirajte komponentuprogramer koristi kao prihvatljiviju metodu, budući da je za nju manje zbunjujuća. Barem, Fowler vjeruje u refactoring za poboljšanje postojećeg koda. Trenutačni izvorni kod može se s vremenom mijenjati u odnosu na izvorni dizajn i razvojni programer ga ne može odmah razumjeti. Međutim, ignorira činjenicu da izvorni kod ima mnogo skrivenih značenja. Ispravljanje pogrešaka u izvornom kodu ne može se dokumentirati, ali su vrlo vrijedne. Refactoring čuva ovu skrivenu vrijednost, osiguravajući da se ponašanje sustava neće promijeniti.

Proces preimenovanja metode

Ovaj se primjer odnosi na varijablu, klasu ili drugi java element koji ima pogrešno ime i treba znati kako preoblikovati ovaj kôd. Za to su potrebne sve veze i možda ažuriranja datoteka. Proces može uključivati ​​preimenovanje metode u podrazrede. S druge strane, preimenovanje paketa uključuje i pomicanje datoteka i direktorija i ažuriranje sustava za upravljanje verzijama.
Korektivne metode:
  • Premještanje klase. Klasa je u pogrešnom paketu, pa bi se trebala premjestiti u drugi paket gdje je najprikladniji.
  • Izvadak. Dugačku metodu treba podijeliti na faze kako bi se poboljšala čitljivost i praktičnost usluge. Dio koda s jednim logičkim zadatkom zamjenjuje se pozivom na novu metodu.
  • Vađenje superklasa. Postojeća klasa osigurava funkcionalnost koju je potrebno na neki način modificirati. Apstraktna klasa je također uvedena kao roditelj trenutne klaseonda je opće ponašanje "strože" za ovog novog oca.
  • Zamjena uvjetne vrijednosti polimorfizmom. Klasa metode mogu provjeriti određenu vrijednost (ako je operator prekidač) za određivanje ispravne akcije za izvršenje.

    Prednosti metode

    Izvođenje nekoliko operacija refactoringa prije ili tijekom otklanjanja pogrešaka koda ima određene prednosti. Često je lakše odrediti lokaciju pogreške. Tako se zadržava vrijeme provedeno u radu na kodu i poboljšanju njegove kvalitete. Dobro strukturirani kod je također manje sklon pogreškama kada je u pitanju njegovo širenje. Stručnjaci kažu da primjena metode doprinosi prednostima bilo kojeg programa koji ima barem jednu od sljedećih nedostataka:
  • Programi koje je teško čitati i teško ih je promijeniti.
  • Dvojne logičke aplikacije.
  • Programi koji zahtijevaju dodatna ponašanja koja zahtijevaju promjene koda.
  • Programi s složenom logikom uvjetovanja koje je teško mijenjati.
  • Ukratko, može se tvrditi da stvarne koristi obično dolaze na duge staze, na primjer, kada se refactoring poboljšanja postojećeg pdf koda. Oni se sastoje od znatno smanjenog vremena koje programeri troše na rad na otklanjanju pogrešaka i održavanju kako bi se poboljšala pouzdanost koda. Osim toga, umnožava se dupliciranje koda i potiče se ponovna uporaba koda. Ukupni troškovi održavanja i razvoja trebali bi se smanjiti, a brzina tima odgovoriti na promjenjive potrebe - povećati.

    Nedostatak korekcije ZA

    Ako ima toliko neporecivih prednosti u odnosu na dobro strukturiran, jasan kod, i ako refaktoriranje softverskog koda proizlazi iz kaotičnog, slabo strukturiranog, sklonog kodu, dobro promišljenog koda, onda postoji logično pitanje zašto to ne čine svi programeri ? U praksi, programeri su više nerado obavljaju poboljšanja, jer neki refactoring samo umorna. Pogotovo ako za to nema očite vanjske koristi. Također se može okriviti za upravljanje projektom. Kada priručnik podržava samo vanjska svojstva koda, kao što su funkcionalnost i performanse, ali ne obraća pozornost na unutarnju kvalitetu koda. Osim toga, postoji ozbiljan rizik od proboja koda kroz operacije refactoringa. Ako se, primjerice, promijene nazivi datoteka, problem može biti i sljedivost promjena. Čak i ako programer nastoji reorganizirati neki loše strukturirani kod. Upravitelj može imati potpuno drugačiju perspektivu u pogledu učinka UA-a i može se suprotstaviti svakom pokušaju promjene radnog koda. Ti se problemi ne mogu jednostavno zanemariti, već ih je potrebno pravilno uzeti u obzir od strane razvojnih timova i uprave.

    Automatizacija procesa

    Kada se provodi refactoring, promatrano vanjsko ponašanje treba zajamčiti da ostane nepromijenjeno. Ako se izvršava ručno, često je potrebno ponovno izgraditi sustav i pokrenuti testove. Stoga je ručna metoda stvarno praktična samo s poštovanjemsljedećih uvjeta:
  • Sustav iz kojeg je reorganizirani kod dio može se brzo vratiti.
  • Postoje automatska "regresijska" ispitivanja koja se mogu često izvoditi.
  • Ova situacija nije vrlo uobičajena i znači da su programi refactoringa ograničeni. Ona postaje sve raširenija, pogotovo kada sve više ljudi koristi XP (Extreme Programming) metode. Još jedna prepreka metodi je da su mnogi od tih refactoringa zamorno. Još važnije, uvjerenje da su napravljene ispravne promjene. Stoga se kod poboljšanja preporučuje korištenje automatiziranih alata. Brzina njihovog rada ima još jednu prednost, koja se očituje u okruženju razvojnog tima. Programer mnogo rjeđe obavlja operacije refactoringa, ako je izvorni kod također u vlasništvu drugih developera. Integracija s programerima koji su odabrali IDE također donosi mnoge prednosti. Prvo, prisutnost alata pri ruci znači da programeri mogu lako reorganizirati. Ne trebaju se prebacivati ​​između režima razvoja i refaktoringa i umjesto toga vidjeti ga kao dio njihovog normalnog razvojnog ciklusa. Drugo, IDE funkcije, kao što je integracija kontrole verzija, mogu smanjiti napor metode, kao što je pomicanje klase ili preimenovanje paketa.

    Analiza koda Visual Studio 2017

    Preuranjena optimizacija može biti korijen svega zla, ali aplikacijski alati pružaju jasnoću, čistoću i sigurnost koda. Testiranje programa prije slanja važan je dio razvojnog procesa. Ovdje dolazi na snagualati i metode za analiziranje koda i profiliranje - omogućuju vam da procijenite kod za pogreške, uska grla i učinkovito korištenje procesnih i memorijskih resursa. Moderni alati za profiliranje kodova mogu izravno usmjeriti na točne linije koda koje zahtijevaju refactoring, ili na knjižnice i druge ovisnosti, koje su slabe točke u aplikacijskoj arhitekturi.
    Prije Visual Studio 2012, većina tih vrsta analize i testiranja kodova zahtijevala je alate treće strane i ručno sklapanje, testiranje, analizu i ponavljanje zadataka za razvojnog programera. Danas Visual Studio ima prilično snažne alate za analizu. Osim toga, postoje izvrsni alati koji će programeru pomoći da se upusti u aplikaciju za testiranje produktivnosti i optimizacije, predloške projekata koji imaju učinkovite ovisnosti i ugrađena testna okruženja, kao i robusne alate za integriranje automatizirane analize i testiranja u radni tijek i izdanje.

    Alati za izvedbu

    Opseg skupa ugrađenih alata za refaktoriranje za poboljšanje postojećeg koda projekta prvo je grupiran u Koncentrator performansi i dijagnostike u Visual Studio 2013, koji je dodatno poboljšan i proširen u prozoru za postavljanje performansi i dijagnostike i alatnoj traci skeniranih alata Visual Studio 2015. Pomoću Visual Studio 2017. ovi su alati tako integrirani u razvojno okruženje da više nemaju hiroviti naziv, ali se i dalje razvijaju. Program je opremljen s velikom dokumentacijom i smjernicamaMicrosoftovi dokumenti počevši od odjeljka "Početak rada s alatima za izvedbu" i "Vodič za usmjeravanje izvedbe za Visual Studio Starter".
    Korisnici će pronaći informacije o prikupljanju podataka i profiliranju tijekom implementacije metode, ne samo za tradicionalne .NET Framework aplikacije, već i za ASP.NET JavaScript proizvode i web-mjesta, računalstvo visokih performansi (HPC) i testiranje opterećenja. Još jedan alat koji programeri uživaju je RefV kod za PerfView za analizu izvedbe. Morrison je viši arhitekt Microsofta i napisao je PerfView za internu analizu performansi i prilagodbu timova koji stvaraju .NET Framework i Visual Studio. Sada je to open source alat koji je još uvijek u aktivnom razvoju.

    Dodatni mehanizmi za profiliranje i otklanjanje pogrešaka

    Osim alata dostupnih od Microsofta, alati treće strane koriste se za zadovoljavanje potreba za finim podešavanjem:
  • Jains dotTrace Profiler pomaže u praćenju vremena praćenja, prikupljanju smeća, raspodjeli radnog opterećenja, izvedbi O. Za probne korake dostupna je probna razdoblja od 10 dana.
  • Redgate ANTS Performance Profiler - Još jedan popularan alat za .NET Framework projekte pruža istu analizu sinkronizacije koda kao i drugi alati, ali i produbljuje performanse upita za baze podataka koji podržavaju profiliranje naprednog pristupa podacima podrška za Oracle, MySQL, PostgreSQL.
  • DevExpress CodeRush je još jedanAlat za analizu i refaktoring za C #, Visual Basic i XAML baze podataka. Alati za analizu CodeRush ne samo da rade s osnovnim rješenjima, već imaju i integriranu integracijsku integraciju testova, podržavajući okvir NUnit, xUnit, MSpec i MSTest, kao i CoreCLR test slučajeve u DNX okruženju.
  • Microsoft Code Analysis 2017 pruža ugrađeni pristup za više od 100 najpopularnijih FxCop pravila kao živih analizatora. Analizatori pregledavaju kod C # ili Visual Basic dok tipkate i daju vam savjete o performansama, sigurnosti i najboljim postupcima, kao i pristupu brzom kodu popravka za kôd.
  • Microsoft DevSkim složenija je i fleksibilnija struktura kodnih modula i analizatora koji se usredotočuju na analizu sigurnosti ugrađenog koda kada se upisuju. Potencijalna sigurnosna pitanja istaknuta su u kôdu veze za dodatne informacije jednim klikom za siguran alternativni kôd.
  • Vremenski raspored

    Korištenje automatiziranih alata za refaktorstvo čini vjerojatnijim da će programer pravodobno izvršiti potrebne korake, smanjujući vjerojatnost pogrešaka. No, ne manje važan je izbor termina za njegovo provođenje. Planirano refactoring poboljšava učinkovitost kodova eliminirajući dupliciranje. Ključna točka ovdje je da se popravi što je prije moguće prije nego što postane problem. U ovom slučaju, koristi se kontinuirani refactoring, što je vrlo važno za kontinuiranu isporuku koda.
    U najboljem slučaju, programeri se često prebacuju između svih gore navedenih tipova refactoringa. U ovom slučaju, ime tipa nije važno, aliVažno je da se pokrene. Na primjer, ako čitate kôd, programer razumije da se klase ili metode mogu bolje obaviti, to morate učiniti odmah bez odgađanja, koristeći uobičajene metode za vađenje velikih kvarova ili metode preimenovanja radi boljeg čitanja. Ova platforma Martin Fowler na Workflowima pomaže korisnicima da bolje znaju, planiraju i izvode poboljšanja. Zato svaki programer treba ne samo znati što je refactoring koda, nego i kada ga treba ispravno izvršiti.

    Povezane publikacije