streamalism.org

1. Pregled

U ovom uputstvu proći ćemo kroz principe čistog kodiranja. Također ćemo razumjeti zašto je čist kod važan i kako to postići na Javi. Nadalje, vidjet ćemo ima li dostupnih alata koji će nam pomoći.

2. Što je čisti kôd?

Dakle, prije nego što uskočimo u detalje čistog koda, shvatimo što podrazumijevamo pod čistim kodom. Iskreno, na ovo ne može postojati jedan dobar odgovor. U programiranju se neke zabrinutosti šire i stoga rezultiraju općim načelima. Ali tada, svaki programski jezik i paradigma predstavljaju vlastiti niz nijansi, što nas nalaže da usvojimo prikladne prakse.

Široko, čisti kôd može se sažeti kao kôd koji svaki programer može lako čitati i mijenjati. Iako ovo može zvučati kao pretjerano pojednostavljenje koncepta, kasnije ćemo vidjeti u tutorialu kako se to gradi. Gdje god čujemo o čistom kodu, možda naletimo na neku referencu na Martina Fowlera. Evo kako opisuje čisti kôd na jednom od mjesta:

Svaka budala može napisati kod koji računalo može razumjeti. Dobri programeri pišu kod koji ljudi mogu razumjeti.

3. Zašto bismo trebali brinuti o čistom kodeksu?

Pisanje čistog koda stvar je osobne navike koliko i stvar vještine. Kao programer, vremenom rastemo kroz iskustvo i znanje. Ali, moramo se zapitati zašto bismo ipak trebali ulagati u razvoj čistog koda? Shvaćamo da će drugima vjerojatno biti lakše čitati naš kôd, ali je li to dovoljan poticaj? Hajde da vidimo!

Čista načela kodiranja pomažu nam u postizanju puno poželjnih ciljeva povezanih sa softverom koji namjeravamo proizvesti. Prođimo kroz njih da bismo to bolje razumjeli:

• Održiva baza kodova: Bilo koji softver koji razvijemo ima produktivan život i tijekom tog razdoblja bit će potrebne promjene i opće održavanje. Čisti kod može vam pomoći u razvoju softvera koji je lako promijeniti i održavati tijekom vremena.
• Jednostavnije rješavanje problema: Softver može pokazivati ​​nenamjerno ponašanje zbog različitih unutarnjih ili vanjskih čimbenika. Često može zahtijevati brzi zaokret u pogledu popravaka i dostupnosti. Softver razvijen s načelima čistog kodiranja je lakše riješiti probleme.
• Brže ukrcavanje: Softver će tijekom svog života vidjeti da ga mnogi programeri stvaraju, ažuriraju i održavaju, a programeri se pridružuju u različitim vremenskim trenucima. To zahtijeva brže uključivanje kako bi se održala visoka produktivnost, a čisti kôd pomaže u postizanju ovog cilja.

4. Karakteristike čistog koda

Baze koda napisane s načelima čistog kodiranja pokazuju nekoliko karakteristika koje ih razlikuju. Prođimo kroz neke od ovih karakteristika:

• Usredotočeno: Komad kod bi trebao biti napisan za rješavanje određenog problema. Ne smije raditi ništa što nije strogo vezano za rješavanje zadanog problema. To se odnosi na sve razine apstrakcije u kodnoj bazi, poput metode, klase, paketa ili modula.
• Jednostavan: Ovo je daleko najvažnija i često ignorirana karakteristika čistog koda. Softver dizajn i provedba moraju biti što jednostavniji, koji nam mogu pomoći u postizanju željenih ishoda. Povećana složenost baze podataka čini ih sklonima pogreškama te ih je teško čitati i održavati.
• Testibilno: Čisti kôd, iako je jednostavan, mora riješiti problem. Mora biti intuitivno i jednostavno testirati bazu koda, po mogućnosti automatizirano. To pomaže uspostaviti osnovno ponašanje kodne baze i olakšava je promjenu bez ičega lomljenja.

To su ono što nam pomaže u postizanju ciljeva razmotrenih u prethodnom odjeljku. Korisno je započeti razvoj uzimajući u obzir ove karakteristike u usporedbi s refaktorom kasnije. To dovodi do nižih ukupnih troškova vlasništva za životni ciklus softvera.

5. Čisto kodiranje u Javi

Sad kad smo prošli dovoljno pozadine, pogledajmo kako u Java možemo ugraditi principe čistog kodiranja. Java nudi puno najboljih praksi koje nam mogu pomoći u pisanju čistog koda. Kategorizirat ćemo ih u različite segmente i razumjeti kako pisati čisti kôd s uzorcima koda.

5.1. Struktura projekta

Iako Java ne provodi niti jednu strukturu projekta, uvijek je korisno slijediti dosljedan obrazac za organiziranje izvornih datoteka, testova, konfiguracija, podataka i drugih artefakata koda. Maven, popularni alat za izgradnju za Javu, propisuje određenu strukturu projekta. Iako možda ne koristimo Maven, uvijek je lijepo držati se konvencije.

Pogledajmo neke mape koje Maven predlaže da stvorimo:

• src / main / java: Za izvorne datoteke
• src / glavni / resursi: Za datoteke resursa, poput svojstava
• src / test / java: Za testne izvorne datoteke
• src / test / resources: Za testne datoteke resursa, poput svojstava

Slično ovome, postoje i druge popularne strukture projekata poput Bazela predložene za Javu, a mi bismo trebali odabrati jednu ovisno o našim potrebama i publici.

5.2. Konvencija o imenovanju

Slijedeći Konvencije o imenovanju mogu mnogo doprinijeti da naš kôd postane čitljiv i stoga održiv. Rod Johnson, tvorac Proljeća, naglašava važnost imenovanja konvencija u proljeće:

"... ako znate što nešto radi, imat ćete prilično dobru priliku pogoditi naziv klase Spring ili sučelje za to ..."

Java propisuje skup pravila kojih se treba pridržavati kada je riječ o imenovanju bilo čega u Javi. Dobro oblikovano ime ne pomaže samo u čitanju koda, već i puno govori o namjeri koda. Uzmimo nekoliko primjera:

• Nastava: Klasa u smislu objektno orijentiranih koncepata nacrt je za objekte koji često predstavljaju objekte iz stvarnog svijeta. Stoga je smisleno koristiti imenice za imenovanje klasa koje ih dovoljno opisuju:

kupac javne klase {}

• Varijable: Varijable u Javi bilježe stanje objekta stvorenog iz klase. Naziv varijable trebao bi jasno opisivati ​​namjeru varijable:

javna klasa Customer {private String customerName; }

• Metode: Metode u Javi uvijek su dio klasa i stoga općenito predstavljaju radnju na stanje objekta stvorenog iz klase. Stoga je korisno imenovati metode pomoću glagola:

javna klasa Customer {private String customerName; javni niz getCustomerName () {return this.customerName; }}

Iako smo raspravljali samo o tome kako imenovati identifikator na Javi, imajte na umu da postoje dodatni najbolji primjeri kao što je kućište deva, koje bismo trebali promatrati zbog čitljivosti. Može biti više konvencija povezanih s imenovanjem sučelja, enuma, konstanti.

5.3. Struktura izvorne datoteke

Izvorna datoteka može sadržavati različite elemente. Dok je Java kompajler provodi neku strukturu, velik dio je fluidan. No pridržavanje određenog redoslijeda smještanja elemenata u izvornu datoteku može značajno poboljšati čitljivost koda. Postoji više popularnih vodiča za stil kojima se možete nadahnuti, poput Googleovih i Proljetnih.

Pogledajmo kako bi trebao izgledati tipični poredak elemenata u izvornoj datoteci:

• Izjava o paketu
• Izvezi o uvozu
  • Sav statički uvoz
  • Sav nestatički uvoz
• Točno jedna klasa najviše razine
  • Varijable razreda
  • Varijable instance
  • Konstruktori
  • Metode

Osim navedenog, metode se mogu grupirati na temelju njihove funkcionalnosti ili opsega. Ne postoji jedna dobra konvencija, a ideja bi trebala biti odlučili jednom, a zatim slijedili dosljedno.

Pogledajmo dobro oblikovanu izvornu datoteku:

# /src/main/java/com/baeldung/application/entity/Customer.java paket com.baeldung.application.entity; import java.util.Date; javna klasa Customer {private String customerName; privatni Datum pridruživanjaDatum; javni kupac (niz ime kupca) {this.customerName = customerName; this.joiningDate = novi datum (); } javni niz getCustomNName () {return this.customerName; } javni datum getJoiningDate () {return this.joiningDate; }}

5.4. Razmaci

Svi znamo da je lakše čitati i razumjeti kratke odlomke u usporedbi s velikim blokom teksta. Nije baš različito ni kada se radi o čitanju koda. Dobro postavljeni i dosljedni razmaci i prazni redovi mogu poboljšati čitljivost koda.

Ideja je ovdje uvesti logične grupacije u kod koje mogu pomoći u organiziranju misaonih procesa dok ga pokušavaju pročitati. Ovdje se ne može usvojiti niti jedno pravilo, već općeniti skup smjernica i inherentna namjera da se čitljivost održi u središtu:

• Dva prazna retka prije pokretanja statičkih blokova, polja, konstruktora i unutarnjih klasa
• Jedan prazan redak nakon višerednog potpisa metode
• Jedan prostor koji odvaja rezervirane ključne riječi poput if, for, catch iz otvorenih zagrada
• Jedan prostor koji odvaja rezervirane ključne riječi kao i ostali, ulov iz završnih zagrada

Popis ovdje nije iscrpan, ali trebao bi nas uputiti prema tome.

5.5. Udubljenje

Iako prilično trivijalan, gotovo svaki programer jamčio bi za to dobro razvedeni kod puno je lakše čitati i razumjeti. Ne postoji jedinstvena konvencija za uvlačenje koda u Javi. Ključno je ovdje usvojiti popularnu konvenciju ili definirati privatnu, a zatim je dosljedno slijediti u cijeloj organizaciji.

Pogledajmo neke od važnih kriterija uvlačenja:

• Tipična najbolja praksa je korištenje četiri razmaka, jedinice uvlačenja. Napominjemo da neke smjernice predlažu karticu umjesto razmaka. Iako ovdje nema apsolutno najbolje prakse, ključ ostaje dosljednost!
• Uobičajeno bi trebala biti granična dužina linije, ali to se može postaviti više od tradicionalnih 80 zbog većih zaslona koje programeri danas koriste.
• I na kraju, budući da mnogi izrazi neće stati u jedan redak, moramo ih dosljedno razbijati:
  • Pozivi metode prekida nakon zareza
  • Razbijanje izraza prije operatora
  • Uvučene crte umotane radi bolje čitljivosti (ovdje na Baeldungu preferiramo dva razmaka)

Pogledajmo primjer:

Popis kupacaIds = kupac.stream () .map (kupac -> kupac.getCustomerId ()) .collect (Collectors.toCollection (ArrayList :: new));

5.6. Parametri metode

Parametri su neophodni za rad metoda prema specifikaciji. Ali, dugačak popis parametara može nekome otežati čitanje i razumijevanje koda. Pa, gdje bismo trebali povući crtu? Razumijemo najbolje prakse koje bi nam mogle pomoći:

• Pokušajte ograničiti broj parametara koje metoda prihvaća, tri parametra mogu biti jedan dobar izbor
• Razmislite o refaktoriranju metode ako joj je potrebno više od preporučenih parametara, obično dugački popis parametara također ukazuje na to da metoda može raditi više stvari
• Možemo razmotriti grupiranje parametara u prilagođene tipove, ali moramo paziti da nepovezane parametre ne izbacimo u jedan tip
• Konačno, iako bismo trebali koristiti ovaj prijedlog za prosudbu čitljivosti koda, ne smijemo biti pedantni prema njemu

Pogledajmo primjer ovoga:

public boolean setCustomerAddress (String firstName, String lastName, String streetAddress, String city, String zipCode, String state, String country, String phoneNumber) {} // Ovo se može refaktorirati kao ispod kako bi se povećala čitljivost javnog boolean setCustomerAddress (adresa adresa) {}

5.7. Tvrdo kodiranje

Vrijednosti kodiranja u kodu često mogu dovesti do više nuspojava. Na primjer, može dovesti do dupliciranja, što promjenu otežava. Često vrijednosti mogu biti nepoželjne ako vrijednosti trebaju biti dinamične. U većini slučajeva, kodirane vrijednosti mogu se refaktorirati na jedan od sljedećih načina:

• Razmislite o zamjeni konstantama ili enumima definiranim u Javi
• Inače, zamijenite konstantama definiranim na razini klase ili u zasebnoj datoteci klase
• Ako je moguće, zamijenite vrijednostima koje se mogu odabrati iz konfiguracije ili okoline

Pogledajmo primjer:

privatni int storeClosureDay = 7; // Ovo se može refaktorizirati tako da koristi konstantu iz Java private int storeClosureDay = DayOfWeek.SUNDAY.getValue ()

Opet, oko toga ne postoje stroge smjernice kojih se treba pridržavati. Ali moramo biti svjesni činjenice da će neki kasnije trebati pročitati i održavati ovaj kod. Trebali bismo odabrati konvenciju koja nam odgovara i biti dosljedni u tome.

5.8. Šifra komentara

Kodni komentari mogu biti korisno tijekom čitanja koda za razumijevanje netrivijalnih aspekata. Istodobno, treba paziti na ne uključuju očite stvari u komentare. To može napuhati komentare što otežava čitanje relevantnih dijelova.

Java dopušta dvije vrste komentara: komentari implementacije i komentari dokumentacije. Oni također imaju različite svrhe i različite formate. Razumijemo ih bolje:

• Dokumentacija / JavaDoc komentari
  • Ovdje su publika korisnici kodne baze
  • Pojedinosti su ovdje obično bez implementacije, usredotočujući se više na specifikaciju
  • Tipično korisno neovisno o bazi koda
• Primjena / Blokiraj komentare
  • Publika ovdje su programeri koji rade na kodnoj bazi
  • Ovdje su pojedinosti specifične za implementaciju
  • Tipično korisno zajedno s kodnom bazom

Pa, kako bismo ih trebali optimalno koristiti kako bi bili korisni i kontekstualni?

• Komentari bi trebali nadopunjavati kôd, ako kôd ne možemo razumjeti bez komentara, možda ga trebamo refaktorizirati
• Blokirane komentare trebali bismo koristiti rijetko, moguće da bismo opisali netrivijalne odluke o dizajnu
• JavaDoc komentare trebali bismo koristiti za većinu klasa, sučelja, javnih i zaštićenih metoda
• Svi komentari trebaju biti dobro oblikovani s odgovarajućim uvlačenjem radi čitljivosti

Pogledajmo primjer smislenog komentara dokumentacije:

/ ** * Ovom metodom želi se dodati nova adresa za kupca. * Međutim, imajte na umu da dopušta samo jednu adresu po poštanskom broju *. Stoga će ovo nadjačati bilo koju prethodnu adresu s * istim poštanskim brojem. * * @param adresa adresa koju treba dodati postojećem kupcu * / / * * Ova metoda koristi prilagođenu implementaciju metode equals * kako bi se izbjeglo dupliciranje adrese s istim poštanskim brojem. * / public addCustomerAddress (adresa adresa) {}

5.9. Sječa drva

Svatko tko je ikad položio ruku na proizvodni kod za otklanjanje pogrešaka, u nekom je trenutku želio više dnevnika. The Važnost trupaca ne može se previše naglasiti u razvoju uopće, a posebno u održavanju.

U Javi postoji puno knjižnica i okvira za bilježenje, uključujući SLF4J, Logback. Iako evidentiranje čine prilično trivijalnim u bazi kodova, mora se voditi računa o evidentiranju najboljih praksi. Inače obavljena sječa može se pokazati kao noćna mora za održavanje umjesto bilo kakve pomoći. Prođimo kroz neke od najboljih primjera iz prakse:

• Izbjegavajte pretjerano bilježenje, razmislite koje bi informacije mogle biti od pomoći u rješavanju problema
• Pametno odaberite razine dnevnika, možda ćemo htjeti selektivno omogućiti razine dnevnika u proizvodnji
• Budite vrlo jasni i opisni s kontekstualnim podacima u poruci dnevnika
• Upotrijebite vanjske alate za praćenje, agregiranje, filtriranje poruka dnevnika za bržu analitiku

Pogledajmo primjer opisnog zapisivanja s pravom razinom:

logger.info (String.format ("Stvoren je novi kupac s ID-om kupca:% s", id));

6. Je li to sve?

Iako je u prethodnom odjeljku istaknuto nekoliko konvencija o oblikovanju koda, to nisu jedine koje bismo trebali znati i do kojih bismo trebali brinuti. Čitljiv i održiv kôd može imati koristi od velikog broja dodatnih najboljih praksi prikupljenih tijekom vremena.

Možda smo ih s vremenom susretali kao smiješne kratice. Oni u osnovi bilježe učenja kao jedinstveni ili kao skup principa koji nam mogu pomoći u pisanju boljeg koda. Međutim, imajte na umu da ih ne bismo trebali slijediti samo zato što postoje. Većinu vremena korist koju pružaju proporcionalna je veličini i složenosti baze kodova. Moramo pristupiti našoj bazi kodova prije nego što usvojimo bilo koji princip. Još važnije, moramo ostati dosljedni njima.

6.1. ČVRSTO

SOLID je mnemotečka kratica koja se temelji na pet principa koje postavlja za pisanje razumljivog i održivog softvera:

• Načelo jedinstvene odgovornosti: Svakog sučelje, klasa ili metoda koju definiramo trebaju imati jasno definiran cilj. U osnovi, u idealnom bi slučaju trebao raditi jednu stvar i to dobro. To učinkovito dovodi do manjih metoda i klasa koje se također mogu provjeriti.
• Otvoreno-zatvoreno načelo: Kôd koji pišemo idealno bi trebao biti otvoren za proširenje, ali zatvoren za preinaku. To zapravo znači da bi klasa trebala biti napisana na način da ne bi trebalo biti potrebe za njenom izmjenom. Međutim, trebao bi omogućiti promjene nasljeđivanjem ili sastavom.
• Načelo zamjene Liskova: Ono što navodi ovo načelo je to svaka podrazred ili izvedena klasa trebaju biti zamjenjivi za svoju roditeljsku ili osnovnu klasu. To pomaže u smanjenju sprezanja u bazi kodova, a time i u poboljšanju ponovne upotrebe.
• Načelo segregacije sučelja: Implementacija sučelja način je za pružanje specifičnog ponašanja našoj klasi. Međutim, klasa ne smije trebati provoditi metode koje joj nisu potrebne. Ovo što od nas zahtijeva jest definiranje manjih, fokusiranijih sučelja.
• Načelo inverzije ovisnosti: Prema ovom principu, klase trebaju ovisiti samo o apstrakcijama, a ne o njihovim konkretnim provedbama. To zapravo znači da klasa ne bi trebala biti odgovorna za stvaranje instanci za svoje ovisnosti. Umjesto toga, takve ovisnosti treba ubrizgati u razred.

6.2. SUHO I POLJUBIŠTE

DRY je kratica od "Don's Repeat Yourself". Ovo načelo kaže da komad koda ne smije se ponavljati u softveru. Obrazloženje ovog načela je smanjenje dupliciranja i veća ponovna upotreba. Međutim, imajte na umu da bismo trebali biti oprezni pri usvajanju ovoga previše doslovno. Neko dupliciranje zapravo može poboljšati čitljivost i održivost koda.

KISS je kratica za "Neka bude jednostavno, glupo". Ovo načelo kaže da trebali bismo nastojati da kod bude što jednostavniji. To olakšava razumijevanje i održavanje tijekom vremena. Slijedeći neka od prethodno spomenutih načela, ako nastavu i metode držimo usredotočenima i malim, to će dovesti do jednostavnijeg koda.

6.3. TDD

TDD je skraćenica od "Test Driven Development". Ovo je praksa programiranja koja od nas traži da napišemo bilo koji kod samo ako automatizirano testiranje ne uspije. Stoga moramo započnite s razvojem dizajna automatiziranih testova. U Javi postoji nekoliko okvira za pisanje automatiziranih jediničnih testova poput JUnit i TestNG.

Blagodati takve prakse su ogromne. To dovodi do softvera koji uvijek radi prema očekivanjima. Kao što uvijek započinjemo s testovima, postupno dodajemo radni kod u male dijelove. Također, kôd dodajemo samo ako novi ili bilo koji stari test ne uspije. Što znači da to dovodi i do ponovne upotrebe.

7. Alati za pomoć

Pisanje čistog koda nije samo stvar principa i prakse, već je osobna navika. Skloni smo rasti kao bolji programeri dok učimo i prilagođavamo se. Međutim, kako bismo održali dosljednost velikog tima, trenirat ćemo i određenu provedbu. Kodirati recenzije su uvijek bile izvrsno sredstvo za održavanje dosljednosti i pomoći programerima da rastu kroz konstruktivne povratne informacije.

Međutim, ne moramo nužno ručno provjeravati sva ta načela i najbolje prakse tijekom pregleda koda. Freddy Guime iz Jave OffHeap govori o vrijednosti automatizacije nekih provjera kvalitete kako bi se cijelo vrijeme završavalo s određenim pragom s kvalitetom koda.

Tamo su nekoliko alata dostupnih u ekosustavu Java, koji oduzimaju barem neke od ovih odgovornosti recenzentima koda. Pogledajmo koji su neki od ovih alata:

• Oblikovači koda: Većina popularnih uređivača Java koda, uključujući Eclipse i IntelliJ, omogućuje automatsko formatiranje koda. Možemo koristiti zadana pravila oblikovanja, prilagoditi ih ili zamijeniti prilagođenim pravilima oblikovanja. Ovo vodi računa o mnogim konvencijama strukturnog koda.
• Alati za statičku analizu: Postoji nekoliko alata za statičku analizu koda za Javu, uključujući SonarQube, Checkstyle, PMD i SpotBugs. Imaju bogat skup pravila koja se mogu koristiti takva kakva jesu ili prilagoditi određenom projektu. Izvrsno otkrivaju puno koda koji miriše na kršenje pravila imenovanja i curenje resursa.

8. Zaključak

U ovom smo uputstvu prošli kroz važnost principa čistog kodiranja i karakteristika koje čisti kod prikazuje. Vidjeli smo kako u praksi usvojiti neka od ovih načela koja su se razvila u Javi. Također smo razgovarali o drugim najboljim praksama koje pomažu u održavanju koda čitljivim i održivim tijekom vremena. Na kraju smo razgovarali o nekim alatima koji su nam na raspolaganju u ovom pothvatu.

Da rezimiramo, važno je napomenuti da su svi ovi principi i prakse neophodni kako bi naš kod bio čišći. Ovo je subjektivniji pojam i stoga ga se mora vrednovati kontekstualno.

Iako je na raspolaganju mnogo usvojenih pravila, moramo biti svjesni svoje zrelosti, kulture i zahtjeva. Možda ćemo morati prilagoditi ili, u tom smislu, potpuno osmisliti novi skup pravila. No, bez obzira na to što je slučaj, važno je ostati dosljedan u cijeloj organizaciji kako biste iskoristili koristi.