Arta războiului aplicată dezvoltării software

Dacă lucrați în industria software, este posibil să fi auzit despre paradigma de design împărțiți și cuceriți , care constă practic în împărțirea recursiv a unei probleme în două sau mai multe sub-probleme ( divide ), până când acestea devin suficient de simple pentru a fi rezolvate direct. ( cucerește ).

Ceea ce s-ar putea să nu știți este că această paradigmă provine dintr-o veche strategie politică (numele este derivat din expresia latină divide et impera ) care sugerează că este posibil să păstrați controlul asupra subordonaților sau subiecților prin încurajarea diviziunii între ei.

Această strategie a fost folosită de nenumărați politicieni și lideri militari de-a lungul istoriei, cum ar fi Iulius Caesar (care a folosit-o în timpul războaielor galice pentru a-i învinge pe cei puternici din punct de vedere militar) și Napoleon (expertul francez în artilerie ar împărți trupele inamice, astfel încât nicio parte nu a fost mai puternică). decât propriile trupe și apoi le întrerupe comunicațiile, împiedicând eforturile inamicului de a coordona și executa atacuri).

Arta războiului: principii antice aplicate dezvoltării

Cu toate acestea, regula împărțiți și cuceriți nu este singura strategie politică care poate fi aplicată dezvoltării software. Deși politica și războiul au puțin de-a face cu dezvoltarea software-ului, la fel ca politicienii și generalii, dezvoltatorii trebuie să conducă subordonați, să coordoneze eforturile între echipe, să găsească cele mai bune strategii pentru a rezolva problemele și să administreze resursele.

Arta Războiului este un tratat militar străvechi scris în secolul al V-lea î.Hr. și atribuit lui Sun Tzu, un vechi strateg militar chinez, ale cărui teorii au avut o influență profundă atât asupra filozofiei orientale, cât și asupra filosofiei occidentale.

În ciuda vechimii sale, textul este încă inclus în programa la multe școli militare din Asia de Est și este listat ca o lectură recomandată în unele academii militare din Occident. Textul este împărțit în 13 capitole, fiecare fiind dedicat unui aspect diferit al războiului.

Cu toate acestea, pe lângă război, principiile și învățăturile lui Sun Tzu au aplicații practice în politică, afaceri, sport și, credeți sau nu, în dezvoltarea de software. De fapt, s-ar putea să aplici unele dintre aceste principii în rutina ta zilnică, fără să le cunoști măcar originile.

Detaliat mai jos, veți găsi o listă scurtă de tactici de bază și sfaturi explicate în Arta războiului. Probabil că acestea pot fi aplicate jobului dvs. în industria software-ului sau în oricare dintre alte industrii.

Timpul este crucial în orice campanie

Capitolul II, paragraful 2

Când te angajezi într-o luptă reală, dacă victoria se întârzie, atunci armele bărbaților vor deveni plictisitoare și ardoarea lor va fi atenuată.

Acest principiu poate fi aplicat dezvoltării software, de regulă descriind relația dintre durata ciclurilor de dezvoltare și moralul dezvoltatorului.

Dacă un grup de dezvoltatori lucrează luni de zile la aceleași proiecte, fără obiective clare sau fără un final la vedere, ei pot deveni frustrați și productivitatea lor poate scădea.

Dezvoltarea de software este un efort intelectual, astfel încât motivația este principalul combustibil pentru productivitate. A lucra în fiecare zi fără a percepe că munca ta generează rezultate reale poate fi foarte demotivant.

După cum se indică în unele metodologii agile, foaia de parcurs de dezvoltare ar trebui să fie împărțită în mai multe obiective și etape, pe care echipa le-ar putea atinge în intervale de timp scurte și le vor oferi un sentiment de progres și realizare.

Capitolul II, paragraful 18

În război, așadar, lasă ca obiectivul tău mare să fie victoria, nu campaniile lungi.

Această expresie poate fi interpretată în două moduri:

În primul rând, poate fi văzut ca un precursor al filozofiei UNIX: scrieți programe care fac un lucru și îl fac bine . Când dezvoltați software, trebuie să aveți întotdeauna în vedere obiectivul principal al programului, caracteristica cheie pe care o oferă sau cea mai mare problemă pe care o rezolvă și să vă asigurați o implementare adecvată.

Uneori, s-ar putea să vă inspirați și să vă gândiți la o caracteristică cu adevărat cool de adăugat, dar nu uitați că aplicațiile care au o mulțime de funcții utilizate rar au un nume denigrator: bloatware .

În al doilea rând, afirmația poate fi, de asemenea, considerată un precursor pentru unul dintre principiile de dezvoltare software lean: Livrare cât mai repede posibil .

Cu cât livrați mai devreme software fără defecte majore, cu atât veți primi mai devreme feedback de la client și veți putea încorpora modificările în următoarea iterație.

Dacă, pe de altă parte, livrați software care nu funcționează, veți pierde feedback valoros, deoarece clienții nu vor avea șansa de a-l testa în mod corespunzător. Acest lucru va face următoarea etapă de dezvoltare mai dificilă sau imposibilă în situațiile în care următoarea ta iterație depinde de feedback-ul clienților.

Fără leadership, fără rezultate

Capitolul III, paragraful 11

Acum generalul este bastionul statului; dacă bastionul este complet în toate punctele, statul va fi puternic; dacă bastionul este defect, statul va fi slab.

Acest citat descrie importanța rolului managerului într-o echipă de dezvoltare: succesul unui proiect depinde de forța tuturor persoanelor implicate, iar managerul este bastionul proiectului. Responsabilitatea începe de la vârf.

Chiar dacă dezvoltatorii lucrează frecvent singuri (fiecare stând în spatele unui computer, cu o comunicare limitată cu colegii), asta nu înseamnă că nu au nevoie de un lider bun. Managerii de proiect se ocupă de menținerea echipei pe drumul cel bun, asigurând o comunicare eficientă și soluționarea disputelor, iar liderii, evident, definesc prioritățile proiectului (printre alte sarcini), așa că rolul lor nu trebuie subestimat. Nici responsabilitatea lor dacă ceva nu merge bine. Imaginează-ți ce s-ar întâmpla cu un lider militar a cărui unitate nu și-a îndeplinit datoria în câmpul de luptă?

O echipă poate produce un software grozav chiar dacă are câteva mere proaste în poziții de dezvoltare, dar acest lucru este puțin probabil să se întâmple dacă managerul de proiect este mărul rău , indiferent de câți dezvoltatori rockstar are echipa.

Capitolul VI, paragraful 28

Nu repeta tacticile care ți-au adus o singură victorie, ci lasă-ți metodele să fie reglementate de o varietate infinită de circumstanțe.

Uneori, atunci când începem un proiect, este tentant să folosim același set de tehnologii pe care le folosim în proiectele de succes anterior (același limbaj de programare, aceleași biblioteci, același server etc.). Cu toate acestea, cu excepția cazului în care cerințele noilor proiecte sunt exact aceleași cu cele anterioare, aceasta ar putea fi o abordare greșită.

În programare, ca în majoritatea domeniilor, panaceul (un presupus remediu capabil să vindece toate bolile) nu există. Nu există o combinație unică de tehnologii pe care să o puteți utiliza pentru a rezolva toate problemele; fiecare tehnologie are avantajele și dezavantajele ei.

Desigur, învățarea unui nou limbaj de programare sau utilizarea unui API necunoscut ar putea fi inițial costisitoare, dar pe termen lung, calitatea software-ului va fi superioară și vei deveni un dezvoltator mai bun.

Capitolul XIII, paragraful 27

Prin urmare, numai conducătorul luminat și generalul înțelept vor folosi cea mai înaltă inteligență a armatei în scopuri de spionaj și, prin urmare, obțin rezultate mari. Spionii sunt cel mai important element în război, deoarece de ei depinde capacitatea unei armate de a se mișca.

Această frază poate fi interpretată ca importanța utilizării instrumentelor de monitorizare și a bibliotecilor de jurnal în timpul fazei de întreținere.

Deși uneori clienții ar putea să nu creadă așa, dezvoltarea nu se termină atunci când obțineți o versiune stabilă și complet testată. Software-ul evoluează mereu, fie prin remedierea erorilor, prin adăugarea de noi funcții sau prin îmbunătățirea eficienței.

Și nu există o sursă mai bună de informații pentru a ști ce modificări trebuie făcute decât a avea spioni care monitorizează software-ul în mediile de producție, verificând ce caracteristici sunt cele mai utilizate, cele mai frecvente erori și cele mai lungi operațiuni.

Rapoartele de eroare, intrările de jurnal și datele de utilizare sunt fundamentale pentru detectarea erorilor, identificarea blocajelor și a altor probleme, deoarece nu este întotdeauna posibil să se reproducă aceleași condiții în medii de testare controlate.

Munca în echipă și motivație

Capitolul X, paragraful 24

Cel care avansează fără să caute faima, Care se retrage fără să scape de vină, Cel al cărui singur scop este să-și protejeze poporul și să-și slujească domnul, Omul este o bijuterie a Tărâmului.

Practic, aceasta este versiunea chineză veche a „nu există eu în echipă” . Este mai important să lucrați împreună cu ceilalți decât să urmăriți câștigul personal.

Dezvoltarea software este o activitate complexă care necesită dezvoltatorilor să lucreze eficient în echipă. Un dezvoltator bun nu este cel care remediază cele mai multe erori, implementează cele mai multe funcții sau termină sarcinile înainte de termen; un dezvoltator bun este cel care ajută echipa să-și atingă obiectivele.

A revendica meritul pentru tot ceea ce ai făcut, a nu recunoaște erorile tale sau a da vina pe alții pentru ele sau a te numi un ninja cod ar putea păcăli unii manageri fără experiență și s-ar putea chiar să-ți obțină o mărire de salariu, dar vei deveni un membru contraproductiv al echipei tale.

Capitolul VII, paragraful 21

Gândiți și deliberați înainte de a face o mișcare.

Această frază indică importanța întâlnirilor de dezvoltare a echipei, precum cele propuse de metodologiile agile.

Când lucrați într-o echipă, este important să discutați despre orice schimbări majore înainte de a le implementa. Nu contează dacă ești liderul echipei sau dacă ești persoana cu cea mai mare experiență în subiect, ar trebui să vorbești mereu cu, sau cel puțin să informezi, restul echipei.

Amintiți-vă că alți dezvoltatori vă pot oferi informații despre părți necunoscute ale software-ului. Aceasta înseamnă că ar putea începe implementarea modificărilor mai repede decât se aștepta, deoarece ar putea fi pe deplin conștienți de efectele modificărilor menționate.

Capitolul X, paragraful 25

Privește-ți soldații ca pe copiii tăi și ei te vor urma în cele mai adânci văi; priviți-i ca pe proprii voștri fii iubiți și vă vor sta lângă voi până la moarte.

Acest citat indică importanța motivației, un principiu de management care este uneori uitat de manageri și liderii de echipă. Dezvoltatorii motivați vor scrie cod mai bun, vor lucra mai repede, vor comite mai puține erori și vor fi mai dispuși să investească ore suplimentare.

Motivația trebuie să fie generată de manageri, prin interesul real față de subalterni, ascultându-i, îngrijindu-se de echilibrul dintre viața profesională și cea privată, construind medii de lucru pozitive și îngrijindu-se de traseul lor de carieră.

De asemenea, nu trebuie să confundați motivația cu remunerația. Studii recente demonstrează că banii nu motivează majoritatea lucrătorilor, banii sunt în mare parte buni pentru a atrage și reține angajații, dar nu pentru a-i face fericiți de locurile de muncă. Așa că măririle de salariu și promovările nu trebuie privite ca instrumente motivaționale.

Gândește liber

Capitolul V, paragraful 7, 8 și 9

Nu există mai mult de cinci note muzicale, dar combinațiile acestor cinci dau naștere la mai multe melodii decât pot fi auzite vreodată.

Nu există mai mult de cinci culori primare, dar în combinație produc mai multe nuanțe decât s-au putut vedea vreodată.

Nu există mai mult de cinci gusturi cardinale, dar combinațiile dintre ele produc mai multe arome decât pot fi gustate vreodată.

Unul dintre lucrurile bune despre programare este că posibilitățile sunt nesfârșite; te poți dezvolta practic oriunde vrei (cel puțin, atâta timp cât nu este o problemă NP-completă).

Aplicații mobile, site-uri web, jocuri, aplicații desktop... dacă știi programare, toate sunt la îndemâna ta.

Capitolul III, paragraful 1

În arta practică a războiului, cel mai bun lucru dintre toate este să luați țara inamicului întreagă și intactă; să-l sfărâm și să-l distrugi nu este atât de bine. De asemenea, este mai bine să capturați o armată întreagă decât să o distrugeți, să capturați un regiment, un detașament sau o companie întreagă decât să le distrugeți.

Când lucrați la un proiect cu o bază de cod mare, este obișnuit să găsiți module sau secțiuni de cod care au fost implementate cu practici proaste sau folosind biblioteci depreciate. Deși ar putea fi tentant să ștergi (sau să distrugi) acest cod, s-ar putea să nu fie cea mai bună idee din mai multe motive:

• Codul moștenit nu este neapărat rău, uneori este un cod bun care a fost scris atunci când alte metodologii și tehnologii au fost considerate calea de urmat. Cu toate acestea, doar pentru că este vechi nu înseamnă că nu funcționează.

• S-ar putea să pierdeți timp pentru a remedia codul care încă funcționează, în loc să vă concentrați pe repararea altor părți mai critice ale codului.

• Dacă nu sunteți cu adevărat sigur de ceea ce faceți, înlocuirea unei secțiuni de cod care funcționează înseamnă că riscați să introduceți noi erori sau bug-uri.

Asta nu înseamnă că expresia „Dacă nu s-a stricat, nu-l repara” este o strategie bună, ci că fiecare proiect are priorități, obiective și constrângeri de timp. Deci, dacă găsiți cod care ar putea fi îmbunătățit, discutați-l cu restul echipei sau cu managerul de proiect pentru a afla când să îl optimizați.

Capitolul VIII, paragraful 3

Sunt drumuri care nu trebuie urmate, armate care nu trebuie atacate, orașe care nu trebuie asediate, poziții care nu trebuie contestate, porunci ale suveranului care nu trebuie respectate.

Chiar dacă nu o spune direct, am putea interpreta acest principiu ca pe un avertisment pentru a evita antitiparele.

Deși utilizarea unui anti-model poate rezolva o problemă pe termen scurt, ar trebui să rețineți că pe termen lung va fi contraproductiv. Deci, indiferent de cât timp economisiți, de câte erori remediați sau de cât de convenabil este pentru dvs., evitați-le.

Cu toate acestea, există momente în care ați putea fi tentat să utilizați un anti-model pentru a rezolva o sarcină urgentă, promițându-vă că veți implementa o remediere adecvată când aveți mai mult timp, dar amintiți-vă una dintre legile lui Murphy: toate remediile rapide devin schimbări permanente.

Concluzie

Deși dezvoltarea de software este diferită de a comanda soldați în război sau de a conduce o țară, toate acestea trebuie să rezolve probleme care necesită muncă în echipă, conducere bună, eficiență și soluții pe termen lung.

Cu toate acestea, Arta Războiului nu este singura carte care conține principii care pot fi aplicate dezvoltării software. Prințul de Niccolo Machiavelli este un exemplu.

De fapt, iată o listă de citate din Machiavelli care sunt încă relevante. Încercați să ghiciți care sunt principiile corespunzătoare în lumea dezvoltării software.

1. Leul nu se poate proteja de capcane, iar vulpea nu se poate apăra de lupi. Prin urmare, trebuie să fii o vulpe pentru a recunoaște capcanele și un leu pentru a speria lupii.
2. Nu încercați niciodată să câștigați prin forță ceea ce poate fi câștigat prin înșelăciune.
3. Niciodată nu s-a realizat nimic mare fără pericol.
4. Oricine dorește un succes constant trebuie să-și schimbe comportamentul odată cu vremurile.
5. Bărbații în general judecă mai mult după aparențe decât după realitate. Toți bărbații au ochi, dar puțini au darul pătrunderii.
6. Cine dorește să fie ascultat trebuie să știe să poruncească.
7. Înțelepciunea constă în a ști să distingem natura necazului și în a alege răul mai mic.
8. Nu există nicio evitare a războiului; nu poate fi amânat decât în ​​avantajul inamicului tău.
9. Natura creează puțini oameni curajoși; industria si instruirea face multe.