Assessorament sobre com gestionar el codi llegat

La icònica APPLE MACINTOSH 128K

Quan apareix el terme "codi llegat", se sol dir o rebre amb una molèstia de menyspreu. Una cerca preliminar de Google per a "memes de codi heredat" reuneix centenars i centenars de macros d'imatge de persones que es rasguen els cabells, semblen incomodades o molt decebudes.

Quan vaig començar a treballar com a desenvolupador de programari, fa 5 mesos en una empresa basada en productes, no tenia ni idea de què era el codi llegat ni el que comportava.

Durant el quart mes, se’m va sol·licitar afegir un mòdul de filtre de canvi a una aplicació construïda per un dels meus companys de feina fa dos o tres anys. Semblava prou fàcil; He passat la majoria dels últims tres anys treballant en una aplicació molt complexa que inclou la pila estàndard: TypeScript / React / Angular / Dotnet. Ja havia resolt molts problemes únics i em sentia confiat en la meva capacitat de codificació per fer un modal simple per passar els paràmetres de consulta al backend.

Com heu pogut endevinar, no va ser gaire senzill. Però perquè?

Què és el codi llegat i per què pot ser difícil tractar

El codi llegat és el codi heretat d'un altre desenvolupador o equip que utilitza tecnologies més antigues que ja no són compatibles o que han estat substituïdes per una versió més recent. Molts programadors diuen que “el codi es converteix en el llegat tan aviat com s’escriu”. La diferència funcional entre el codi "regular" i el codi llegat podria ser simplement que té convencions diferents en comparació amb el que estàs treballant.

En el meu cas, l'aplicació utilitzava les plantilles de text XAML i T4 en lloc del codi C # bàsic, i no estava tan fort com ara estava acostumat. Això em va fer una mica més difícil entendre l’estructura de les dades. Cap tipus va significar que jo estava executant-me amb TypeErrors en temps d'execució molt més freqüent, cosa que pot ser difícil de depurar quan escriviu una característica gran. A més d'això, l'aplicació utilitzava una versió molt més antiga de dotnet, que calia conciliar amb una versió compatible de la biblioteca de components.

Abans d’afrontar-me a l’incentiu de com gestionar el codi heretat amb un sentit de pes i racionalitat, vull afegir una renúncia que el codi llegat no està malament i treballar en un projecte llegat no ha de ser terrible. Al contrari, el fet de treballar amb el codi llegat em va ensenyar a ser flexible, pacient i, sobretot, l’experiència em va permetre resoldre problemes amb una nova perspectiva en un context nou.

De fet, em va fer ser un desenvolupador millor del que era abans de començar a treballar a través de l’esmentada base de codis i, tant de bo, el vostre projecte llegat també us pugui ensenyar alguna cosa.

Com fer front al codi heretat a nivell tècnic

Llegiu la documentació i els comentaris de codi quan sigui possible

En un món perfecte, cada base de codi compta amb un robust README que conté explicacions concises sobre com funciona el projecte, comentaris de codi que expliquen la lògica exacta de l’autor original i tota l’aplicació té sentit. Tot i això, poques vegades és així. Molts READMEs no s’actualitzen a mesura que es desenvolupen els projectes, la gent s’oblida d’escriure comentaris, suposa que la seva lògica és òbvia per a un nou desenvolupador o simplement s’executen amb el temps per tenir cura d’aquestes coses.

Mireu la base de codis en conjunt

Si us heu perdut i no sabeu per on començar, poseu-vos aquestes preguntes:

  • Quin és l’objectiu de l’aplicació?
  • Com flueixen les dades a través de l'aplicació?
  • Com entra la vostra funció a l’aplicació?

Quan pugueu tenir una idea de la imatge gran, és més fàcil comprendre quina és la millor solució per afrontar el problema. Potser necessiteu crear un fitxer nou i crear un controlador nou. Potser haureu d’escriure una funció d’utilitat i provar-la. Sigui quin sigui el cas, comprendre el context més ampli del problema és un bon pas per crear una solució.

Prova l'aplicació manualment i amb proves d'unitats sempre que sigui possible

Fer trencar una aplicació temporalment mentre afegir una nova característica és una inevitabilitat, sigui quin sigui el nivell de desenvolupador que siguis. Això és normal i s’espera, sobretot si ets nou a la feina, treballant en una base de codis antigues amb una pila desconeguda o amb alguna combinació d’aquests.

La millor manera d’evitar que aquestes ruptures es converteixin en problemes a llarg termini és provar a fons l’aplicació tant amb proves d’unitats com amb proves manuals. Si teniu aquestes proves al seu lloc i sabreu exactament quin tipus de cobertura obtindreu, us estalviareu molt de temps i els futurs desenvolupadors. A més, les proves rigoroses fan que l'aplicació sigui més escalable i també us proporciona una mica de pressa de dopamina cada vegada que les proves es netegen. Malauradament, hi ha casos de prova d’unitat limitats al meu escenari

Per a les proves manuals, voldreu desenvolupar una matriu de proves i assegureu-vos que el document sigui accessible als futurs desenvolupadors. Per a la matriu, voldreu definir un conjunt d’accions, el comportament esperat, el comportament real en provar-lo i qualsevol altre detall important, com ara:

Demanar ajuda

Suposant que el vostre projecte hagi estat escrit per un empleat actual o antic del vostre lloc de treball, probablement algú més sap el que passa a l'aplicació, o almenys sap prou com per desfer-vos. Aprendre a empassar el vostre orgull i demanar a algú altre és un pas incòmode per a alguns, però necessari per créixer com a desenvolupador, i potser el vostre company de feina us pot ensenyar alguns trucs nous.

Una bona manera de fer un ús eficient del vostre temps (i el seu) és formular preguntes informades. Proveu de tornar a veure la base de codis en general i esbrineu els buits que enteneu. No només els ajudarà a entendre millor quin és el vostre problema, sinó que demostra que heu pres la iniciativa d’intentar resoldre el problema pel vostre compte.

Saber quan haureu de reduir les pèrdues

Si dediqueu massa temps a intentar posar el peu a la porta i no heu avançat cap a l'implementació de la funció després d'haver intentat els passos anteriors, potser val la pena tornar a executar el codi al voltant de la vostra funció. No renunciïn massa fàcilment, però també tingueu en compte quins són els vostres terminis i el que espera el vostre responsable de projecte.

Dit això, hi ha inconvenients de seguir així:

  • El codi de reescriptura pot introduir errors, encara que es pot evitar amb una bona prova de les unitats.
  • El codi de reescriptura pot eliminar la funcionalitat oculta, tot i que també es pot eludir amb bones proves d'unitats.
  • Si teniu premut el temps, escriure codi fora de la vostra funció, a més de la característica, pot costar més temps que simplement crear-lo al voltant.

En definitiva, utilitzeu el vostre millor judici. Hi ha avantatges i contres per a qualsevol opció i tot depèn de les circumstàncies i del pressupost del projecte.

Com fer front al codi llegat a nivell psicològic

Ara que hem tractat els aspectes tècnics de la gestió del codi heretat, parlem de com afrontar-lo mitjançant les nostres habilitats suaus. Al cap i a la fi, els desenvolupadors són persones, no només codificant robots, i fer front a problemes difícils en projectes que requereixen creativitat i autoritat pot ser un impost emocional, no només per a vosaltres, sinó també per als vostres col·laboradors.

Sigui humil i amable

Això és una cosa que reconèixeré que he de practicar més. Quan se'm va assignar el projecte modal del filtre per primera vegada, em va mostrar una bona vocació sobre la manera de tractar el codi descarat i desaparèixer mentre l'autor original del codi estava a 15 metres de distància de mi. Tenia la intenció que els meus comentaris fossin una broma, però, a la vista posterior, reconec que em sentia arrogant i dolent i que devia ser més empàtic.

Hi ha molts factors que poden conduir a que el codi heretat es vegi “fora” que heu de tenir en compte abans de començar a criticar l’autor o assumir el pitjor d’ells (Això està lligat a l’error fonamental d’atribució!).

És possible que l’autor original hagi tingut les seves raons per escriure codi de la manera que ho feia.

Les limitacions de temps i les limitacions tecnològiques poden fer que una persona escrigui codi que funcioni, però no necessàriament té la millor convenció. Si us penseu en una situació amb temps, amb eines obsoletes i una llista de milla de llarg, probablement tampoc escriviu el millor codi.

Canvien les convencions.

En projectes anteriors, la convenció per a codis utilitza cometes simples per declarar cadenes, i dos espais eren iguals a una pestanya. Teníem diverses classes petites petites inserides en un sol fitxer. En la nostra convenció actual, utilitzem cometes dobles i quatre espais, i cada classe, per petita que sigui, viu al seu propi fitxer .cs al directori Models. I en diversos anys, estic segur que també canviarà.

Tot el codi esdevé llegat

Això es relaciona amb el punt anterior: el vostre codi acabarà sent heretat. A mesura que augmenteu l'escala de l'antiguitat, els nous desenvolupadors es contractaran i hauran de mantenir el vostre codi antic. És possible que escrigueu un codi sec, impecable i sec, però, un cop canvien les convencions o canvien les tendències, els nous desenvolupadors podrien veure el codi de la mateixa manera que visualitzeu el codi heretat d'altres.

Enorgulleix-te dels petits èxits

No és fàcil treballar fora de les convencions habituals; hi ha una raó per a la gran quantitat de memes i acudits sobre com tractar el codi llegat. Si alguna vegada heu après un idioma fora de la vostra llengua materna, ja sabeu com se sent que oblideu una paraula o un terme en la segona llengua, però recordeu-lo en la vostra llengua materna i no pugueu traduir-los per qualsevol altre espai. El mateix passa amb el canvi entre les convencions modernes i les heretades. De vegades només cal trigar un minut a recuperar els seus coixinets.

Per poder navegar amb èxit amb el codi heretat, mostreu la vostra capacitat de ser adaptable, la qual cosa és una habilitat important que us beneficia al vostre lloc de treball actual i a tots els vostres futurs treballs, tant si són dins del camp tecnològic com si no. El codi llegat és el terreny de joc perfecte per practicar aquesta habilitat.

En conclusió

Utilitzeu aquest temps per reforçar la vostra escriptura de codi

Ara que heu tingut l'experiència de treballar en una base de codis, heu d'afegir-la amb un millor sentit del que us agrada i no us agraden quant a eines i convencions. Són coses a les que podeu dur a terme els projectes futurs i us permetran millorar el revisió del codi d’altres persones, oferir crítiques constructives i donar consell.

Desenvolupar aplicacions per a l’usuari i el futur desenvolupador

Tant si teniu experiència de gran documentació i comentaris de codi, com si no teniu comentaris de documentació o codi, podeu veure com la documentació i els comentaris són eines potents per ajudar els futurs desenvolupadors a navegar pel projecte. Compartiu un objectiu comú de desitjar una aplicació fluida, funcional i seca; mantenir la documentació i deixar enrere comentaris de codi informatiu és una bona manera de suprimir aquest buit.

Recordeu que el vostre codi serà llegat també algun dia

Ja ho he esmentat algunes vegades, però és important reiterar que el vostre codi serà també heretat, per molt que siguin secs i prístics del vostre codi i lògica.

El més important és ser flexible, humil i, sens dubte, que podeu aprendre nous trucs a partir del codi antic.