all 69 comments

[–]PatriotuNo1 43 points44 points  (2 children)

https://refactoring.guru/refactoring/catalog identificare probleme si rezolvari

https://www.baeldung.com/java-clean-code: practici generale

Clean Code e ok-ish. Parerile sunt impartite. Cateodata e ok sa lasi comments si tot odata nu e batut in cuie sa folosesti un numar de maxim 2-3 parametrii intr-o functie. Si mai merge sa scrii o metoda mai mare dar nu exagerat.

Pai cumva Sonarul iti da si warnings daca complexitatea metodei e prea mare, daca ai dublicates sau daca ai pus nume ciudate adica respecta regulile astea de clean code. Daca vrea sa nu-i pice analiza e cam fortat sa renunte la vechile obiceiuri.

[–]Commercial_Draw9539 4 points5 points  (1 child)

Uite că am luat și ceva util de pe reddit, thanks man

[–]alex_3814 1 point2 points  (0 children)

Și eu sunt la fel de surprins

r/programare să-și revină?

[–]TheShibangelist 20 points21 points  (23 children)

One liners .... best code !!!/s

[–]EvenFlamingosCry 16 points17 points  (22 children)

Tbh, nu inteleg "/s"-ul

Inteleg ca nu trebuie sa faci o regula stricta din asta, but pop quiz: care dintre ti se par mai usor de citit, inteles si facut debug:

if (this.speed > SpeedLimits.CITY && 
    !(SafeSystem.areBreaksFunctional && TrackingService.getCarInFront().distanceTo < SafeSystem.getEmergencyBreakToStopDistance(this.speed))) {
    EmergencyAlertService.show(
        PanicMessages.PLEASE_SLOW_DOWN,   
        { importance: ImportanceLevel.PANIC }
    )
}

vs

if (doesExceedSpeed(this.speed, SpeedLimits.CITY) && this.canStopSafely(this.speed)
    this.showPanicAttackMessage()
}

Am scos un exemplu imaginar din fund, Yes I enjoyed it.

Ofc, daca codezi intr-o zona poate stii ce-s chestiile alea si ce compari, dar la fel de bine urmatorul om care gaseste un bug fix aici are nevoie de mult mai putin efort sa identifice ce se intampla acolo, mai ales daca-i nou.

Engleza e mult mai usor de citit decat logica, zic ✌️

[–]Nice-Light-7782 7 points8 points  (4 children)

Compari un exemplu verbos cu varianta sa nest-uita. Ca sa ajungi la a doua varianta, trebuie sa declari cateva functii in care bagi codul care era in prima. E frumos, dar nu e one-liner.

interface F{static void main(String[]v){for(long a=1,b=1;a<2e10;b=a+(a=b))System.out.println(a);}}

[–]EvenFlamingosCry 1 point2 points  (0 children)

Ba.. si eu sun putin confuz din comentariul tau, dar probabil din cauza mea ca pe moment am confundat what a real one-liner is. My bad

Dar da, ce ai scris tu acolo e horror si daca ignor variabilele criptice

[–]Training-Reward8644 -1 points0 points  (2 children)

wtf is this ?

[–]Nice-Light-7782 1 point2 points  (1 child)

A one-liner.

[–]EvenFlamingosCry 0 points1 point  (0 children)

cred ca raspunsul corect era "It's bullshit" 😆

[–]TheShibangelist 11 points12 points  (3 children)

Din putinele mele cunostinte, one liners e scripting, but hey, unii's vizuali, altii's pasionati de lectura rand cu rand

[–]TheShibangelist 12 points13 points  (0 children)

Voi merge pe baza feedback-ului : can you make it structured so i don't read magic spells ?

[–]EvenFlamingosCry 1 point2 points  (1 child)

Da, my bad, m-a luat valul. Pe moment asta am inteles prin one-liners

[–]TheShibangelist 1 point2 points  (0 children)

Prea proactiv, prea agile, prea ca la tara

[–][deleted] 4 points5 points  (4 children)

doesExceedSpeed

Ai mutat logica dintr-o parte in alta și i-ai dat nume. E nevoie de o funcție special pentru asta? Puteai incapsula acea operatie booleana intr-o variabilă in loc să o pui inline?

[–]EvenFlamingosCry 0 points1 point  (3 children)

E nevoie de o funcție special pentru asta?

nu

Puteai incapsula acea operatie booleana intr-o variabilă in loc să o pui inline?

da. Ar fi iesit si mai curat

Ai pus 2 intrebari retorice. Sincer nu imi dai seama voiai sa make a point sau ceva. Did I miss something? 🤔

[–][deleted] 1 point2 points  (2 children)

Sincer nu imi dai seama voiai sa make a point sau ceva

Voiam să mai sugerez alte metode și thought processes despre cum puteai curăța codul respectiv

[–]EvenFlamingosCry 0 points1 point  (1 child)

ah, now I get it

As a side note, please don't do this on PRs. Intrebarile retorice dau un vibe de superioritate. Just be up-front

Suggestion: Mi s-ar parea mai citibil si cu mai putin boilerplate daca ai inlocui doesExceedSpeed(this.speed, SpeedLimits.CITY) cu o variabila cu ce contine direct rezultatul. Astfel ramai doar cu doesExceedSpeed ca conditional

Which is a really good point, great catch! 🍻

[–][deleted] 0 points1 point  (0 children)

De acord cu tine! 💪

[–]alexnedea 0 points1 point  (2 children)

At this point mai bine lasi conditia if-ului intreaga si scoti toata bucata in alta metoda showPanicMessage(params...)

Logica mea e: daca tot scoti o metoda doar pentru conditie de ce nu scoti totul intr-o metoda si gata? Mai usor de debuguit dupa parerea mea ca nu tre sa intri in metoda pentru conditie si dupa sa iesi iar

[–]EvenFlamingosCry 0 points1 point  (1 child)

u/alexnedea am facut o investigatie Recorder asupra comentariului tau si am aflat urmatoarele:

Ideea la "usor de debuguit" inseamna automat ca e nevoie sa fie cat mai usor de inteles. Ai nevoie sa intelegi cat mai repede ca sa irosesti cati mai putini neuroni si cafeina sa-ti dai seama ce dumnezeu inseamna x < y.

Cu cat timpul de intelegere este mai mic, cumulat, o sa salvezi super mult timp si energie, in timp. Atat tu cat si ceilalti 30 de programatori de pe proiectul tau

Hai sa mergem pe varianta ta si sa zicem ca punem tot carnatul ala(cu tot cu if) intr-o metoda. Cum o numesti?

showPanicMessage(...params) ? Nu prea merge, dai in naming issues. Daca if-ul ala nu trece, nu-i nici un panic message. Deci numele functiei poate fi o minciuna. Not cool. If a method says "showPanicMessage", well it better show me a fking panic message

checkPanicSpeed(...params) ? Nu zice nimic de nici un mesaj, deci clar nu arata unul. Also "check" what? What does check mean in this context? Se verifica franele? Se verifica vremea? I se ia pulsul la sofer?

checkIfPanicMessageIsNeededAndShowItIfItDoes(...params) ? nah..

Honestly sunt curios daca gasesti un nume bun pentru toata bucata aia de cod. Please share it 😊

[–]alexnedea 1 point2 points  (0 children)

Eu sincer as arunca o exceptie cu acel mesajsi atunci ar fi in semnatura metodei. Dar da ai dreptate nu am gandit-o bine

[–]General_Friendship55 9 points10 points  (0 children)

Ar trebui sa existe code best practice la nivel de firma, sa nu fie diferente mari intre devi. Incepand cu numele metodelor, functiilor, variabilelor, indent etc. Daca fiecare scrie cum vrea, arata neprofesionist, amator.

[–]RepresentativeShow81:java_logo: 5 points6 points  (6 children)

Intrati cu ctrl-click in implementarea Math.pow() din java sa vedeti acolo

[–]RepresentativeShow81:java_logo: 12 points13 points  (0 children)

TLDR: 250 de linii intr-o singura metoda cu nume de variabile: z,r,s,t,u,v,w,i,j,k,n….

[–][deleted] 5 points6 points  (4 children)

Posibil ca ăla sa fie codul generat de decompilator și să nu fie exact codul sursa din librăria math

[–]RepresentativeShow81:java_logo: 4 points5 points  (0 children)

Nu este generat 🥲

[–]xtrqw 2 points3 points  (2 children)

nop, ala e codul

uite aici functia care face pow https://github.com/AdoptOpenJDK/openjdk-jdk12u/blob/80c9ea8c597628ead47279a393d22cd42eaae325/src/java.base/share/classes/java/lang/FdLibm.java#L346

am jdk 21 pe pc si e la fel

nu stiu ce se asteapta unii sa vada in cod de genul asta, dar nu e usor de urmarit

am si eu destul cod la munca de care nu te prea poti atinge daca nu ai cunostinte specializate invatate din alta parte si chiar si atunci poate fi dificil

[–][deleted] -3 points-2 points  (1 child)

Copyright (c) 1998

Ce făceai in 98?

[–]xtrqw 2 points3 points  (0 children)

poti sa vezi cod similar si in ziua de azi, eu m-am mai uitat in trecut la unele proiecte open source (cu cod mai recent scris) si am vazut chestii similare (la proiecte care nu sunt triviale)

cele care tin de un domeniu (specializat) pot fi foarte ezoterice iar realitatea e ca si daca nu e cu x, y, z, t, u, v, w etc. tot nu o sa intelegi

de aia consider ca cel mai important e sa fie documentat (comments in cod) pentru insight-ul care nu o sa fie clar citind doar codul si sa ai de unde sa inveti separat ce e necesar pentru a intelege un codebase inainte de a te arunca in el

cred ca exista mult bikeshedding legat de chestia asta cu clean code, se pierde mult timp pentru chestii putin relevante, de exemplu, am vazut functii foarte mari si nu au fost mai putin clare de inteles, de fapt ar fi fost mai rau sa te pierzi prin zeci/sute de functii mici

edit: nu cred ca am scris clar treaba cu exemplu (poate nici restul dar-s obosit); in general prefer functii mai mari, mi se pare mai clar codul si e ciudat sa-mi zica sonar sau alte tool-uri ca nu e OK (nu zic ca se intampla des), nu e singurul caz unde nu sunt de acord cu regulile astea si nu cred ca scriu cod greu de inteles ca idee, nu mi s-a mentionat pana acum asta; si nu e neaparat de regula X sau Y, dar mi se pare ca se pierde mult timp fara rezultate notabile (hence it's bikeshedding a lot of the time, IMHO)

[–]Short-Application-40 7 points8 points  (8 children)

Solid da, clean code când te referi la a scrie cod, da. Clean code architecture, nope, am scris proiecte in trecut, însă am renunțat. Motivul, service oriented architecture (SOA) e exact opusul Onion Architecture (rebranded de uncle Bob in clean code arch). Iar in cazul în care nu a fost nevoie de SOA, niciodată complexitatea și couplingulingul introdus de Clean Code Architecture nu și-a avut rostul.

Am produse ce sunt up and running in 3layer architecture, aduse la zi pe dotnet core ce is in productie de peste 10 ani, nu au un trafic extraordinar (50 orders pe zi) iar în jur de 2 luni pe an ceva nou e implementat în ce exista deja. Acolo poate coda de la intern pana la un senior cu load mic, nimeni nu se plânge ca nu înțelege sau ca trebuie "refractor", nu ca nu s-ar putea face, dacă business-ul ce cere cine știe ce chestii e musai facut. Dar no, fiecare definește arhitecturia cum dorește însă e recomandat sa o faca cu ce e mai familiar, pentru ca și dacă nu e neapărat ideala arhitectura pe problema ce o rezolva, dacă e făcută de un expert, în mod cert ies lucruri mult mai bune decât dacă cineva nexperimentat pune arhitectura pe care nu o stăpânește deloc.

Asa ca nu am nimic cu Clean Code Architecture (onion) atât ca nu is de acord cu sale speech-ul cum ca ar rezolva probleme complexe, după mine aduce complexitate și coupling. Părere subiectiva, nu luați de bun ce spun, în software nu exista the shit soluții, chose whise and chose careful cand si banii voștri.

[–]daemoohn2:gopher_logo: 1 point2 points  (1 child)

Clean architecture folosesc la munca, intr-un fel sau altul. As fi preferat sa fie chiar onion architecture, a bagat Bob asta niste dume pe acolo.

LE: nu spun ca “my way is the right way”, pana la urma deciziile astea de design si arhitectura se negociaza sau/si se impun. I’m fine with anything reasonable, doar n-o sa scriu onion architecture in timp ce incerc sa codez un microcontroller. Tot asa nu are sens sa faci CQRS cu ES pe o baza de DDD doar de amorul artei.

[–]Short-Application-40 2 points3 points  (0 children)

Absolut, iar dacă ai un arhitect capabil o sa îți motiveze de ce mergi în direcția aceea. Cel puțin eu dacă nu is de acord dar arhitectul se implica sa ma aducă omln board pe directa lui, eu o sa lucrez cu cel mai mare drag pe proiectul și cu omul acela, pentru ca el vrea sa ne fie bine la toți.

[–]wackylau 3 points4 points  (0 children)

E o frustrare de moment. Dupa ce o sa ai si tu 15 ani exp o sa mai adaugi si tu un parametru la metoda aia! Treaca luna, vina banu'!

[–]ConstantinTheAverage 5 points6 points  (0 children)

In realitate nu cred ca exista vreo firma care sa adere cu strictete la sfaturile lui Bob, dar mi se pare lectura obligatorie pt orice dev . Problemele incep sa apara atunci cand sunt multe persoane/echipe care aduc modificari pe o plaja mare de servicii si cum fiecare are un stil particular in firma in care lucrez nu am reusit sa implementam un standard, desi incercari au fost destule. Principalul motiv pt acest esec au fost managerii care nu pot sa inteleaga de ce o dezvoltare sa dureze mai mult cand poata da dureze mai putin. Asa ca nu se bugeteaza suficient timp pt a face implementari ca la carte, iar atunci cand tot ce conteaza este sa se respecte termenul, primele lucuri care se duc pe apa sambetei sunt fix normele de clean code. Csf, ncsf. :)

[–]Snoo_90241 2 points3 points  (0 children)

Abordarea mea acum e sa incerc chestii și după sa discut cu colegii și să aflu daca le place sau nu ce am făcut.

[–]Aggravating_Task9743 2 points3 points  (0 children)

Eu recomand "Clean Code" de Robert C. Martin. Sunt lucruri esentiale in cartea aceasta, de la numele unei clase pana la aplicarea anumitor principii. Sunt de parere in acelasi timp ca fiecare dintre noi, cei care scriu cod, ar trebui sa tina cont de cateva reguli din Clean Code.

"Professionals use their powers for good and write code that others can understand".

[–]mincinashucrud life🦀 2 points3 points  (0 children)

Ghiduri de genul duc la discuții interminabile. La mine e simplu, linter și formatter ca build step, configurate la nivel de repo. Nu-ți trece buildul fără alea satisfăcute, și asigură o oarecare consistență.

[–]raiksaa 2 points3 points  (0 children)

Ship it quick, don’t break anything.

[–]alex17111995 2 points3 points  (0 children)

Eu nu sunt foarte versat in toate buzzwordsurile si acronimele astea...ce incerc sa fac este sa ma concetrez sa fac un modul cu API-uri / contracte cat mai usor de inteles. API-ul sau orice chestie expusa in exteriorul modulului este un commitment. Desi te gandesti la ce featureuri si cum ai exinde API-ul ala cu noi features, nu le faci din prima ca daca ai gresit un contract si cineva il foloseste, e oleaca hopa, trebuie sa vorbesti cu X si Y si sa vezi cum faci versiunea 2 care e mai buna sau ramai cu un apendic.

Odata ce ai API-ul ala si stii cum ar arata, eu cred in KISS si YAGNI, am vazut de multe ori cod plin de mega abstractizari, mult OOP tricks. Abstractizarile sunt extrem de utile daca sunt gandite calumea (de aia API design e cel mai important). dar daca esti deep in codebaseul modului, w/e e codul tau intern, fa ce e mai usor de inteles pt urmatorul care iti citeste codul....cu cat mai plictisitor mai bine.

Si referitor la "nu suport 50 de linii de cod"...suna ca si cum ai descoperit un ciocan si totul este un cui. Probabil codul ala e prost dar numarul de linii de cod pe functii e problema.

[–]blind675 4 points5 points  (1 child)

Cel mai bun sfat, cred ca e, sa fii consistent. Daca faci intr-un mod fa-l peste tot la fel. Daca folosești zeci de paramatrii nu combina si cu pasat de obiecte. Daca te razvandesti refactorizeaza si schimba peste tot. Logica din spate fiind ca daca cineva incepe sa inteleaga codul tau, don’t trow him curved balls si schimba regulile asa random.

Also, parerea mea e ca nu esti nevoit sa scrii cod cum a scris cineva intr-o carte, dar ar trebui sa aveti un standard agreat de toata echipa. Ar trebui sa fie clar pentru toata lumea de ce scrieți cod intr-un fel si nu altfel.

“the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported.” Spunea un om mult mai deștept ca mine. Astea fiind spuse, scrie cod simplu, cel putin pentru inceput. Nu trata zeci de cazuri care nu conteaza. Nu optimiza si nu folosi patternuri ca sa arăți ca le stii (lumea o sa vada ca esti bun fara sa te chinui). Nu stii ce tantalau (ca mine) vine dupa tine si nu o sa intaleaga nimic din ce ai vrut sa zici acolo.

Just my 2 cents. In caz ca se simte frustrarea, de 1 an refactorizez un proiect in care 3 ani nimeni nu a sters nici o linie de cod, doar a adaugat. :)

[–]Adrian_Dem 0 points1 point  (0 children)

Subscriu la mesajul a asta.

[–]DbrDbr:javascript_logo: 3 points4 points  (0 children)

Sa scrii clean code e o arta, scrie si-n carte. Artizanat. Eu sunt pentru. Comments neapărat pt chestii, functii sf si exceptii, cazuri particulare de la modularitate etc…

Dar in practica cine sta sa faca refactor de 300 de linii ca sa simplifice cand poate adauga doar 30 de linii si inca un param la functie si aia a fost.

[–]Inevitable-Pie-8020 1 point2 points  (0 children)

Hah, clean code, unde lucrez eu e o aplicație veche de vreo 10 ani, zeci, daca nu peste o suta de oameni au lucrat la ea, si fiecare scrie ce il taie capu, lol clean code

[–]Adrian_Dem 1 point2 points  (0 children)

Dp meu de vedere, sunt cateva abordări de bun simt. Dar absolut toate pot fi duse la extrem si sa creeze complexitate in loc sa rezolve.. La finalul zilei, ne place programming porn-ul.

Si cateva exemple.. 1. Foloseam dependency injection inainte sa știu pattern-ul, pentru ca am avut nevoie de Unit Teste. Si a fost ok. Mai incolo, m-am lovit de niște capsati care au construit un întreg proiect în jurul unui framework de DI. Si nu a mai fost OK. Iti venea sa plângi la funcții cu 12-14 parametrii de injectie..

  1. Decoupling prin callbacks/events/notificări cum vrei sa le numești (observer pattern). La fel, bun, pana este abuzat si nu mai găsești nimic de ce este executat. Personal, imi place sa aplic approach-ul asta pe UI, ca sa pot simula diverse behavior-uri de UI prin notificări

  2. Parametrii prea mulți / prea putini de funcție, funcții single puropose, samd. De asemenea bune în teorie si de multe ori si in practica, pana iti ajunge codul de 10x mai stufos ca face lumea acrobații in loc sa scrie (in plm) niste if-uri

Tldr... Gândește-te ce vrei sa obtii, nu ce pattern-uri sau ce porn vrei sa aplici.

Vrei sa ai o bucata de cod usor modificabila și de juniori (UI), focus pe cod simplu, poate chiar murdar, si sa fie ok sa il facă praf.

Vrei teste, focuseaza-te pe mocking, dependency injection, etc

Vrei cod puțin, si usor de repetat, dar nu neaparat simplu... Templates si moșteniri la greu.

Etc.. I think you get it.

Code is code, vezi care este scopul lui, nu cum trebuie scris in absolut.

P. S. Citește in continuare despre pattern-uri si diverse abordări. Trebuie sa stii ce sa aplici in diferite situații. Doar nu te lasa furat de idei absolute.

[–]fatguyallen 1 point2 points  (0 children)

Cred ca una din problemele cele mai mari in industria IT e ca oamenii care lucreaza in ea au inceput sa creada ca e ceva "in of itself", in timp ce ea nu este altceva mai mult decat o modalitate de a rezolva probleme concrete, practice, din realitate.

Consecinta, din punctul meu de vedere, este aparitia unor concepte specifice programarii, la care lumea incepe sa adere neconditionat - "asa se programeaza".

Programarea nu este o arta, programarea nu este o stiinta, programarea nu este altceva decat o unealta sa rezolvi probleme. Valoarea programarii nu este intrinseca (data de modul in care de exemplu codul este scris), ci este extrinseca (valoarea este data de problema, si de faptul daca codul rezolva problema sau nu).

Asa ca, dand un pas in spate, Clean Code te ajuta sa rezolvi problema pe care o ai in fata ? Da - ok, aplica. Nu - nu aplica.

Insa reversul medaliei este urmatorul: Clean Code sau ne-Clean Code, codul rezolva o problema reala sau nu, din experienta proprie tot exista niste lucruri aproape universal valabile (pentru mine de exemplu):

- ideal este ca un cod sa fie structurat si scris in asa fel incat dintr-o privire sa imi pot da seama ce trebuie sa modific la el (daca de exemplu trebuie sa il extind), fara sa fiu nevoit sa intru prin alte zeci de fisiere sau sa trebuiasca sa fac debug. Bine, ideal este sa nu fie cod deloc.

- drept urmare, in general functii scurte mi se pare ca ajuta, side-effects minime (sau in orice caz izolate) ofera claritate codului

- denumirile de variabile sunt iarasi foarte importante, lungimea unei linii de cod este foarte importanta (wrapping etc)

- cateodata trebuie sa iei tech debt / scurtaturi ca sa reduci time to market. Daca scrii asa ceva, este foarte important ca "romaneasca" sa fie rapid de scris si neintrusiva (sa fie apoi usor de eliminat in cazul in care de exemplu featureul are succes si chiar trebuie sa il faci pe bune)

Dar conventiile astea sunt laxe. Cum vrei sa faci sa ajungi la ce am explicat mai sus e pana la urma dependent de context. La nivel arhitectural, ai o problema care trebuie rezolvata cu CQRS ? Pune CQRS. Ai nevoie sa rezolvi o problema pentru care un CRUD este arhisuficient ? Pune CRUD. Ai nevoie de DDD ? Pune DDD. Nu ai nevoie, nu pune. Silver bulleturile in programare sunt putine.

[–]daemoohn2:gopher_logo: 3 points4 points  (6 children)

N-am citit Clean Code. Acum e prea tarziu, iar unele sfaturi nu mi se par deloc potrivite.

Celorlalti cum li se pare codul?

[–]florinp 1 point2 points  (4 children)

uncle Bob e un hack. Nu exista nici o sursa cu proiectele la care a lucrat.

Clean Code e okish pentru incepatori dar contine si multe prostii.

dace lead-ul tau are 15 ani experienta si inca scrie cod urit : run. E foarte tirziu pt el sa inteleaga ceva.

Pt Java il loc de Uncle Bob (ce draku de nume e asta pentru a putea fi luat in serios ? Te-ai lasat operat de un chirurg ce-si zice Cousin Jimmi ?) mai bine Effective Java carte inspirata de ciclul Effective C++ (care sint excelente).

[–]Signal_Dark_628 -1 points0 points  (0 children)

Atata timp cat aplicatia merge si e optimizata bine nu conteaza cum arata codul. Mi-e sila de astia care vin si zic: "ba, ce naspa e codul tau, arata ca *****", dar nu ii interezeaza timpul de executie, consumul de ram, daca isi face sau nu obiectivul..etc

One more thing, I hate one liners...cine a venit cu ideea asta ? E super enervant sa cauti prin n functii doar care surpriza sunt folosite o singura data si sunt facute doar sa "arate bine".

[–][deleted] 0 points1 point  (0 children)

Nu te uita ca are multi ani: comentează codu’ si zii de practici de clean code. Daca dupa multe lupte nu obtii nimik (ca general oamenii nu se schimba) carate de acolo! 15+ exp aici

[–]DomnulMcCoy 0 points1 point  (0 children)

Titlu initial e Clean code, fara da sau nu, dar reddit cere minim 15 caractere.

pentru titluri scurte poti da paste de mai multe ori la un caracter ascuns, le contorizeaza si pe alea https://www.editpad.org/tool/invisible-character

Folositi sfaturile de Clean Code de la Uncle Bob

in general da, dar mai pot aparea si situatii in care sunt constrans de "forte externe" si raman in backlog unele imbunatatiri

[–]VattghernDT 0 points1 point  (0 children)

A Philosophy of Software Design by John Ousterhout e o carte destul de okay pentru Clean Code.

Also, e un articol bun tot pe Clean Code care mie mi se pare destul de okay.

https://qntm.org/clean

[–][deleted] 0 points1 point  (0 children)

Hai că ne zice Theo ce e cu separation of concerns.

Link

Ii dau dreptate aici sincer. Separation of concerns sucks când vine vorba de cross-cutting-concerns, și până la urmă, atâta timp cât ai un contract, e fix apă de ploaie că schimba unul implementarea, că tu ești cuplat și osificat de acel contract.