Cele mai bune API-uri sunt foarte uşor de învăţat. Redactarea unei documentaţii cuprinzătoare nu este suficientă. Utilizatorii nu au timp să parcurgă sute de pagini de manuale, dat fiind că au termene limită. Aşadar, pot ei deduce modul de acţiune într-un scenariu cu care nu s-au mai confruntat? Multe API-uri arată că acest lucru este posibil. Secretul constă în consistenţă. API-ul Highrise este un exemplu excelent de consistenţă. Highrise este un CRM SaaS simplu, dar foarte util. Asigură consistenţă pe multe nivele:

Nu există o definiţie clară a arhitecturii software. Apelaţi de exemplu la Wikipedia:
„Arhitectura software face referire la structurile fundamentale ale unui sistem software, disciplina elaborării acestor structuri şi documentarea acestor structuri”
Această definiţie include câteva elemente. Care sunt „structurile fundamentale” ale unui sistem software? Ce sunt „structurile” unui sistem software?

În ultimele șase luni, am lucrat cu un client care dezvoltă dispozitive hardware. Provocarea cu care s-a confruntat a constat în plângerile clienților, din cauza bugurilor apărute după câteva luni de la instalare la unul dintre produsele lor. Bineînțeles, cauza respectivelor buguri necesită o investigare minuțioasă.

Sunt programator. Pentru mulți programatori, abilitățile de comunicare nu reprezintă un punct forte - cel puțin, eu știu că am avut problemele mele. Cele mai multe dintre ele au provenit din faptul că tendința mea naturală este de a ignora semnalele emoționale și de a lua în considerare doar faptele. În multe cazuri, acest lucru funcționează bine, doar că se creează uneori o tensiune inutilă și acest lucru poate deranja oamenii.

În calitate de consultant, mentor și formator, am fost nevoit să îmi îmbunătățesc abilitățile de comunicare. Practica te învață. Te sfătuiesc cu căldură să faci acest lucru. Dar, dacă îți place felul tău de a fi și dorești doar să îți îmbunătățești puțin interacțiunile tale cu entitățile non-geek, îți prezint următorul model. Acest model funcționează la fel de bine atât în comunicarea scrisă, cât și în cea vorbită

Din când în când, particip la discuții cu diverși oameni despre ce este de fapt TDD de fapt. Deoarece am dobândit în timp o anumită cunoaștere a acetui subiect, care se datorează nu numai utilizării, dar și datorită faptului că îl explic altora, am hotărât să scriu acest articol care detaliază punctul meu de vedere în legătură cu ce este TDD. Sper că îl veți găsi util.

Citeşte mai mult

Din când în când particip la discuții cu oameni despre ceea ce este TDD . Datorită faptului că utilizez TDD , dar și că îl explic altora , am dezvoltat o anumită cunoaștere în timp referitoare la acest subiect. De aceea, m-am hotărât să scriu acest articol care detaliază punctul meu de vedere în legătură cu ce este TDD. Sper că îl veți găsi util. Cum ar putea fi un articol lung, voi scrie pentru Today Software Magazine o serie de articole mai scurte pe această temă. Iată-l pe primul.

În cele două articole anterioare din TSM - Patru idei pentru îmbunătățirea software design-ului și Usable software design-am arătat cum să creăm un software design mai bun și am definit ideea de usable software design. Designul Software Utilizabil provine din observația simplă că dezvoltatorul este utilizatorul unui design software. Ipoteza mea este că utilizând principiile și practicile din Utilizabilitate în designul software se vor crea două beneficii importante: un timp mai rapid de implementare pentru sarcinile comune și integrarea mai rapidă a dezvoltatorilor noi într-o echipă existentă.

Într-un articol anterior pentru Today Software Magazine - Patru idei pentru îmbunătățirea Software Design-ului - am scris despre faptul că avem tendința de a face *software design* care nu este orientat către utilizator. Ori de câte ori vorbim despre design în alte domenii decât software-ul, discutăm din punct de vedere orientat către utilizator. Produsele Apple sunt renumite pentru că se concentrează pe experiența utilizatorului cu dispozitivul: cum se simte, cum arată, cât de repede răspunde, sunetele pe care le scoate, etc. . Software Design-ul este singurul tip de design care pare să nu aibă utilizator. La urma urmei utilizatorul final nu are nici o idee despre cum este organizată aplicația pe care o folosește și nici măcar nu-i pasă. Tot ce contează pentru el este ca aceasta să funcționeze bine.

Software Design se numără printre ultimele trenduri care impresionează domeniul IT. Se pare că în fiecare an apar alte câteva idei de design. Mai întâi au fost _design patterns_. MVC este modul în care construim aplicații _web_, în timp ce idei cum ar fi: domain driven design, porturi și adaptoare, microservices se bucură de adopție și interes crescut. Am învățat software design făcând, cu un mentor care a ținut să-mi dea un feedback foarte util, deși uneori enervant. Acest lucru a fost înainte să știu despre design patterns, SOLID principles sau TDD.

În fiecare săptămână, la Mozaic Works, în echipa de dezvoltare de produse, descoperim 2 - 3 buguri în produsul la care lucrăm în timpul sesiunii de Code Review. Acest lucru se întâmplă în ciuda faptului că lucrăm într-un mod foarte structurat și aplicăm ATDD și Test First/TDD.


Mai mult, dezvoltatorii și liderii tehnici se plâng la noi ori în comunitate ori în timpul sesiunilor de coaching sau workshopuri despre anumite aspecte ale revizuirilor de cod. 



De-a lungul carierei mele de 15 ani ca dezvoltator, technical lead, manager de proiect, freelancer, trainer, agile/lean/technical coach și din nou dezvoltator am văzut multe eșecuri în dezvoltarea de software. Dar am văzut și succese neașteptate. Dintre toate industriile, dezvoltarea de software pare destul de imprevizibilă. În calitate de client, poți cere să adaugi o funcționalitate destul de simplă ce pare să dureze o zi sau două până e gata, (ex. Adaugă euro la un sistem de contabilitate creat pentru francii francezi) și în realitate îți va lua două luni.

Cât de repede ai putea crea un produs software începând de la o idee? Acesta este scopul prezentului articol. Vă vom prezenta etapele pe care le parcurge un concept o dată cu ideea inițială până la a găsi valoarea esențială a ideii și apoi de a o pune în mâinile utilizatorilor cât mai repede posibil.

Evoluția profesională a unui dezvoltator software parcurge de obicei următoarele etape: programator junior, programator senior, lider tehnic sau de echipă, uneori arhitect și apoi manager. Această cale este paradoxală: cariera care începe prin a scrie cod se transformă în a nu mai scrie deloc cod. De altfel, cum ai putea să te ții la curent cu toate noutățile care apar în fiecare an în tehnologie?

Iată o situație obișnuită în zilele de astăzi: o companie află despre Agile și decide să adopte “procesul agile”. Echipa de conducere a companiei creează un plan al tranziției care include: training, coaching și consultanță. Monitorizarea avansului se face întrebând: câte echipe sunt agile? Pentru că atunci când vom fi peste 80%, am terminat tranziția și vom fi agile. Nu?

În lumea startup-urilor, mișcarea Lean Startup a fost o revoluție deși a pornit de la o observație simplă. Modelul standard de creare a unui startup era până de curând “Build, Measure, Learn” adică:
- Un antreprenor are o viziune de produs.
- După ce obține finanțarea necesară, construiește produsul conform viziunii sale.
- Produsul este testat pe piață.
- Dacă are succes, perfect! Dacă nu are succes, este modificat pentru a fi mai aproape de nevoile utilizatorilor reali.

Începutul de an este un moment bun pentru a medita la viitor. Cum putem crește în carieră? Cum putem avea o slujba (mai) stabilă? Cum putem deveni mai căutați într-o piață competitivă? Acest articol conține zece abilități tehnice care pot ajuta un programator să se facă remarcat de către colegi sau de către manageri pentru eficiență.

Specificațiile executabile sunt o modalitate de a folosi testele automate cu scopul de a documenta funcționalitățile unei aplicații. Testele automate sunt tot mai utilizate în industria software cu scopul de a valida funcționarea corectă a unei aplicații. Validarea funcționării corecte implică evident și un dialog cu persoanele care formulează cerințele (analiști business, product owners, product managers, alți stakeholders) și testele automate nu ne scutesc de documentarea cazurilor de utilizare ale aplicației. Pentru documentarea funcționalităților există câteva soluții, cea mai comună fiind scrierea de documente de specificații.

Ideea de comunități de practică derivă de la principiul agile care enunță nevoia de îmbunătățire continuă. Una dintre practicile agile pentru îmbunătățire continuă este crearea de comunități de practică, pe anumite domenii. O comunitate are un scop si este formată dintr-un grup de persoane pasionate sau interesate de aceleași subiecte. În agile obiectivul unei comunități este de a împărtăși cunoștințele și experiențele (cu cât mai diferite, cu atât mai bine) ale fiecărui participant.

În 2001, un grup de oameni nemulțumiți de starea lucrurilor din industria de software development s-a adunat într-o stațiune de schi din Utah. Dintr-una în alta, au ajuns să discute despre metodele industriale aplicate la vremea respectivă pentru gestiunea programatorilor și despre metodele așa-numite lightweight pe care mulți dintre ei le foloseau informal. Rezultatul acestei întâlniri, cum probabil știți, a fost The Agile Manifesto.

După cum afirmam în articolele anterioare despre software craftsmanship, Test Driven Development este una dintre practicile considerate de bază pentru artizanii software. În ciuda numărului tot mai mare de articole, blog-uri, filmulețe sau cărți despre acest subiect, Test Driven Development (TDD) continuă să fie un subiect de confuzie în comunitățile de programatori. Acest articol va încerca să structureze și să clarifice subiectul și să ofere suport celor care vor să învețe mai multe despre el.

Citeşte mai mult

Mișcarea software craftsmanship promovează ideea că singurul mod în care un dezvoltator poate fi rapid este prin a se comporta rațional în perioade de criză. Această gândire este o reacție la comportamentul de a scrie cod greu de modificat și de înțeles, practic de a produce datorie tehnică (eng. Technical debt), în momentul în care trebuie să livrezi software într-o perioadă scurtă de timp.

Știm din experiența industriei că tehnicile promovate de mișcarea software craftsmanship au potențialul de a crește productivitatea echipelor de dezvoltare. Test Driven Development ajută la obținerea unor soluții cu design mai bun și mai.. . stabile într-un timp mai scurt. Pair Programming ajută la eliminarea greșelilor în timp ce codul este produs, la diseminarea rapidă a cunoștințelor într-o echipă și la găsirea unor soluții mai simple. Continuous Integration ajută la rezolvarea rapidă și fără stress a problemelor de integrare între diverse componente.

Imaginați-vă următoarea situație: o echipă a dezvoltat timp de 6 luni un produs grozav, care se vinde imediat. Utilizatorii își arată pasiunea pentru produs cerând mereu funcționalități noi. Dacă echipa nu livrează noile funcționalități destul de repede, fericirea lor va scădea, poate chiar vor decide să migreze la concurență. Echipa trebuie să livreze rapid.

Mișcarea Software Craftsmanship a prins contur în 2009, ca reacție la ideea că putem reduce temporar calitatea codului pentru a scoate produse mai repede. Promotorii mișcării consideră că dimpotriva, ceea ce trebuie sa îmbunătățim este viteza cu care un programator scrie cod de calitate. Altfel, utilizatorii, clienții și compania care produce software au de suferit: primii din cauza greșelilor introduse în aplicații (bug-uri), iar compania datorită scăderii vitezei de producție a noilor versiuni și a nemulțumirii utilizatorilor.

Citeşte mai mult