Acum codul mizerabil e relativ, daca sari cu DRY cand ai 2 chestii copiate in tot proiectul si e clar ca fac chestii diferite dar ai putea sa le spargi cumva ca sa fie mai elegant nu se merita.
Dar daca ai cod sincron pentru un serviciu/feature care clar va fi asincron in viitor trebuie rescris. Ca stii ca vine un feature care necesita un alt mod de gandire precum stream-uri, servicii asincron si tu inca esti pe cod sincron. Pe front-end de exemplu cu react sunt oameni care isi inventeaza tot felul de metode ca o componenta sa nu se randeze de mai multe ori de stai si te uiti ce a vrut ala sa faca in loc sa caute sursa adevarata si sa rescrie tot cum trebuia. Daca pui prea multe fix-uri in loc sa te bazezi pe react devine oribil codul.
Multi nu vor sa scrie teste, nici mie nu imi place sa scriu teste pe feature-uri complexe, e enervant de multe ori, dar e foarte util cand vrei sa stergi chestii si sa nu strici ceva in productie.
mizerabil ca extinzi regula de tslint sa iti permita sa dai commit cu 1000+ de linii in fisier, ca limita era 700 inainte
sau pui toate componentele intr-o pagina, inclusiv logica care tine strict de una dintre ele pentru ca nu ai chef sa gandesti interactiunea dintre ele, vine demo si ai promis
ramane acolo putred si tot apar buguri foarte greu de rezolvat, foarte greu de agaudat chestii etc
Nu folosim react, folosim Angular noi si asa s-a intamplat vreo 3 luni de zile FE-urile sa trimita de vreo 5 ori mai multe requesturi catre backend de am ajuns la vreo 10 milioane de requesturi pe zi. Nici nu ne-am dat seama
State management is HARD. Frontendul trebuie gandit cu arhitectura si tot, am facut greseala sa-l desconsider si asa am ajuns in situatia de mai sus. Trebuie pornit cu state management in mind din prima si educat developerii sa lucreze in felul acela. Nu-l face nici mai usor Redux-ul, ba dimpotriva mi se pare asa de alambicat ca fix de-aia un dev normal nici nu-si bate capul sa-l inteleaga si face hackuri si quick fixuri.
Daca pentru fiecare test in parte trebuie sa reinventezi roata, atunci e foarte enervant. Dar, daca ai un toolbox pentru teste, atunci devine totul foarte placut si chiar incepi sa practici TDD-ul. Multe echipe nu investesc in partea de testare foarte mult, adica nu trateaza testele ca un cod viu la care trebuie sa faci mentenanta si la care trebuie sa scrii cod bine.
Daca ai teste pe PR si sunt bine scrise testele. Accepti, dai merge si treci mai departe. Dar daca nu ai teste, nu bagi codul ala. Practic, ce am observat este ca daca nu ai teste pe o parte de cod scrisa mizer nici nu o sa te apuci sa o rescrii, e pur si simplu presiunea mentala prea mare
folositi patternu de Component Harness pentru testare pe Angular?
mi se pare foarte tare si pentru mentenabilitatea testelor, ca practic abstractizezi complet implementarea propriu zisa a componentei si nu sapi prin DOM in teste
plus ca asa poti sa te folosesti de functionalitatea interna a componentei in testele scrise pentru pagina in care este folosita, de ex. Fara sa te uiti cum arata ca si structura.
Chiar pare ce trebuie, dar asta e prima data cand aud de asta. Mersi fain, voi mai citi legat de Component Harness.
Noi ce folosim cel mai mult sunt integration tests. Practic, la fiecare PR, fiecare merge in development, aprindem un stack pe undeva si rulam testele pe intregul stack. Pe frontend stam foarte slabut cu testele, dar planul meu este sa folosim: GitHub - microsoft/playwright: Node.js library to automate Chromium, Firefox and WebKit with a single API pentru a face testele de UI. Mai mult de atat, sa fiu sincer, nici nu ma prea intereseaza sa testez; deoarece, pana la urma, pe utilizator si pe PM il intereseaza sa se vada butonul X, ca are drepturi sa faca Y, etc.
Intr-un startup, cand lucrurile se schimba de la o zi la alta, nu are rost sa faci prea multe unit tests deoarece ajung sa fie foarte instabile la un moment dat. Practic o sa-ti intre in cale daca nu e codul stabilizat. Avem deja cateva sute de teste de integrare, rulate pe suite in paralel care acopera cam 60-70% din business case-uri. Merge, e putin incet, dar face si ce testezi sa nu fie asa de abstract. Adica, chiar testezi pe entitati reale deobicei, nu mockuri.
Nu recomand teste e2e, iti complica build-ul foarte tare, chiar si cu puppeteer ia mult efort sa le faci stabile. Incearca sa faci toate testele relevante din unit si integration pe front-end si unit/integration pe back-end. Contract testing-ul e sfant daca ai microservicii (cu pact).
Daca vrei e2e, testeaza fiecare componenta izolat (ca si in storybook de exemplu), preferabil doar snapshot testing. Backend-ul sa fie cat mai mockuit. Eventual un smoke/regression bazat pe tot flow-ul de la cap la coada pe un singur test ca sa nu faci manual sanity check la release poate fi util, dar o sa ai sigur probleme de stabilitate. (e necesar daca folositi feature flag-uri si codul se poate pune automat in productie din staging daca trec testele)
Apropo de code reviews. Am ajuns sa cred ca sunt o mare minciuna si pierdere de timp. E locul unde se platesc polite iar unii abia asteapta sa show off si sa bage in ceata un junior. Problema e ca singura alternativa viabila la code reviews este pair-programming. O practica foarte misto dar care insa necesita 2 oameni deodata cu acelasi timp disponibil, chef si putere de munca. Si nu mereu se aliniaza planetele. Mai ales daca echipa tehnica este formata din 3 insi.
E drept, si limbajul conteaza enorm. Altfel de CR am acum pe GO fata de perioada cand faceam PHP. Fara flame, e vorba strict ca PHP este un limbaj mult mai expresiv dar si mai loose. Poti comite cod cu greseli foarte usor.
In GO e foarte diferit. In primul rand nu prea poti sa “faci” lucruri decat in 1 sau 2 moduri. Nu prea poti sa introduci prostii pentru ca de cele mai multe ori nici nu compileaza al naiba. Unused imports? nope. Unused variables? try again. Daca folosesti Goland, vei avea by default tooling-ul oficial instalat si configurat. Deci partea asta e rezolvata. Parte care imi ocupa mult timp in alte limbaje.
Dar nici nici un tooling din lume nu te poate scuti de comentarii de genul:
“Codul asta poate fi refactorizat si facut putin dry”
Wat? Sa zicem ca asa ar fii…ba oameni buni…daca aveti ceva in cap cand lasati comentarii de genul…lasati si sugestii de rezolvare. Ca altfel omul o sa lucreze cum stie el, o sa ti se intoarca PR-ul la review din nou, o sa comentezi aceeasi aberatie si uite cum pierdem timp cu totii.
Meh, pair programming mi se pare greu de facut. Multi oameni, mai ales la inceput, sufera putin de impostor syndrome. Si le este foarte greu sa scrie cod cand stiu ca le urmareste cineva fiecare bataie de tasta, judecand. Si eu eram la fel, singur puteam implementa multe chestii, dar cand statea cineva langa mine si il auzeam cum respira ma incurcam si la filtrari de array
Da, trebuie dat ego-ul la o parte putin cand faci CR si cand primesti critica pe o bucata de cod. Practic, daca commentul pe care il dai nu e o intrebare sau ceva actionable si realist, mai bine nu mai comentezi nimic pe acel PR. Sa fim sinceri putin aici: nu toata lumea are maturitatea sa inteleaga asta, mai ales in domeniul nostru. Si cu totii suntem cateodata flame warring socially awkward persons, dar majoritatea dintre noi nu stam in modul asta tot timpul. Dar, poate la unii se activeaza fix cand dau code review modul acesta de functionare
You want to be spending your time on things that get the most bang for the buck. And you can’t figure out how much buck your bang is going to cost without knowing how long it’s going to take.
Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?
When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.
This forces you to actually figure out what you are going to do.
Treaba asta deschide o altă discuție: cât de mult planificați în avans ce aveți de făcut? Și cât de detaliat?
3) Don’t let managers badger developers into shorter estimates. Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.
Why do managers try this?
When the project begins, the technical managers go off, meet with the business people, and come up with a list of features they think would take about three months, but which would really take twelve. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 4n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. The business people are unhappy.
Inept managers try to address this by figuring out how to get people to work faster. This is not very realistic. You might be able to hire more people, but they need to get up to speed and will probably be working at 50% efficiency for several months (and dragging down the efficiency of the people who have to mentor them).
You might be able to get 10% more raw code out of people temporarily at the cost of having them burn out 100% in a year. Not a big gain, and it’s a bit like eating your seed corn. Of course, when you overwork people, debugging time doubles and a late project becomes later. Splendid karma.
But you can never get 4n from n, ever, and if you think you can, please email me the stock symbol for your company so I can short it.
Are dreptate in mare parte insa modul in care se face software in 2021 este destul de diferit de 2007. Asta nu inseamna ca il contrazic.
Noi ne planificam munca cu 2 sprinturi in avans. Nu mai mult pentru ca am observat ca nu are rost. Pe de o parte business-ul se razgandeste des si asa mi se pare normal, pe alta parte si planificarea mananca mult timp daca o faci bine. Implica niste timp alocat pentru analize, poate chiar POC, etc.
Insa nu asta e problema de fond in opinia mea. Cum ziceam mai sus, in 2021 software-ul este cateva ordine ne magnitudine mai complicat ca in 2007. Pai in 2007 aveam interfete in html si css si poate daca erai skilled suficien in Dreamweaver puteai adauga ceva dinamic in pagina cu js. Apoi build tools, testing. Apoi in 2021 avem pe backend in 95% din cazuri sisteme distribuite. In 2007 foarte putini porneau la drum cu sisteme distribuite in minte. Apoi evolutia limbajelor de programare. In majoritatea limbajelor s-au adaugat features noi care ingreuneaza citirea codului si complica codebase-ul.
Toate astea duc la marirea timpului de executie. Iti ia mai mult timp sa scrii cod. Iti ia mult mai mult timp sa citesti cod.
Estimarile in ore in 2021 mi se par asa…desuete estimarile in man days mi se par cele mai ok.
Estimarile sunt necesare intr-o firma care cauta sa-si respecte niste angajamente, deoarece vrei o metoda prin care sa-ti poti masura progresul, sa poti calcula un pret, etc. La fel, o echipa scrum isi ia angajamentul ca livreaza un set de backlog items intr-un sprint tot pe baza estimarilor. Ca sunt story points, ore, etc, nu conteaza asa mult, dar trebuie sa ai o modalitate prin care sa iti masori progresul fata de niste deadline-uri prestabilite. Sunt foarte multi oameni care lucreaza in Scrum, dar care nu inteleg ce reprezinta un burndown chart.
Absenta unor estimari pe unele proiecte arata ori o capacitate exceptionala de a avea story-uri cu efort similar, ori o lipsa de interes fata de termene, date de release, etc.
Nu zice nimeni ca estimarile sunt usoare, de-aia de multe ori lumea se uita la seniori sa dea estimari deoarece stiu implicatiile, dependintele mai bine decat altii. Chiar daca nu poti estima ceva, sunt modalitati de genul proof of concept sau timebox-uri in sprinturi prin care poti analiza situatia mai in detaliu cu scopul de a da o estimare.
Este dezamagitor ca foarte multa lume din zona tehnica nu intelege esenta dezvoltarii in iteratii, principiile lean, dar critica scrum, kanban… stiu ei mai bine, dar pe baza carei experiente?
Este diferit, de acord, dar hai să nu mergem atât de departe să spunem că e
Poate că în unele domenii (e.g. web) s-a… „normalizat” complexitatea, dar în 2007 existau si aplicații web complexe (gmail, parcă google docs apăruse tot pe atunci) și cu siguranță erau aplicații desktop complexe (de la programe de grafică la sisteme de operare). Nu cred că procesul de dezvoltare a acestor aplicații era easy-peasy…
Am eu darul de a exagera. Ca si la estimari. Ok, o sa rectific. Este mai complicat sa faci software on 2021 fata de 2007. Si sa o lasam asa.
Ce as vrea sa mai zic: la un moment dat in linkul dat de tine este un exemplu de schedule. Iar un task de acolo suna asa “Change html bg color to blue”. Estimare 1 minut.
Dude, nici daca ma misc cu viteza gandului nu am cum sa livrez asa ceva intr-un minut. Valabil pentru orice codebase pe care am lucrat din 2015 incoace. Nu ca taskul e greu, ci din cauza/datorita tooling-ului specific anilor in care muncim.
In prima faza negociezi, cauti sa vezi ce anume e important pentru client in alea 2 saptamani, poti sparge functionalitatea in mai multe bucati? Evaluezi daca are sens sa aduci un om in plus in echipa care sa faca diferenta. Evaluezi consecintele depasirii angajamentului luat fata de client - merita sa ceri ore suplimentare, ajuta la livrare?
Trebuie intelese nevoile si constrangerile pe care le are clientul, ma refer la nivel de management, e posibil ca reprezentantul clientului sa aiba propriile obiective, interese, au si ei manageri care le sufla in ceafa, e de asteptat sa puna presiune pe furnizor ca sa-si atinga interesele.
Sa inteleg ca nu esti familiar cu #noEstimates movement. E ok. Nu e timpul pierdut. Cauta Vasco Duarte no estimates. Vorbim dupa. Hint: Are si niste studii in spate.
estimarile in man days mi se par cele mai ok.