Des de principis de 2018, ocupo el càrrec de desenvolupador principal/cap/desenvolupador principal a l'equip; digueu-lo com vulgueu, però la qüestió és que sóc totalment responsable d'un dels mòduls i de tots els desenvolupadors que treballen. sobre ell. Aquesta posició em dóna una nova perspectiva sobre el procés de desenvolupament, ja que estic involucrat en més projectes i més activament en la presa de decisions. Recentment, gràcies a aquestes dues coses, de sobte em vaig adonar de com la mesura de la comprensió afecta el codi i l'aplicació.
El punt que vull destacar és que la qualitat del codi (i del producte final) està estretament relacionada amb el grau de consciència del que estan fent les persones que estan dissenyant i escrivint el codi.
Potser esteu pensant ara mateix: "Gràcies, Cap. Per descomptat, estaria bé entendre el que esteu escrivint en general. En cas contrari, també podríeu contractar un grup de micos per tocar tecles arbitràries i deixar-ho". I tens tota la raó. En conseqüència, doc per fet que t'adones que és necessari tenir una idea general del que estàs fent. Això es pot anomenar el nivell zero de comprensió, i no ho analitzarem en detall. Veurem amb detall què necessites entendre exactament i com afecta les decisions que prens cada dia. Si hagués sabut aquestes coses per endavant, m'hauria estalviat molt de temps perdut i codi qüestionable.
Tot i que no veureu una sola línia de codi a continuació, encara crec que tot el que es diu aquí és de gran importància per escriure codi expressiu i d'alta qualitat.
Primer nivell de comprensió: per què no funciona?
Els desenvolupadors acostumen a arribar a aquest nivell molt al començament de la seva carrera, de vegades fins i tot sense cap ajuda dels altres, almenys segons la meva experiència. Imagineu que heu rebut un informe d'error: alguna funció de l'aplicació no funciona, s'ha de solucionar. Com procediràs?
L'esquema estàndard és el següent:
- Trobeu el fragment de codi que està causant el problema (com fer-ho és un tema a part, el cobreixo al meu llibre sobre el codi heretat)
- Feu canvis en aquest fragment
- Assegureu-vos que l'error estigui solucionat i que no s'hagi produït cap error de regressió
Ara centrem-nos en el segon punt: fer canvis al codi. Hi ha dos enfocaments d'aquest procés. El primer és aprofundir en què passa exactament al codi actual, identificar l'error i solucionar-lo. En segon lloc: moure's amb la sensació: afegiu, per exemple, +1 a una declaració condicional o un bucle, mireu si la funció funciona en l'escenari desitjat i, a continuació, proveu una altra cosa, i així successivament fins a l'infinit.
La primera aproximació és correcta. Com explica Steve McConnell al seu llibre Code Complete (que us recomano molt, per cert), cada vegada que canviem alguna cosa al codi, hauríem de poder predir amb confiança com afectarà l'aplicació. Estic citant de memòria, però si una correcció d'errors no funciona com esperaves, hauríeu d'estar molt alarmat i hauríeu de qüestionar tot el vostre pla d'acció.
Per resumir el que s'ha dit, per tal de realitzar una bona correcció d'errors que no degradi la qualitat del codi, cal entendre tant l'estructura completa del codi com l'origen del problema específic.
Segon nivell de comprensió: per què funciona?
Aquest nivell s'entén de manera molt menys intuïtiva que l'anterior. Jo, encara que era un desenvolupador novell, ho vaig aprendre gràcies al meu cap i, posteriorment, vaig explicar repetidament l'essència de l'assumpte als nouvinguts.
Aquesta vegada, imaginem que heu rebut dos informes d'error alhora: el primer és sobre l'escenari A, el segon és sobre l'escenari B. En ambdós escenaris, passa alguna cosa malament. En conseqüència, primer abordeu el primer error. Utilitzant els principis que hem desenvolupat per a la comprensió del nivell XNUMX, aprofundeixeu en el codi rellevant per al problema, esbrineu per què fa que l'aplicació es comporti com ho fa a l'escenari A i feu ajustos raonables que produeixin el resultat que voleu. . Tot va molt bé.
Després passes a l'escenari B. Repetiu l'escenari per intentar provocar un error, però... sorpresa! —Ara tot funciona com cal. Per confirmar la vostra conjectura, desfeu els canvis que heu fet mentre treballava amb l'error A i l'error B torna. La vostra correcció d'errors va resoldre tots dos problemes. Sort!
No comptaves gens amb això. Heu trobat una manera d'arreglar l'error a l'escenari A i no teniu ni idea de per què va funcionar per a l'escenari B. En aquesta etapa, és molt temptador pensar que ambdues tasques s'han completat amb èxit. Això és força lògic: la qüestió era eliminar errors, no? Però la feina encara no s'ha acabat: encara heu d'esbrinar per què les vostres accions han corregit l'error de l'escenari B. Per què? Perquè pot estar treballant en principis equivocats, i llavors haureu de buscar una altra sortida. Aquí teniu un parell d'exemples d'aquests casos:
- Com que la solució no es va adaptar a l'error B, tenint en compte tots els factors, és possible que sense saber-ho hàgiu trencat la funció C.
- És possible que també hi hagi un tercer error a l'aguait en algun lloc, relacionat amb la mateixa funció, i la vostra correcció d'error en depèn per al correcte funcionament del sistema a l'escenari B. Ara tot sembla bé, però un dia aquest tercer error es notarà i es solucionarà. Aleshores, a l'escenari B, l'error es tornarà a produir, i és bo encara que hi hagi.
Tot això afegeix caos al codi i algun dia et caurà al cap, probablement en el moment més inoportú. Haureu de reunir la vostra força de voluntat per forçar-vos a dedicar temps a entendre per què sembla que tot funciona, però val la pena.
Tercer nivell de comprensió: per què funciona?
La meva visió recent es relaciona precisament amb aquest nivell, i probablement és el que m'hauria donat més benefici si hagués arribat a aquesta idea abans.
Per fer-ho més clar, mirem un exemple: el vostre mòdul s'ha de fer compatible amb la funció X. No esteu especialment familiaritzat amb la funció X, però us van dir que per ser compatible amb ella heu d'utilitzar el framework F. Altres els mòduls que s'integren amb X funcionen exactament amb ell.
El vostre codi no ha estat en contacte amb el framework F des del primer dia de la seva vida, de manera que implementar-lo no serà tan fàcil. Això tindrà conseqüències greus per a algunes parts del mòdul. No obstant això, us llances al desenvolupament: passes setmanes escrivint codi, provant, llançant versions pilot, obtenint comentaris, corregint errors de regressió, descobrint complicacions imprevistes, no complint els terminis acordats originalment, escrivint més codi, provant, obtenint una comunicació amb comentaris, corregir errors de regressió, tot això per implementar el marc F.
I en algun moment us adoneu de sobte, o potser escolteu algú, que potser el marc F no us donarà compatibilitat amb la funció X. Potser tot aquest temps i esforç s'han dedicat completament a això.
Una cosa semblant va passar una vegada mentre treballava en un projecte del qual era responsable. Per què va passar això? Com que entenia poc quina era la funció X i com es relacionava amb el marc F. Què hauria d'haver fet? Demaneu a la persona que assigna la tasca de desenvolupament que expliqui clarament com el curs d'acció previst condueix al resultat desitjat, en lloc de simplement repetir el que s'ha fet per a altres mòduls o acceptar la seva paraula que això és el que ha de fer la característica X.
L'experiència d'aquest projecte em va ensenyar a negar-me a començar el procés de desenvolupament fins que tinguéssim una comprensió clara de per què se'ns demana que fem certes coses. Negar-se directament. Quan rebeu una tasca, el primer impuls és assumir-la immediatament per no perdre el temps. Però la política de "congelar el projecte fins que entrem en tots els detalls" pot reduir el temps perdut en ordres de magnitud.
Encara que intentin pressionar-te, obligar-te a començar a treballar, encara que no entenguis la raó d'això, resisteix-te. En primer lloc, esbrineu per què us donen aquesta tasca i decidiu si aquest és el camí correcte cap a l'objectiu. Tot això ho havia d'aprendre de la manera més difícil: espero que el meu exemple faci la vida més fàcil als que llegeixen això.
Quart nivell de comprensió: ???
Sempre hi ha més coses per aprendre en programació, i crec que només he ratllat la superfície del tema de la comprensió. Quins altres nivells de comprensió has descobert al llarg dels anys de treball amb codi? Quines decisions vau prendre que van tenir un impacte positiu en la qualitat del codi i de l'aplicació? Quines decisions van resultar ser incorrectes i us van ensenyar una lliçó valuosa? Comparteix la teva experiència als comentaris.
Font: www.habr.com