'Y'

Arhitectura software, refactoring si ce este de fapt important. Partea a doua

In prima parte a articolului am discutat despre cum sa ne dam seama daca refactoring este util, ce ne ofera dar si consecintele. Haideti sa continuam discutia.

Apr 11, 2018 890
In prima parte a articolului am discutat despre cum sa ne dam seama daca refactoring este util, ce ne ofera dar si consecintele. Haideti sa continuam discutia.

Ce ar trebui sa fie facut pentru a nu apela din nou la refactoring pe viitor sau “Do it well to make it good”

Managerii intreaba de multe ori daca este vreodata posibil sa fie dezvoltat un sistem fara bug-uri. Bineinteles ca se poate, dar necesita foarte mult timp. Lucrez in industria de sfotare development de foarte multi ani si am observat ca in cele mai mutle cazuri dezvoltarea este una evolutiva si daca ne uitam la modul in care un sistem de operare dezvoltat de o companie de renume functioneaza vedem ca fiecare al doilea produs are succes.

Nu prea avem cum sa evitam erorile dar putem sa controlam volumul lor facand anumit pasi:

  • Folosirea unit si automated testing
  • Implementarea BDD
  • Sa lucram cu functionalitati mai putin complexe, sa introducem modificari mai mici, simplificand astfel sistemul
  • Sa facem refactoring dar de dimensiuni mai mici, regulat asa cum am face curat in casa
  • Sa responsabilizam echipa care dezvolta sistemul
  • Sa oferim acces la o functionalitate schimbata / noua unui numar limitat de stakeholderi astfel incat sa identificam problemele de mai devreme
  • Sa incepem sa folosim abordari unificate de arhitectura software pentru a limita diversitatea de solutii tehnice
  • Sa introducem si sa ajustam procedura de supervizare tehnica inainte de a fi dezvoltata o noua functionalitate sau de a face modificari.
  • Facilitarea unei revizuiri a arhitecturii si o monitorizare a solutiilor, notarea rezultatelor si generarea de recomandari
  • Introducerea unor metrici care sa evidentieze complexitatea si calitatea codului – si evident monitorizarea acestora

Din experienta mea stiu ca nu putem evita refactoring dar putem reduce impactul negativ folosind pasii de mai sus.

Daca trebuie sa rescrii codul, care va fi planul tau?

In momentul in care ai primit permisiunea de a face refactoring, ar trebui sa iti rogi echipa sa ofere:

  • O lista de actiuni care trebuie facute si o lista de metrici care ar trebui imbunatatiti
  • O propunere/draft de arhitectura care trebuie atinsa
  • Performance time schedule
  • O lista de riscuri
  • Tactici de management al riscului
  • Un plan in cazul in care nu se poate finaliza refactoringul; trebuie sa existe un plan in caz ca lucrurile nu merg

Vreau sa evidentiez faptul ca echipa ar trebui sa faca refactoring-ul pentru a fi implementat in sistem chiar si sub forma incompleta fara a-l afecta. In acest caz inginerii isi vor face treaba mult mai responsabil.

Alte recomandari pentru refactoring ar mai fi:

  • Separarea codului in mai multe layere
  • Respectarea arhitecturii
  • Dezvoltarea de componente/sisteme intr-un mod compact; incercati sa le faceti si interschimbabile
  • Reducerea legaturilor intre sisteme
  • Scrierea de cat mai multe teste posibil
  • Mergeti pe legaturi intre sisteme care sa fie in concordanta cu “protocoalele/interfetele” comune

P.S.

Ideile din acest articol par a fi de bun simt dar vad de multe ori ingineri care au fost entuziasmati de refactoring si nu au avut succes in aplicarea lui. Nu sunt impotriva refactoring dar vreau sa fie de succes. Daca nu se face un release datorita unui refactoring care s-a lungit, va fi foarte dificil ca asa ceva sa mai fie acceptat pe viitor. Ar fi mai bine sa finalizati un refactoring mai simplu, sa aratati ca aceasta procedura este in regula si sa capatati increderea clientului – apoi va fi mult mai usor sa obtineti permisiunea pentru astfel de activitati pe viitor.

Descopera cursurile noastre de Code Refactoring si Arhitectura Software.

Ivan Alyakskin 
Software Consultant

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.