"Dependency Injection" este un tipar de design folosit de toate paradigmele moderne. În 2012 ați publicat o carte pe această temă. Ce ne puteți spune despre acest subiect și de ce ar trebui să citească programatorii cartea?
Mark Seeman: Mi se pare că există un sentiment ce se cristalizează în mințile vizionarilor de vârsta mea sau mai bătrâni, anume că problema cea mai mare a dezvoltării actuale de software este interdependența între programe (coupling). Este un factor ce distruge proiectele software.
Codul crește în complexitate până când se prăbușește sub propria greutate. În cazul codurilor care au un grad de interdependență foarte mare, fiecare bucată de cod este legată de toate celelalte elemente. Repari un bug aici, dar introduci alte două în altă parte. Adaugă o funcționalitate simplă, dar vei edita zeci de fișiere.
Pentru a menține codul sustenabil, va trebui să controlați interdependența îndeaproape. "Dependency Injection" reprezintă o astfel de încercare. Utilizând polimorfismul bazat pe obiecte, inserați (injectați) dependințe în obiecte. Unii mai numesc procesul "inversarea controlului", deși acesta este un concept mai general.
Puteți citi despre aceste idei peste tot pe internet, aceasta fiind situația și în 2010. Totuși, toate lucrările care încearcau să explice "Dependency Injection" aveau abordări diferite pentru a explica acest concept, folosind vocabular vag sau imprecis. Pe scurt, în ciuda faptului că toată informația era disponibilă, a fost greu să găsim o introducere bună în subiect. Din acest motiv, am decis să scriu o carte cu un limbaj consistent, bine definit.
Cartea a fost bine primită de public, deci cred că aceasta îi va ajuta pe oameni să reducă interdepedența și să mențină codul fiabil cu mai mare ușurință. A doua ediție a cărții se va publica zilele acestea. Steven van Deursen a depus efort în actualizarea textului, iar feedbackul pe care l-am primit referitor la a doua ediție arată că oamenilor le-a plăcut ce au citit. Cred că Steven a realizat un lucru deosebit.
Prezentarea dumneavoastră de la IT Days va fi despre Codul Uman (Human Code). Vă bazați pe o teorie interesantă, care ia în calcul codul scris sau citit de programatori zi de zi. Spuneți-ne mai multe despre acest subiect.
Mark Seeman: Cred că are legătură cu interdependența între programe. De ce este această interdependență atât de greu de gestionat?
Ce se întâmplă când dezvoltăm software? Pe lângă introducerea datelor de la tastatură, ne petrecem timpul citind codul existent pentru a ne da seama cum putem să îl schimbăm sau să îl îmbunătățim. Petrecem mult timp citind codul existent.
Ce se întâmplă când citim cod? Din câte îmi dau seama, toți programatorii își creează 'un simulator mental' în creier și cumva încearcă să 'ruleze' codul în acel simulator mental. Acest lucru presupune monitorizarea stării programului, a variabilelor, a flagurilor (atenționărilor).
Psihologia experimentală indică faptul că memoria noastră de scurtă durată poate monitoriza doar un număr limitat de elemente. Un studiu celebru menționează cifra 7 (plus/minus 2).
Interdependența între programe ne distruge abilitatea de a 'rula' codul complex cu încredere în creierul nostru, deoarece creierul uman pur și simplu nu poate monitoriza zeci sau sute de variabile.
Aceasta este problema cu dezvoltarea de software modern. Nu este vorba despre cum se poate echilibra un arbore binar sau despre cum să scrii un algoritm eficient de sortare. Aceste probleme au fost rezolvate acum câteva decenii. Problema care persistă este să ne dăm seama cum să scriem cod în funcție de limitările creierului uman.
Ce părere aveți despre tiparele de design din ziua de azi, când cele mai multe dintre ele sunt deja încorporate în limbajele de programare moderne?
Mark Seeman: Nu sunt de acord cu acest lucru, dar depinde de limbaj, presupun. Care sunt limbajele care au, de exemplu, tiparul de design Visitor inclus? Nu C# sau Java, dar surprinzător, limbajele derivate ML precum F# și Haskell au incluse tiparul acesta. Totuși, în aceste limbaje, funcționalitatea nu se numește Visitor, ci 'sum types' sau 'discriminated unions'. Se poate însă demonstra că "sum types" sunt echivalentul tiparului de design Visitor.
O critică frecventă a tiparelor de design este că oferă soluții la deficiențele unor limbaje particulare, și, cu toate că sunt de acord cu noțiunea, nu cred că sunt motive să respingem ideea de tipare. Dacă ne întoarcem la cartea originală Gang-of-Four, un tipar de design este o soluție comună la o problemă curentă. Aceste probleme apar când un limbaj nu oferă o soluție explicită. Din nou, Visitor este un exemplu bun: ocazional, trebuie să puteți modela datele din cadrul unui set finit de cazuri eterogene, în distribuție complementară, iar limbaje precum C# sau Java oferă funcționalități explicite pentru a rezolva un anume tip de probleme. Aderați la tiparul de design Visitor.
Când un limbaj oferă suport pentru o anumită problemă, nu e nevoie de un tipar de design pentru acest lucru. Este doar o funcționalitate specifică unui limbaj, așa cum este cazul sumelor Haskell.
De când s-a publicat cartea Gang of Four, unele dintre tiparele din acea carte au devenit funcționalități specifice pentru un anumit limbaj. De exemplu, C# a dezvoltat sintaxa 'foreach', care este o trăsătură de limbaj ce implementează tiparul de design Iterator. Astfel, rar veți auzi programatorii C# vorbind despre tiparul de design Iterator, deoarece se află deja acolo în limbaj.
În general, cele mai multe tipare de design nu sunt dezvoltate în limbajele moderne. Nu sunt la curent cu limbaje ce au funcționalități explicite ce implementează Adapter, Facade, Singleton, Bridge, și așa mai departe, iar limbaje precum C# sau Java nu au funcționalități explicite pentru Composite, Chain of Responsibility, etc. . Mai mult, trebuie luat în considerare că există mai multe tipare de design decât cele descrise în cartea Gang-of-Four. Cele mai populare sunt tiparul Null Object și tiparul Value Object.
Eu cred că vom folosi tipare de design multe decenii de acum încolo, dar accentul se va modifica. Nu doar că noile limbaje absorb tiparele de design vechi, dar noile probleme vor da naștere la noi tipare. Tiparele din cartea Gang-of-Four sunt intim legate de software pentru desktop. Acestea oferă soluții la problemele software cu mai mulți clienți, precum maniera în care să se implementeze sisteme de tip fereastră, manual context-sensitive, funcționalitate "undo" și altele. Multe din aceste probleme sunt acum rezolvate fie de sistemele de operare, fie au devenit complet irelevante într-un mediu de tip "web pe primul loc", sau "smartphone pe primul loc". Totuși, noile tipare apar, deoarece acele contexte vin cu alte tipuri de probleme.
Cum vedeți evoluția Agile? La ce ar trebui să ne așteptăm în ceea ce privește agilitatea în cadrul echipelor?
Mark Seeman: Este amuzant, oamenii mă privesc ca expert în dezvoltarea software Agile și mă întreb de ce. Rar am vorbit despre acest subiect și nici nu am scris multe despre asta.
Am petrecut un an într-o organizație ce făcea Scrum în mod formal, dar dincolo de asta, am fost în organizații ce aderau la metodologia "fă lucrurile să funcționeze" ('get shit done'). Există câteva trucuri pentru a obține acest obiectiv. Dezvoltarea bazată pe teste sau cel puțin testele comprehensive efectuate, ajută foarte mult în acest sens. Livrarea continuă este crucială.
Nu trebuie să urmați o metodologie formală pentru a realiza ceva, deși am făcut rareori acest lucru. Însă ceea ce fac este să ofer răspuns la feedback. Dacă un proces ajută, repetați-l. Dacă un proces nu ajută, nu îl mai practicați.
Totuși, cred că succesul meu în livrarea de software funcțional a fost legat de munca în echipe mici. În puținele ocazii, când am făcut parte din echipe mari, proiectul a eșuat. Proiectele mici au o șansă mai mare de a reuși, motiv pentru care livrarea continuă este importantă. Nu este nimic nou. Fred Brooks descrie acest fenomen în cartea 'The Mythical Man-Month' din 1975.
Agile și-a pierdut de atunci pentru mine fascinația. În aceste zile, termenul 'Agile' a fost cooptat de manageri și este puțin legat de ideile sale originare din Manifestul Agile. Cred că această tendință va continua, dar 'Agile' implică deja un proces formal - exact opusul a ceea ce a însemnat la început.
Noile generații de programatori vor redescoperi probabil principiile Agile și vor găsi un nou termen pentru acestea. Ideile inițiale din spatele dezvoltării de software Lean Agile sunt suficient de utile, iar ideile noi vor apărea și ele.
de Ioana Dogaru
de Vlad Haiduc
