Menú

Refactorització de codi: què cal saber-ne

code refactoring what you need know about it

Proveu El Nostre Instrument Per Eliminar Problemes

Comprensió de la refactorització del codi: una perspectiva del provador

El terme 'refactorització' s'utilitza principalment per indicar la neteja / redisseny del codi necessari.

En aquest tutorial, comprendreem la definició de refactorització, discutirem la necessitat de refactoritzar el codi i revisarem l’impacte del codi de refactorització en diversos membres de l’equip del projecte. També discutirem la resposta a la pregunta més important: Com a provador, per què necessiteu saber sobre la refactorització?

A més, també parlarem d’alguns casos pràctics per aclarir el concepte.

Refactorització de codi

Què aprendreu:

Introducció a la refactorització

Per començar, entenguem primer què és realment la refactorització.

La refactorització és essencialment una pràctica o procés per millorar el codi i / o la base de dades mantenint la funcionalitat existent. La idea és transformar el codi ineficient i massa complicat en un codi més eficient, preferiblement més senzill i fàcil.

La refactorització del codi també ha agafat força amb més equips ara, seguint l’enfocament Agile Software Development. Sovint, els equips del projecte tenen un temps limitat per implementar nous o ampliar la funcionalitat de les funcions existents i del codi net. El codi que és fàcil d’entendre i mantenir, sens dubte, va molt per complir el termini d’iteració.

Necessitat de refactorització de codi

Si mantenim la funcionalitat original de l’aplicació o del mòdul, ens sorgeix una pregunta: Per què fins i tot ens molestem en la refactorització? Bé, hi ha moltes raons per les quals és possible que calgui refactoritzar un mòdul o un fragment de codi concret, com ara:

  1. El codi fa olor
  2. Deute tècnic
  3. Enfocament àgil de desenvolupament de programari, etc.

Tractarem aquests punts en detall a les seccions següents.

# 1) Olors de codi:

Tots podem entendre que, quan el menjar comença a olorar, indica que el més probable és que estigui malament, això també passa amb el codi. Les olors de codi indiquen que pot existir un problema molt greu al codi.

A continuació es mostren algunes olors de codi comuns:

  • Presència de codi redundant o idèntic.
  • Una variable declarada que no s'utilitza en cap lloc de la resta del codi.
  • Disseny de codi massa complicat.
  • Classe de codi que fa massa poc i no justifica l'existència de la classe definida. Aquestes classes es coneixen com a lazy class o freeloader.
  • L’existència de massa condicions i bucles que poden desglossar-se i simplificar-se.
  • Creació de codi de manera que un canvi en una part del codi requereixi que el canvi s’implementi també als altres llocs.

Les olors a codi es fan més evidents amb el pas del temps. A mesura que l’aplicació o el sistema creix, finalment aquestes olors de codi comencen a afectar el desenvolupament, el manteniment i fins i tot el rendiment del sistema en escenaris extrems.

# 2) Deute tècnic:

Mentre desenvolupem un programari, durant el limitat temps i els recursos disponibles, sovint podem prendre dreceres per aconseguir els resultats desitjats.

Penseu en una característica que cal afegir a un mòdul existent. Després de la discussió, l'equip redueix 2 enfocaments per afegir aquesta funció. L’aproximació A, triga dos sprints a realitzar, serà l’enfocament aprovat a llarg termini. L'aproximació B només triga 5 dies a lliurar-se, és un hack desordenat i codificat que està dissenyat per donar servei al mòdul a curt termini.

Si l’equip està pressionat per oferir la funció en un termini limitat, és possible que accepti seguir l’enfocament B per ara i afegir l’enfocament A a l’endarreriment per al futur. Fent això, aquest equip acaba de crear-se el deute tècnic per si mateixos.

En termes senzills, el deute tècnic en el desenvolupament de programari es refereix a la reelaboració o despeses addicionals necessàries per establir les correccions adequades o fer les coses de la manera correcta.

Els sistemes heretats tendeixen a adquirir un enorme deute tècnic amb el pas del temps, que al seu torn pot fer que l’aplicació sigui susceptible de fallar i sigui difícil de suportar i mantenir.

Llegeix més=> Què és el Departament Tècnic?

# 3) Seguiment de l'enfocament de desenvolupament de programari àgil:

L’enfocament àgil de desenvolupament de programari defensa el desenvolupament incremental. Sense un codi net, ben estructurat i fàcil de mantenir, els equips no podrien ampliar el codi existent amb cada iteració. Si es canvia el codi sense una refactorització adequada, pot contribuir a olors de codi o deute tècnic.

Aquesta relació es representa al diagrama següent

Enfocament de desenvolupament de programari àgil

Lectura recomanada => Principals eines d'anàlisi de codi

Per què cal saber un QA sobre la refactorització?

Tot el que hem comentat fins ara en aquest tutorial sembla estar relacionat amb la codificació i sembla el tipus de coses que un desenvolupador hauria de preocupar-se.

Llavors, per què discutim aquest concepte no relacionat a la comunitat d’ajuda de proves de programari? Continueu llegint la resta d’aquest tutorial per obtenir la resposta a aquesta pregunta.

# 1) Per a verificadors / desenvolupadors d’unitats

Mentre es refactoritza el codi, a mesura que s’insereix un codi nou, s’actualitzen classes antigues, s’afegeixen classes noves i és possible que les proves d’unitats existents fallin. A més, per als sistemes antics, és possible que no hi hagi cap prova unitària implementada. En la majoria dels casos, caldrà crear i configurar aquestes noves proves unitàries des de zero.

# 2) Per als provadors

Quan s’està refactoritzant una característica (tenint en compte que no afegirem cap nova funcionalitat), s’entén que després de fer els canvis necessaris, la majoria de la funcionalitat de l’usuari final hauria de seguir sent la mateixa.

  • Com a provador, la refactorització del codi es tradueix aproximadament en = proves en profunditat + proves de regressió. Les proves en profunditat han d’incloure tots els fluxos d’usuaris existents per assegurar-se que totes les funcionalitats funcionen com abans. Proves de regressió de tota l'aplicació (o de les zones afectades) és necessària per assegurar-se que l'actualització d'un mòdul no ha trencat sense voler la funcionalitat dels altres mòduls.
  • Les proves d’acceptació d’usuaris seran importants i aquestes proves han de passar abans que la versió es pugui declarar llesta per a la publicació.
  • A més, cal fer qualsevol altra prova, com ara proves de càrrega, prova de seguretat etc. també caldria implementar-lo segons sigui necessari.

# 3) Enginyers de proves d'automatització

La refactorització del codi pot provocar un error en els scripts d'automatització funcionals i no funcionals.

Això pot passar per les raons següents:

  • Si els objectes de pàgina canvien com a part de l'esforç de refactorització i si els vostres scripts d'automatització de Selenium es basen en els objectes de pàgina, els scripts fallaran i caldria actualitzar-los.
  • Si hi ha hagut canvis menors, redirigeix ​​els que s’han afegit o eliminat durant la refactorització i els scripts d’automatització existents fallarien i s’haurien d’actualitzar

Es recomana que les proves d'automatització funcional només es configurin un cop una característica sigui estable, en cas contrari, es produirà molta reelaboració a mesura que la funció evolucioni.

Com que són desenvolupadors de proves d'automatització, els enginyers de proves d'automatització també han de pensar com a desenvolupadors i volen crear un codi net i fàcil de mantenir. La majoria dels IDE, com IntelliJ IDEA, Eclipse, etc., inclouen un menú de refactorització integrat amb mètodes de refactorització que s’utilitzen habitualment per facilitar la consulta.

A continuació es mostra una captura de pantalla del menú de refactorització a IntelliJ IDEA (Community Edition).

preguntes d’entrevistes per a desenvolupadors de .net

menú de refactorització

# 4) Per a contactes de prova / contactes de control de qualitat

  • Pot ser que els proveïdors de prova / de control de qualitat treballin juntament amb la resta de l'equip, inclosos els desenvolupadors, l'analista de productes i potser fins i tot els grups d'interès, per garantir que la planificació de proves per a aquests projectes es faci amb cura.
  • És important entendre la funcionalitat existent. Basant-se en la funcionalitat existent, cal documentar casos empresarials, fluxos d’usuaris i proves d’acceptació d’usuaris. Quan s’està provant un codi refactoritzat, cal validar tots aquests escenaris, juntament amb proves de regressió de les zones afectades.
  • Sigueu proactiu mentre planifiqueu l'enfocament de la prova i plans de prova . Si preveieu el requisit de diversos entorns de prova o noves eines de prova, envieu la sol·licitud abans d’hora per evitar retards un cop comenci la fase de prova.
  • No dubteu en involucrar membres de l’equip que no siguin del projecte o usuaris finals per contribuir a les proves.

Estudis de casos

Ara parlarem d'alguns estudis de casos reals en els quals vaig tenir l'oportunitat de treballar directament o de contribuir indirectament.

Estudi de cas núm. 1

Tasca: Refactoritzar un mòdul per substituir els valors codificats per variables i afegir comentaris per a la nova eina automatitzada de generació de documentació tècnica.

Desafiaments :No hi ha reptes importants. El mòdul era nou, tenia requisits documentals d’acceptació funcionals i funcionals, fluxos d’usuaris i casos de proves. Les proves d’unitat es van configurar durant el propi llançament inicial.

Enfocament de la prova :Es van executar els casos de prova del mòdul que es va refactoritzar i les zones afectades relativament conegudes. Qualsevol defecte es va informar i resoldre abans de la publicació.

Estudi de cas núm. 2

Tasca :Refactoritzar el procediment emmagatzemat existent per facilitar l’augment de l’aplicació.

El procediment emmagatzemat en aquest escenari era un procediment emmagatzemat anterior que es va dissenyar fa uns anys, tenint en compte el requisit que l’aplicació utilitzava el seu procediment emmagatzemat com a aplicació interna amb menys de 10 sessions simultànies.

Ara la companyia volia comercialitzar aquesta aplicació com a programari com a servei (SaaS), amb el volum previst de 300 sessions simultànies inicialment.

L’equip va fer algunes proves inicials de càrrega i va concloure que el sistema es trenca amb una càrrega de 25 sessions simultànies. L’equip va revisar el codi i va recomanar refactoritzar un procediment emmagatzemat bàsic existent que permetés a l’aplicació ampliar i donar suport a fins a 500 sessions simultànies sense interrupcions.

Alguns problemes identificats amb aquest procediment emmagatzemat eren múltiples subquestions dins d'una sola consulta, combinacions pesades amb vistes en lloc de taules, ús de select * en lloc de seleccionar una columna específica, etc. A causa d'aquests problemes de codificació, l'aplicació va obtenir més dades que aquella era realment necessari, cosa que provocava que l’aplicació es ralentís i, finalment, fallés.

Desafiaments:

# 1) Cap de projecte / analista de productes

  • Reunió de requisits - Com que aquest procediment emmagatzemat era un codi heretat, no hi havia requisits documentats per a ell quan es va dissenyar el mòdul per primera vegada. També per a les iteracions realitzades durant els darrers anys, no hi va haver cap registre de canvis que indiqués les regles i la lògica empresarials afegides o eliminades del mòdul.
  • Calendari del projecte - Atès que els requisits no estaven clarament definits i les dependències del codi encara no estaven completament identificades, era difícil comunicar el calendari provisional.

# 2) Per a desenvolupadors

  • Manca de requisits i regles empresarials clares.
  • Neteja del codi sense perdre la seva funcionalitat.
  • Àrees afectades desconegudes i / o dependències de codi.
  • No es poden proporcionar estimacions concretes de temps de desenvolupament.
  • Cal crear noves proves d’unitat.

# 3) Per als provadors

  • La manca de requisits clars i la planificació de les proves d’impacte de les normes empresarials.
  • Planificació de proves d'impacte d'àrees afectades desconegudes, específicament per a proves de regressió.
  • No es poden proporcionar estimacions concretes de proves.

# 4) Interessats

  • Manca de requisits documentats clars i / o fluxos d’usuaris + terminis ajustats = Major risc de fallada.

L'enfocament seguit per l'equip per mitigar els riscos i solucionar els reptes :

(i) L'equip va seguir un enfocament col·laboratiu per reunir els requisits : El cap de projecte / analista de productes i provadors van treballar estretament amb els usuaris finals interns per comprendre i documentar les principals funcionalitats i flux d'usuaris.

Els desenvolupadors també van revisar el codi i van afegir informació rellevant al document de requisits. Això es va fer abans del dia d’inici del sprint.

(ii) L'entorn de prova alternatiu es va crear per provar el canvi que s'està implementant : Anomenem aquests entorns com Gamma i Phi. Gamma tindria l'antic codi i Phi tindria l'últim procediment emmagatzemat refactoritzat desplegat en tot moment.

Tenir 2 entorns de prova en paral·lel, gairebé recrear-se abans i després de l’aproximació, va permetre a l’equip fer proves més profundes i exploratives comparant el comportament d’aquests 2 entorns de prova, van ser capaços d’identificar els errors probables.

L'equip va proporcionar els requisits per a un entorn de prova alternatiu que es proporcionava abans de la data d'inici del sprint.

(iii) Usuaris finals i grups d'interès implicats en les proves inicials : Qualsevol problema evident es va detectar i es va informar al principi quan es va permetre a l'equip disposar de més temps per implementar i provar la solució necessària.

(iv) Definir criteris de sortida i complir-los: Els criteris de sortida es van definir en les etapes inicials de planificació: es van provar el 80% dels fluxos d'usuaris, no es va resoldre cap error crític, es va fer una demostració i es va tancar la sessió dels grups d'interès abans de la publicació.

(v) Establir una data de llançament provisional: Establir una data de llançament alineada i motivar l’equip a treballar cap a un punt final comú. Basant-se en l’abast del projecte, l’equip va recomanar que es seguís un sprint de 3 setmanes en lloc d’un sprint normal de 2 setmanes per donar temps suficient a l’equip per executar el projecte.

Conclusió

En resum, la refactorització del codi és un procés per netejar / simplificar el disseny d’un mòdul sense canviar-ne la funcionalitat. El procés de refactorització pot ser senzill, com afegir comentaris, afegir sagnat correcte, eliminar una variable estàtica, etc. o pot ser complicat per a sistemes heretats complexos.

Pot ser que s’hagi de refer un mòdul o un fragment de codi en particular a causa de les olors del codi, del deute tècnic o seguint un enfocament àgil de desenvolupament de programari.

Per als verificadors, la refactorització del codi es tradueix aproximadament en = proves en profunditat + proves de regressió.

Es requereixen proves en profunditat per provar tots els fluxos d’usuaris existents per garantir si totes les funcionalitats funcionen com abans. Cal fer proves de regressió de tota l’aplicació (o de les àrees afectades) per assegurar-se que l’actualització d’un mòdul no ha trencat sense voler la funcionalitat dels altres mòduls.

Es pot requerir que els potencials de prova / de control de qualitat treballin juntament amb la resta de l'equip, inclosos els desenvolupadors, analista de productes, especialment per a projectes antics. Sigues proactiu mentre planifiques l’enfocament i els plans de prova. Si preveieu el requisit de diversos entorns de prova o noves eines de prova, envieu la sol·licitud aviat per evitar retards un cop comenci la fase de prova.

Sobre l'autor: Aquest tutorial informatiu està escrit per Neha B. Actualment treballa com a gerent d’assegurament de la qualitat i està especialitzada en liderar i gestionar equips de control de qualitat interns i externs.

Heu treballat en un projecte desafiant que implicava refactoritzar codi o un mòdul / aplicació? Si és així, no dubteu a compartir les vostres experiències a la secció de comentaris per aprendre dels nostres companys de prova.

Lectura recomanada

^