Software Design in Startups

Am inceput sa scriu un articol despre Software Design in Startups pe baza planurilor pe care le facem de redesign la startup-ul la care lucrez, sper sa il mai completez pe parcurs.

Software Design in Startups

Două chestii:

  1. În loc să completezi articolul, ai putea folosi categorii. Astfel, cititorii te vor putea urmări prin RSS & co

2):

We want too to use AngularJS in place of JQuery

Aș zice că ori nu folosiți Angular cum trebuie ori nu îi înțelegeți scopul. Angular și jQuery nu sunt tocmai interschimbabile (unul ajută în manipulările DOM-ului, altul pentru o structurare mai bună a codului)

2 Likes

Folosesc deja categories ele se numesc labels in blogger:

Blogger How To: Add Categories

Nu stiu prea multe despre AngularJS dar ce m-a impresionat la el sunt urmatoarele:
-databinding-ul e mai simplu decat in knockout, proiectul sustinut initial de microsoft, probabil si din cauza ca e MVC si nu MVVM
-cand am zis s-a folosesc AngularJS in loc de JQuery, m-a gandeam la camp cu autocomplete, vazusem niste exemple, ar inlocui mai mult o functie de JQuery UI.

Ar putea coexista JQuery cu AngularJS auzisem ca ar fii probleme ?

Un topic interesant pe stackoverflow:
“Thinking in AngularJS” if I have a jQuery background?

Din cate stiu eu in startup-uri ar fi bine ca tot codul sa fie KISS (keep it simple, stupid), pentru ca sa ai time-to-market rapid. Poti (si trebuie) faci technical debt-uri mai tarziu si refactorizezi codul.

Daca faci treaba asta bazandu-te pe prea multe framework-uri o sa ai probleme in a gasii oamenii potriviti. Conteaza ce face start-up-ul, nu cred ca exista o regula generala.

Spre exemplu daca tu nu intelegi care sunt diferentele de responsabilitati intre AngularJS si jQuery mai bine inlocuiesti AngularJS cu un framework propriu (router, evenimente) cat mai aerisit si il refactorizezi mai tarziu cand ai iesit pe piata :dollar:

1 Like

Sunt de acord cu tine, mai puțin cu partea asta:

Altfel spus: fă treabă de mântuială și dacă ai timp și/sau chef, faci mai bine cu altă ocazie

Ma refeream la faptul ca in prima faza codul nu trebuie sa fie perfect cu unit teste.
Mai bine lansezi feature-ul si dupa aia faci technical debt. Mai ales ca intr-un start-up nu o sa ai la inceput bani de programatori experimentati.

Mai bine incasezi azi si lansezi feature-ul si platesti mai tarziu un pic mai mult pentru refactorizare. Asta nu inseamna ca poti sa scrii cod mizerabil :smile:

1 Like

Cred ca e util sa intelegem acelasi lucru despre Technical Debt. Iata un video despre ce spune Ward Cunninham, creatorul metaforei: https://www.youtube.com/watch?v=pqeJFYwnkjE

Intelesul ca “scriem cod mizerabil si poate rescriem dupa” nu are legatura cu metafora respectiva. Metafora spuna ca mai curand implementam niste cerinte cu cunoasterea de acum despre domeniu, chiar daca nu este complet corect. Apoi dam clientului, sau punem in productie ca sa invatam. DAR trebuie sa ne luam timpul sa adaugam si notiunile invatate.

Technical debt nu spune sa nu scrii teste unitare. Verificarea corectitudinii codului este un punct esential. Ca faci teste manuale sau automate, nu conteaza. Dar conteaza sa tii la calitate.
Ca nu ai bani de programatori de calitate, atunci si produsul este probabil sa nu fie de calitate. De asemenea e posibil sa pivotezi mai greu, pentru ca te tine in spate un cod scris urat si greu de modificat.

Oricum technical debt nu presupune ca avem calitate scazuta. Technical debt presupune ca nu avem toate cunoasterea domeniului si totusi lansam produsul in scopul de a invata domeniul.

5 Likes

Total de acord cu @Adi, technical debt asumat provine din faptul ca in acest moment avem o anumita intelegere asupra domeniului, iar peste 6 luni (de ex) vom avea o cunoastere mai buna, ceea ce creaza nevoia de a imbunatati codul pe care l-am creat la inceput.
E periculos sa ne folosim de acest termen si sa ii denaturam intelesul, in sensul sugerat de @serbanghita, si anume sa coboram deliberat stacheta in timpul scrierii codului.
Cred ca util in acest caz este articolul lui Uncle Bob despre start-up trap, unde se detaliaza aceste lucruri din perspectiva unui software craftsman care a vazut multe failuri si succese in industrie, si care iata nu e dispus sa coboare stacheta pentru ca a invatat the hard way ca nu asa trebuie procedat.

1 Like

Un proiect lansat cu un cod de cacat e mai bun ca un proiect nelansat cu cod frumos. Numa zic.

Ontopic, probabil ar fi trebuit sa-l scrii in romana. Engleza pe care o scrii e foarte greu de urmarit, lipseste coerenta, facand abstractie de toate greselile de gramatica…

@Adi, @tekkie - in primul rand eu nu am scris ca poti sa scrii cod mizerabil. Asta oricum tine de programatorii pe care ii ai si de standardele impuse. Ori eu nu am scris coerent ori voi ati citit in diagonala.

Sunt de acord cu tot ce s-a mentionat si scris legat de Cunningham, Foley si Uncle Bob.

Ideea mea era ca pentru lansarea MVP-ului nu trebuie sa avem dpdv tehnic totul pus la punct (unit teste, cod perfect, arhitectura perfecta). Cum s-a precizat, lucrurile astea se invata si oricum sunt specifice proiectului.

Metafora despre “techical debt” este doar o metafora. Te ajuta in discutiile cu managementul.

Mai departe ce faci tu pe partea tehnica tine si de cultura startup-ului, ca daca e “lean” oricum va trebui sa aplici ce ai invatat pe parcurs si sa refactorizezi.