Am dezvoltat in ultimi 10 ani aplicatii desktop(Windows Forms), web(ASP.NET Web Forms, MVC, Single Page Application AngularJS, JavaScript), acuma lucrez la parsere, writere(algoritmi si structurile de date aferente) utilizati la traducerea de documente din suita office, cred ca cea mai mare problema este atunci cand codul devine un gunoi nementenabil, chiar daca prima versiune a codului nu este clean code, aceasta poate fi refactorizata pana e adusa la o forma acceptabila, un alt aspect important este stabilitatea, la multe interviuri ti se cere sa scrii cod stabil astfel incat sa nu repare alti programatori dupa tine, dar daca nu scrii unit tests sau integration tests cu code coverage mare pe cod, acest lucru mi se pare greu de realizat, plus cum stii ca nu ai stricat ceva care mergea inainte atunci cand adaugi functionalitate sau faci refactoring la cod existent.
(postări retrase de autor, vor fi şterse automat în 24 ore, cu excepţia cazului în care mesajele sunt marcate)
Nu stiu ce software faci tu dar sunt bug-uri care pot cauza daune de zeci de mii de euro, asa ca e safe sa ai un code coverage cat mai mare in teste, codul sa fie clean code, mentenabil, documentat, trecut prin mai multe code review-uri, sunt niste proceduri standard care iti asigura fiabilitatea produsului software.
Din ce ai scris tu acolo, eu am înțeles așa: clientul te plătește să faci o treabă, dar dacă vrea ceva de calitate trebuie să te platească extra?
Revin cu ceva util si anume atentia la stari la anulare. Practic cel mai important lucru de prevazut este anularea in cazul unor interfete asincron si administrarea starilor intr-un mod cat mai eficient. E ceva pentru care e aproape imposibil sa testezi dar daca nu iei in considerare fiecare anulare o sa ai situatii foarte ciudate. (de exemplu daca deschid forumul pe Edge si Chrome deodata si fac un post dar nu il termin pe amandoua browserele voi avea un raspuns in curs, in plus din ceva cauza cateodata nu pot da click pe nimic in chrome - un bug al lui discourse)
Talk-ul de mai jos prezinta o solutie decenta cu redux-observable.
Un alt exemplu unde anularea ar fi importanta e un sistem de vot asincron cu react: sa ne imaginam ca avem 50 de tablete intr-o camera si se afiseaza aceeasi intrebare pe fiecare tableta. Fiindca nu avem de unde sa stim daca touch screen-ul merge bine pe fiecare dispozitiv trebuie sa oferim o fereastra pentru a schimba votul daca a fost efectuat gresit inainte de a-l salva altfel riscam o statistica total gresita dar il salvam si pe cel gresit daca cumva nu ajunge anularea la timp.
Atentia la anulare este ceea ce diferentiaza un cod ad-hoc de un cod care e gata de productie in cazul react/angular/aplicatiilor asincron. (sa presupunem ca respectam tot ce e common sense oricum)
Ce legătură are cu discuția de față? o.O
Am adus in discutie atentia la anularea event-urilor (gen pleci pe o alta pagina sau inchizi tab-ul, ti se schimba ip-ul sau dai click pe anulare sau scoti mouse-ul din focus) ca si un marker pentru calitatea codului si o solutie fara callback hell-uri si fara hack-uri la promisiuni cu RxJS.
Orice alta solutie deja duce un simplu site de prezentare la un cod intangibil din punct de vedere al administrarii starilor si event-urilor si la situatii imposibil de explicat. (gen cineva profita ca nu anulezi event watch-urile la o eroare si iti face ddos)
Am sters primul meu raspuns la cateva minute dupa ce l-am scris dar din vreun motiv a revenit. (exact cum am spus, discourse implementeaza nu prea bine anularea event-urilor)
Ma rog e ceva deja avansat care tine doar de viitor si doar de site-uri/aplicatii asincron in timp real (gen acest forum).
Posibil ca ăsta să fi fost un motiv? 
I-am făcut restore pentru că deja aveai două răspunsuri adunate; peste o săptămână, cele două răspunuri vor părea fi rupte din context pentru restul cititorilor.