Motive pentru a folosi micro-servicii

Micro-serviciile, un concept și nou și vechi, e din nou la modă. Acum doi ani nu prea îi dădeam prea mare importanță, însă azi dacă aș avea de proiectat un serviciu sau produs nou, aș folosi cu plăcere acest model. Iată câteva dintre motivele mele:

  1. Sunt mai ușor de întreținut: când o aplicație monolit are un defect, vei fi nevoit să descarci tot codul sursă (de obicei câteva zeci de mii de linii de cod), să reproduci problema și să faci deployment-ul. În cazul unui micro-serviciu ai doar câteva clase și câteva sute de linii de cod – găsirea problemei și rezolvarea ei va fi mult mai ușoară.
  2. Mai puțin cod rezultă mai puține defecte, și mai ușor de testat.
  3. De obicei, micro-serviciile oferă mai multe opțiuni de configurare, pentru că depind de alte micro-servicii. Asta face migrarea lor mai ușoară și cuplarea cu alte micro-servicii.
  4. Mai ușor de scalat, și în multe cazuri și costuri mai mici: fiindcă micro-serviciile de obicei au un scop foarte limitat, poți monitoriza mai ușor și scala doar acele micro-servicii care a căror performanță este direct dependentă de resurse.
  5. Mai ușor de monitorizat.
  6. Mai puțin dependente de platformă: doar în cazuri foarte rare, un micro serviciu este dependent de un furnizor de servicii cloud, de exemplu dacă folosești ca micro serviciu un serviciu specific acelui furnizor, cum este Mailchimp sau SES. Dar atunci când îți implementezi propriile servicii le poți face să comunice prin HTTP cu interfețe REST, și ai din start independență față de infrasctructură sau rețea.

Sper că v-am convins să considerați micro-serviciile pentru următorul proiect. Chiar dacă e nevoie de o planificare mai laboriaosă a componentelor și interfeței de comunicare/autentificare e un exercițiu foarte bun.

Cel mai simplu mod de a înțelege diferența dintre i++ și ++i

Pe principiul ”omul din greșeli învață”, am să vă propun azi să înțelegem diferența dintre expresia i++ și ++i . Sunt sigur că i++ e nelipsit din utilizarea zilnică și așa devine oarecum expresia de facto pentru a incrementa o variabilă, dar în același timp suntem ”păcăliți” să credem că este echivalentă cu i+1.

Exemplele de mai jos sunt în PHP, însă le puteți adapta foarte ușor la alte limbaje, eliminând în principiu $ din fața numelor variabilelor.

Dacă rulăm următorul cod:

Vom vedea pe ecran: a=0 iar b=2; Ceea ce nu prea are sens nu? De fapt b=2 oarecum e corect deoarece, am pus de două ori ++ pe lîngă i și deci a fost incrementat de două ori.

Hai să mai luăm un caz, o funcție recursivă:

Dacă executăm codul de mai sus, o să observăm că rulează la ifinit, și afișează în continuu ”Sunt la iteratia 1 din 100”. Se pare că în acest caz simbolul local al funcției $i, nu se incrementează. Dar dacă schimbăm codul astfel:

De această dată funcția va rula de 100 de ori.

Deci diferența dintre i++ și ++i e că expresia i++ incrementează valoarea lui i și returnează valoarea ne-incrementată pe când expresia ++i incrementează valoarea lui i și returnează valoarea incrementată.

Înainte să scrii cod…

Cred că o mare parte dintre problemele cu care se confrunta un proiect, în ceea ce privește implementarea, ar putea fi prevăzute și evitate înainte de a scrie vreo linie de cod, dacă s-ar parcurge, cu calm și poate o doză de detașament următorii pași:

Clarifică scopul proiectului

E un pas mare și important, însă tot pe atât de ignorat și ”pus la colț” când vine vorba de detalii tehnice. Eu vin din câmpul dezvoltării și programării de sait-uri  web, și uneori se întâmplă ca clientul să fie foarte încântat de design-ul prezentat și să semneze contractul pe loc. Însă peste câteva săptămâni, aproape de lansare să realizeze că design-ul saitului e total ”afon” de scopul acelui sait. Da da, putem discuta zile în șir și să ajungem la concluzia că scopul unui sait e ”să vândă”, dar chiar ai nevoie de un design plin de briz-briz-uri pentru asta? – vezi Amazon

Așadar, ca programator e esențial să înțelegi scopul proiectului la care lucrezi. Asta te va ajuta să împarți cerințele clientului în versiuni să-ți programezi milestone-urile și desigur data când o versiune stabilă va ieși pe poarta ”laboratorului”.

Eh, da o să fie și proiecte al căror scop va suna așa: ”Sait nou pentru compania X”, ”re-branding pentru agenția Y” – dar dacă proiectul nu are un scop bine definit, poate că nici nu merită investiția de timp. Deci un pont pentru managerii de proiecte: faceți tot posibilul să vă convingeți programatorii că lucrează la ceva important.

Vezi ce au făcut și alții

De multe ori poți avea impresia că ești pus în fața unei probleme unice. Și în 1% din cazuri așa e. Deci pentru o mare parte din cazuri există posibilitatea ca cineva să fi abordat deja aceeași problemă și chiar să o fi rezolvat. Poate cu mici nuanțe dar în definitiv, a găsit o soluție. Acuma nu mă refer aici la chestii ca trimiterea unui newsletter sau crearea unui slideshow. Acesta nu sunt probleme, ci sunt task-uri. Dacă ai înțeles bine scopul proiectului, atunci înseamnă că ai o imagine a formei lui finale, deci de ce să nu vezi cum au abordat alții acest tip de proiecte?

Citește documentația

O mare parte dintre bug-urile cu care se confruntă programatorii, sunt un rezultat al faptului că nu au citit toată documentația. Sau uneori chiar nu au citit-o deloc. De fapt uneori ajung să re-implementeze o funcție care era deja într-o librărie standard. Deci revizuirea documentației, chiar dacă plicticoasă e vitală, înainte de a scrie cod.

Supune design-ul la use-cases

Acest task ar trebui executat de un tester, sau o personană responsabilă de QA, dar dacă nu e nici un ins cu asemenea etichetă prin preajmă, tu ca programator ar trebui să o faci, înainte de a scrie cod. Sfatul meu ar e să o faci oricum.
Când programezi pentru web, un buton în plus sau în minus nu e așa de greu de adăugat, dar ce te faci dacă butonul respectiv trebuie să aibă text în 4 limbi, și cuvântul corespondent din estoniană are 24 de litere :P .  Da, se întâmplă așa des ca design-ul să ignore complet utilizatorul și să se axeze exclusiv pe a ”arăta bine”.

În consecință dacă nu-ți place să re-modelezi HTML și CSS (și mie îmi place tetrisul, dar uneori devine enervant :P ), supune design-ul la use-cases și dacă ceva ”dă cu virgulă” un project manager ar trebui să știe, înainte să începi să scrii cod.