Una dintre cele mai supraîncărcate specializări de către cei care nu au habar este managementul programatorilor. Nu toți, ci cei care nu au fost niciodată programatori. Cei care cred că pot „crește” eficiența (sau poate „eficiența”?) folosind metode din cărți. Chiar și fără a se obosi să citească aceste cărți — există niște videoclipuri, nu-i așa?
Cei care nu au scris niciodată cod. Cei pentru care se fac filme de Hollywood despre programatori — știi, acelea în care verică e-mailurile din linia de comandă. Cei pentru care nu contează nimic altceva decât cifrele, termenele și propriul salariu.
Cei pe care îi întâlnești la tot pasul.
Dar idioții sunt dintr-un alt motiv. Vor eficiență, sau cel puțin rezultate (hai, managerule, caută pe Google care e diferența), fără a înțelege nimic din niciunul. De fapt nu înțeleg esența, procesul de obținere a rezultatului, pierderile care apar în acest proces, costurile de dezvoltare. Practic, lucrează cu programatorul ca și cum ar fi o cutie neagră.
Au alergat în managementul programatorilor dintr-un singur motiv: aici e hype, bani, piață și o grămadă de alți idioți. E loc de ascuns.
Dacă ar exista hype în producția de asamblare mecanică — s-ar duce acolo. Universali proști. Nu m-aș mira dacă tipul care vinde brazi în decembrie în cartierul nostru este un manager IT în vacanță.
Așadar, dacă aveți ocazia, scăpați-vă de acești băieți. Nu vă faceți griji, își vor găsi de muncă. Niciunul dintre ei nu va realiza vreodată ceva de calitate, până nu devine el însuși programator. Pentru că nu înțeleg esența, mecanismul, logica procesului pe care îl gestionează.
Bine, gata cu managerii. Acum, despre ce e important pentru programatori. Cum să creștem eficiența dezvoltării, învățând să scriem cod de calitate.
Pentru a crește eficiența, trebuie să rezolvi sarcinile mai repede, fără a pierde din calitate. Pentru a rezolva rapid sarcinile, trebuie să știi să scrii de la început cod de calitate. Și „de calitate”, și „a scrie”, și „de la început”. O voi explica printr-o metaforă.
A scrie cod de calitate – este ca și cum ai vorbi corect într-o limbă străină. Când nu cunoști limba, pierzi o grămadă de timp pentru a-ți formula gândurile în ea.
Dacă trebuie să spui ceva rapid, pur și simplu lipsești câteva cuvinte, adesea nu cele potrivite, uiți de articole, ordinea corectă a cuvintelor, ca să nu mai vorbim de timpurile verbelor și pronunția defectuoasă.
Dacă ai timp pentru a formula un răspuns, va trebui să deschizi un dicționar sau un traductor online și să petreci o grămadă de timp formulându-ți gândurile. Sentimentul, totuși, va fi neplăcut: spui un răspuns și nu știi dacă este corect sau nu. La fel cu codul – pare că ai scris, pare că funcționează, dar cât de bun este – habar n-am.
Rezultatul este o pierdere dublă de timp. Timpul necesar pentru a veni cu un răspuns este consumat. Timpul necesar pentru a formula acest răspuns este consumat și el – și nu e deloc puțin.
Dacă însă ai abilitatea de a scrie cod de calitate, atunci răspunsul poate fi formulat imediat, odată ce s-a maturizat în minte, fără a pierde timp suplimentar cu traducerea.
Abilitatea de a scrie cod de calitate ajută în proiectarea arhitecturii. Pur și simplu nu vei lua în considerare, în minte, opțiuni greșite, nerealizabile sau prost concepute.
În concluzie: abilitatea de a scrie cod de calitate accelerează semnificativ rezolvarea problemelor.
Dar asta nu este tot. Datorită managerilor ineficienți, există o problemă – deci nu avem motive să scriem cod de calitate. Managerul nu se uită la cod, clientul nu se uită la cod. Ne arătăm codul rar, doar uneori, în unele proiecte unde există un «verificator» desemnat al codului sau o refactorizare periodică.
Astfel, în majoritatea cazurilor, codul prost ajunge în producție sau la client. Persoana care a scris cod prost își formează o legătură neuronală stabilă – scrierea codului prost nu numai că este permisă, dar și necesară – este acceptată și chiar plătită pentru asta.
În cele din urmă, abilitățile de a scrie cod de calitate nu au nicio șansă să se dezvolte. Codul scris de un angajat oarecare nu este verificat de nimeni vreodată. Singurul motiv pentru care va învăța să programeze corect – va fi motivația interioară.
Dar această motivație interioară intră în conflict cu planurile și cerințele de eficiență și productivitate. Această contradicție se rezolvă clar în defavoarea codului de calitate, pentru că pentru codul prost nu e nimeni sancționat. Și pentru nerealizarea planului – cu siguranță.
Ce să fac? Văd și propun două căi pe care le putem combina.
Prima — să arăți codul tău cuiva din companie. Nu reactiv, când te roagă / te obligă, ci proactiv (hei, uite codul meu, te rog). Aici e important să nu îmbraci critica codului în termeni excesiv de politicoși. Dacă codul este prost, trebuie să spunem că este prost. Cu explicații, desigur, și recomandări despre cum să-l îmbunătățim.
Dar această cale are și ea limitările ei. Aplicabilitatea ei depinde de momentul în care a avut loc contactul. Dacă munca a ajuns deja în producție și s-a descoperit că codul e prost, nu mai are sens să-l refaci. Sau, mai exact, nu mai există motive — de asemenea, metricile vor scădea. Vor veni managerii și te vor constrânge cu cerințe de eficiență. Și nici nu încerca să le explici că codul prost va reveni sub formă de bug-uri — asta te va costa. Poți doar să îți iei angajamentul de a nu mai face așa.
Dacă munca nu este încă predată sau tocmai a început, atunci a critica codul (sau proiectul său, concepția) poate avea un sens practic — persoana va face lucrurile corect.
A doua cale, cea mai tare — să te apuci de dezvoltarea open-source în timpul liber. Scopul este să ajungă o mulțime de programatori, anume programatori, să vadă codul tău și să își exprime opinia despre el. În interiorul companiei, toată lumea este ocupată. Însă programatorii din întreaga lume nu au ce face, și, dacă scrii ceva util din punct de vedere aplicativ, cu siguranță se vor uita înăuntru.
Principala idee, din punctul meu de vedere, este scrierea de cod în timpul liber, pentru că nu va exista o contradicție între calitatea codului și viteza de livrare a rezultatului. Poți scrie dezvoltarea ta timp de un an. Nimeni nu te va presa cu termene limită, TPP-uri, bani sau șefi. Completă libertate și creativitate.
Numai în creația liberă vei înțelege și simți ce înseamnă cod bun, vei vedea frumusețea limbajelor de programare și tehnologiilor, vei simți plăcerea de a rezolva problemele de afaceri. Și, desigur, vei învăța să scrii cod de calitate.
Adevărul este că aceasta va necesita din partea ta investiții de timp personal. Așa cum, de altfel, orice altă dezvoltare. Privește asta nu ca pe o cheltuială, ci ca pe o investiție — în tine.
Sursa: habr.com
