Pentru fiecare programator conceptul de "cod curat" este diferit. În acest articol, voi încerca să-mi exprim gândurile în această privință și, poate, într-un fel, chiar să schimbe vechile abordări.
Deci, care sunt criteriile pentru determinarea purității codului?
numire
Uneori aceasta este o întrebare foarte complexă și "filosofică". Reguli de bază:
- Numele variabilei ar trebui să fie cât mai scurt posibil și să răspundă la întrebările "ce este stocat în această variabilă" și "cum va fi folosită variabila". În acest caz, înțelegerea are o prioritate superioară celei mai scurte. Același lucru este valabil și pentru funcții;
- utilizați camelCase pentru numele variabilelor și funcțiile care constau din mai multe cuvinte;
- Numai engleza. Se întâmplă de multe ori că prima versiune a proiectului a fost scrisă de dezvoltatori dintr-o țară, iar cea de-a doua versiune a celeilalte. Și dezvoltatorul de limbă franceză nu va înțelege ce voia să spună vorbitorul rus prin apelul variabilelor var moiTovary. var cena. var ssylka;
- nume scurte cum ar fi "var a, lăsați b" să aibă sens să folosească numai variabilele locale, într-o mică bucată de cod.
Principalele criterii pe care le urmez la scrierea funcțiilor:
- Creați o nouă funcție în loc să duplicați codul. Dacă în 2 locuri există același cod pentru 2-3 sau mai multe linii, atunci ar trebui să luați această parte a codului într-o funcție separată.
formatarea
Codul de formatare este foarte importantă atât pentru comoditatea de sprijin pentru proiect, precum și pentru viteza și comoditatea de orientare în proiect structura, variabilele și funcțiile. Lipirea stilul de formatare adoptat de societate, face mai ușor să fie incluse în activitatea de dezvoltatori, care sa alăturat proiectului în procesul de dezvoltare, deoarece dezvoltarea ei sunt ghidate de aceleași principii ca dezvoltatorii, care a condus proiectul de la zero.
Exemplu de structură a proiectului:
Respectarea unei singure structuri de proiect accelerează căutarea fișierelor corecte. La fel de important este formatarea clasei. principiile sale principale:
Un fișier este o clasă (structură).
Mai multe detalii despre elementele:
Lista completă a mărcilor Pragma:
Codul pare chiar mai structurat dacă funcțiile și variabilele sunt formatate folosind PragmaMarks într-o secvență dată, mai degrabă decât împrăștiate aleatoriu. Personal, am adăugat o astfel de listă la Xcode ca fragmente, pentru confort.
Este o practică bună atunci când există un document în companie cu un nume precum "iOS Code Styles Guidline", cu care noul angajat se cunoaște înainte de a începe lucrarea și apoi formatează codul în stilul așteptat.
refactoring
Refactorizarea este un proces controlat pentru îmbunătățirea codului fără a scrie noi funcționalități. Sarcina refactorizării este de a face codul curat.
Codul de scriere poate fi împărțit în 2 puncte: pentru a face codul de lucru și pentru a refactor codul. Ce ne poate lăsa codul? Lucruri precum:
Modele arhitecturale
Folosind modele arhitecturale vă permite să echilibrați împărțirea responsabilităților între entități. Conceptul de "model" poate fi explicat ca un stil, un model conceput pentru a rezolva o problemă specifică. Modelul arhitectural definește structura aplicației în ansamblul său, specifică împărțirea responsabilităților între clase, fiecare dintre acestea jucând doar unul dintre roluri. Un model arhitectural (numit și model de design) determină nu numai rolul claselor și obiectelor în aplicații, ci și modul în care obiectele comunică unul cu celălalt.
Principalul model de design din Apple (MacOS iOS) este MVC (Model-View-Controller). De-a lungul timpului, au apărut și altele, ca urmare, astăzi lista principalelor modele arhitecturale este după cum urmează:
- MVC (Model-View-Controller);
- MVP (Prezentator pasiv-model);
- MVVM (Model-View-ViewModel);
- Viper (CleanSwift).
Acesta este modelul cel mai frecvent utilizat. El clasifică obiectele în funcție de rolul lor pe proiect, care ajută la separarea curată a codurilor. Aplicarea corectă a modelului MVC înseamnă că obiectul se încadrează în numai una din cele 3 grupe.
Vizualizare - obiectele responsabile pentru reprezentarea vizuală, pentru ceea ce vede utilizatorul. În iOS, toate acestea sunt clase care au prefixul UI (și moștenitorii acestora).
Controlorul este mediatorul între modelul View i. Coordonează toate lucrările: răspunde la acțiunile utilizatorilor efectuate în vizualizare și actualizează vizualizarea folosind modelul.
În mod ideal, vederea este complet separată de model și nu știe nimic despre model. Acest lucru vă permite să utilizați vizualizarea pentru a afișa alte date.
Utilizând MVC, obținem următoarele avantaje:
- o mai bună înțelegere a clasei;
- reutilizarea clasei, inclusiv în alte proiecte (în special pentru model și vizualizare);
- clase de testare separate unul de celălalt;
- în comparație cu alte modele, acest model este cel mai simplu și mai ușor de utilizat și, de asemenea, mai puțin costisitor din punct de vedere al timpului.
Dezavantajul MVC este că, în timp, în cazul în care proiectul este în creștere treptat și în schimbare, software-ul controler este în creștere și se poate ajunge la nivelul de 1000 de linii de cod în unele proiecte și mai mult, și mai mult și mai mult complică suportul pentru proiect: bagfiksing sau adăuga noi funcționalități. Din acest motiv, unii dezvoltatori „decoda“ acronimul MVC ca «masiv» ViewController :) Atâta timp cât facem un lucru, ne este frică să rupă ceva. Ca urmare, de lucru cu controlerul, dezvoltatorul nu poate evalua în mod corespunzător sarcina, nu se potrivesc în timpul specificat, își pierde încrederea și reputația de la clienți. Aici s-ar putea da vina pe client, pentru că:
- clientul nu dorește să înțeleagă cât de dificil este implementarea unui astfel de volum mare de funcționalități pe un singur ecran;
- clientul nu înțelege că nu este posibilă modificarea constantă a cerințelor în TK;
- clientul a încercat în repetate rânduri să explice că mai întâi trebuie să ne concentrăm pe UX, nu pe design-ul UI;
- dacă clientul de la începutul proiectului a indicat această funcție, atunci ar dura mult mai puțin timp ...
- optiunea ta :)
Dar toate acestea nu anulează faptul că situația se va repeta mereu.
Cum pot descărca ViewController?
Modelul MVP a evoluat de la MVC și constă din trei componente:
- Prezentator (intermediar independent al UIKit);
- Vizualizare pasivă (UIView și / sau UIViewController);
- Modelul.
Acest model definește Vizualizarea ca evenimente de primire UI de la utilizator și apoi apelează prezentatorul corespunzător, dacă este necesar. Prezentatorul este responsabil pentru actualizarea Vizualizării cu date noi din model.
Avantaje: o diviziune mai bună a codului, bine testată.
Dezavantaje: În relație cu MVC are mult mai mult cod, dezvoltare și suport necesită mai mult timp.
Acest model este util în proiecte care utilizează cadre, cum ar fi ReactiveCocoa i RxSwift, în care există conceptul de „legare de date“ - date cu caracter obligatoriu pentru elementele vizuale pe o bază bilaterală. În acest caz, utilizarea modelului MVC este foarte inconfortabil, deoarece datele cu caracter obligatoriu pentru vizualizarea (View) - aceasta este o încălcare a principiilor MVC.
Vizualizați (ViewController) și Model au un "intermediar" - Vizualizați modelul. Modelul de vizualizare este o vizualizare independentă de UIKit. Modelul de vizualizare invocă modificări ale modelului și actualizează el însuși modelul deja actualizat, iar din moment ce legarea are loc prin Vizualizare, vizualizarea este, de asemenea, actualizată.
Dezavantajul este că "în loc de 1000 de linii în ViewController 1000 linii din ViewModel pot ieși". De asemenea, una dintre problemele utilizării cadrelor pentru "programarea reactivă" este pur și simplu să rupă totul și poate dura mult timp pentru fixarea bug-urilor. Unii ar putea crede că RxSwift, de exemplu, simplifică scrierea codului, dar este suficient să examinăți stiva de apel a prietenului din metoda "rx-" pentru a evalua această "simplificare". Este posibil să adăugăm aici probleme cu documentația și probleme constante cu autocompletarea în xCode.
Viper (CleanSwift)
Interaporul conține logica de afaceri asociată cu datele (entități).
Prezentatorul conține logica de afaceri asociată cu interfața de utilizator (dar independentă de UIKit), apelând metode în Interaptor.
Entitățile sunt obiecte de date simple, nu sunt un strat de acces la date, deoarece aceasta este responsabilitatea Interaptor.
Router-ul este responsabil pentru tranzițiile dintre modulele VIPER.
Chiar și cu un astfel de studiu superficial, este evident că o mai bună împărțire a responsabilităților se obține printr-un număr mare de clase cu un număr mic de sarcini.