Ridică mâna dacă oricare dintre următoarele sună familiar: Gândește-te la formatarea codului. Scapă de inutil <div>și <span>‘s. Utilizați componente React funcționale. Încercați să evitați funcția săgeată în randare. Și nu te repeta!

Înainte de a merge direct la refactorizare, trebuie să răspundeți la o întrebare simplă: ce înseamnă să dezvolți o aplicație? De obicei, aceasta înseamnă producerea unui software care îndeplinește cerințele prin implementarea anumitor caracteristici.

Și cum facem asta? Colectăm cerințele clienților, le estimăm și dezvoltăm caracteristici una câte una, nu? Aproape.

Nu uitați de bug-uri

Da, apar erori. În funcție de procesul de dezvoltare, complexitatea software-ului, stiva tehnică și mulți alți parametri, numărul de erori poate varia.

O afacere nu își poate permite probleme critice în producție. Pentru a minimiza problemele, ar trebui să acordați o atenție deosebită Procesul QA. Dar teoria QA susține că este de obicei imposibil să rulați 100% acoperirea testului aplicațiilor dvs. și să vă pregătiți pentru toate scenariile posibile.

Totuși, pentru a obține rezultate optime, echipele petrec mult timp testând software-ul și rezolvând problemele. Aceasta este o parte necesară a procesului pe care fiecare client ar trebui să îl înțeleagă și să îl acorde prioritate.

Atenție la datoria tehnică

Cu toate acestea, această monedă are o față inversă. Cu cât durează mai mult procesul de dezvoltare și testare, cu atât veți avea mai multe datorii tehnice.

Deci, ce înseamnă „datorie tehnică”? Datoria tehnică se referă la toate problemele legate de calitate pe care le aveți în cod. Probleme care vor necesita cheltuirea resurselor suplimentare în viitor.

Aveți datorii tehnice din mai multe motive, cum ar fi:

  1. Compania împinge să lanseze noi funcții mai rapid.
  2. Testarea este insuficientă.
  3. Cerințele se schimbă rapid.
  4. Dezvoltatorii nu au experiență.

Datoria tehnică ar trebui să fie documentată. Dacă nu lăsați de făcut în cod, cel mai probabil veți uita de problemă. Și chiar dacă aveți timp pentru asta în viitor, nu vă veți aminti să o remediați.

Înțelegeți importanța refactorizării

De obicei, trebuie să petreceți ceva timp refacând codul existent pentru a rezolva problemele legate de calitatea codului și, astfel, pentru a reduce datoria tehnică.

Dar ce este refactorizarea? Este procesul de restructurare a codului existent fără a-i modifica comportamentul extern. Și acesta este de fapt ceva care ar putea fi dificil de înțeles pentru oamenii de afaceri care gestionează proiectul.

– Vom primi noi funcții?

– Nu.

– Vom remedia cel puțin niște bug-uri?

– De asemenea, nu.

– Ce vom primi atunci?

– …

Lucrul cu datorii tehnice ajută la evitarea erorilor. Și pentru a adăuga remedieri sau modificări la proiect, trebuie întotdeauna să citim vechiul cod.

Prin urmare, refactorizarea și menținerea unei bune calități a codului ne vor ajuta să menținem dezvoltarea într-un ritm bun.

Uneori, o afacere ar putea să nu aibă nevoie de ea. De exemplu, dacă lucrați la un prototip sau Dovada de concept, sau dacă există priorități de afaceri care nu pot fi ajustate, puteți face fără refactorizare.

Dar, în majoritatea cazurilor, eliminarea refactorizării nu este un lucru înțelept de făcut. S-ar putea să petreceți o cantitate uriașă de timp pe refactorizare dacă dezvoltatorii dvs. sunt perfecționiști, dar nici acest lucru nu are sens.

Prin urmare, trebuie să găsiți un echilibru. Nu ar trebui să petreceți mai mult timp refactorizând decât veți economisi în viitor.

Cum să începeți refactorizarea codului de reacție

Gândiți-vă la formatarea codului

Unele persoane adaugă virgule finale, iar altele nu. Unii folosesc ghilimele simple, în timp ce alții folosesc ghilimele duble pentru un șir.

Dacă lucrați în echipă, menținerea stilului de cod comun poate fi foarte dificilă. Și inconsecvența în stilul de cod poate face ca codul dvs. să pară murdar și greu de citit.

Deci, dacă nu v-ați gândit să folosiți instrumentele de formatare a codului înainte, este timpul să faceți acest lucru. Unul dintre cele mai populare și mai ușor de utilizat instrument de refactorizare React este Mai frumoasă. Puteți doar să-l adăugați la proiect și acesta se va ocupa de formatare pentru dvs.

Prettier are câteva setări de stil implicite, dar le puteți modifica în funcție de preferințe adăugând un .prettierrc fișier cu regulile de formatare.

O configurare bună de .prettierrc poate arăta astfel:

{ "printWidth": 120,  "singleQuote": true, “trailingComma”: “none” }

De asemenea, puteți reformata automat codul înainte de a vă angaja cu pre-comite cârlige.

Scăpați de

și ‘inutile

Când React 16.2 a fost lansat în noiembrie 2017, o mulțime de dezvoltatori React au oftat ușurați. Înainte de aceasta, pentru ca o componentă să returneze o listă de copii, era necesar să îi înfășurați într-un element suplimentar, cum ar fi <div> sau <span>.

Dar cu React 16.2 am primit un sprijin îmbunătățit pentru returnarea copiilor componentelor. Acum dezvoltatorii pot folosi așa-numitele fragmente. Arată ca niște etichete JSX goale (<> … </>). Cu ajutorul fragmentelor, puteți transmite o listă de copii către componentă fără a adăuga noduri suplimentare în DOM.

Gândește-te la nume

Nu vă lăsați când vă gândiți la nume pentru componente și variabile. Fiecare nume ar trebui să se explice de la sine.

Ați văzut vreodată fragmente de cod de acest gen?

const modifyData = data.map(x => [x.a, x.b]))

Ce face? Dacă nu puteți înțelege scopul unei variabile din numele ei, este timpul să o redenumiți!

Acest lucru vă va ajuta pe dvs. și echipa dvs. să înțelegeți mai ușor logica. De asemenea, va elimina timpul petrecut făcând modificări la componentele existente în viitor.

Nu te repeta

Principiul DRY a fost formulat pentru prima dată în carte Programatorul pragmatic. Se afirmă că „fiecare piesă de cunoaștere trebuie să aibă o reprezentare unică, fără echivoc, autoritară în cadrul unui sistem”. Cu alte cuvinte, trebuie să puneți blocuri de cod repetitive în componente separate reutilizabile.

Efectuarea codului uscat are multe avantaje. Vă poate economisi mult timp. Dacă trebuie să schimbați acest cod în viitor, veți face acest lucru doar într-un singur loc. De asemenea, nu va trebui niciodată să vă faceți griji că ați uitat să faceți modificări în unele locuri. În plus, veți menține componentele mai curate și veți spori lizibilitatea codului.

Pentru a vă menține componentele uscate și mici, puteți urma două reguli simple:

  1. Dacă utilizați un bloc de cod de mai multe ori, este timpul să îl extrageți.
  2. Dacă depășiți un număr predefinit de linii într-o componentă (de exemplu, 100 de linii), există probabil logică care poate fi extrasă. Împărțiți-l în componente mai mici după funcționalitate.

Utilizați componente funcționale peste clasă

Odată cu introducerea Hooks în React 16.8, am primit acces la caracteristicile clasei React din componentele funcționale. Cârligele rezolvă o grămadă de probleme întâlnite frecvent de dezvoltatori în ultimii ani.

De exemplu, useEffect hook, așa cum sugerează documentele React, ne permite să grupăm logica componentă în funcții mici bazate pe ce piese sunt legate (în loc să grupeze logica pe baza metodelor ciclului de viață). Acest lucru ne ajută să ne restructurăm mai bine logica.

Una peste alta, refacerea componentelor React cu ajutorul cârligelor face codul mai curat și reduce cantitatea de cod pe care trebuie să o scrieți.

Iată un exemplu foarte simplu: preluarea datelor după ce componenta a fost montată și recuperarea acestora pe baza elementelor de recuzită actualizate.

Într-o componentă de clasă, am scrie ceva de genul acesta:

class BookList extends React.Component {
  componentDidMount() {
    this.props.fetchBooks(this.props.bookGenre);
  }
  componentDidUpdate(prevProps) {
    if (prevProps.bookGenre !== this.props.booksGenre) {
      this.props.fetchBooks(this.props.bookGenre);
    }
  } 
// ... }

Cu React hooks va arăta astfel:

const BookList = ({ bookGenre, fetchBooks }) => {
  useEffect(() => {
    fetchBooks(bookGenre);
  }, [bookGenre]);
// ... }

Cartile care aduc logica sunt acum adunate într-un singur loc. useEffect cârligul va rula după montare de fiecare dată când recuzita [bookGenre] între paranteze drepte se schimbă. Mult mai curat, nu-i așa?

De asemenea, puteți extrage o logică similară și o puteți refolosi în diferite componente, creând cârlige personalizate. Puteți citi mai multe despre cârligele personalizate în oficial Reacționează documentația.

Încercați să evitați funcțiile săgeată în randare

Ați văzut vreodată cod de genul acesta ?:

render() {    
  return (
    <div>
      <button onClick={() => this.setState({ flag: true })} />
      ...      
    </div>    
  );  
}

Sigur că ai. Care este problema? De fiecare dată când o componentă este redată, se creează o nouă instanță a unei astfel de funcții.

Nu este mare lucru dacă componenta este redată de una sau de două ori. Dar, în alte cazuri, poate afecta cu adevărat performanța. Deci, dacă vă pasă de performanță, declarați funcția înainte de a o folosi în randare:

changeFlag = () => this.setState({ flag: true })
render() {    
  return (      
    <div> 
      <button onClick={this.changeFlag} />        
      ...      
    </div>    
  );  
}

Faceți pachetul mai mic

Dacă utilizați o bibliotecă terță parte, nu ar trebui să încărcați întregul lucru dacă nu este necesar. Uneori puteți da peste un import care folosește o singură metodă din bibliotecă, cum ar fi:

import lodash form 'lodash'  
...  
const certainProps = lodash.pick(userObject, ['name', 'email']);  ...

În schimb, este mai bine să utilizați următoarele:

import pick from 'lodash/pick' 
... 
const certainProps = pick(userObject, ['name', 'email']); ...

Acum nu încărcați întreaga bibliotecă, ci doar metoda de care aveți nevoie.

Pentru a încheia

Să trecem în revistă pașii pe care ar trebui să-i urmați pentru refactorizarea codului React:

  • Gândiți-vă la formatarea codului
  • Scapă de inutil <div>și <span>‘s
  • Gândește-te la nume
  • Nu te repeta
  • Utilizați componente funcționale peste clasă
  • Încercați să evitați funcțiile săgeată în randare
  • Faceți pachetul mai mic

Cu toate acestea, refactorizarea ideală este refactorizarea care nu are loc. Ca dezvoltator și mai ales ca lider tehnologic, ar trebui să vă gândiți la mulți pași înainte și să încercați să produceți cod de înaltă calitate. De asemenea, ar trebui să efectuați revizuiri regulate ale codului, nu numai în cadrul unei echipe, ci și între echipe.

Ai o idee pentru un proiect React?

Compania mea KeenEthics este un React cu experiență companie de dezvoltare. Dacă sunteți gata să schimbați jocul cu proiectul software, nu ezitați cere o estimare.

Puteți citi mai multe articole similare pe blogul meu Keen. Permiteți-mi să sugerez Valoarea testării utilizatorilor sau Angular vs React: ce să alegeți pentru aplicația dvs.?

Cel mai important, aș dori să le spun „mulțumesc” lui Yaryna Korduba și Max Fedas, ambii dezvoltatori remarcabili React, pentru coautorarea acestui articol, precum și a cititorilor pentru că au ajuns la final!