Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Problema cuptor electric cu disju...

Merita achizitionat DFSK Fengon 5...

Pret actual invelitoare

Probleme baterie Samsung A54
 Schema statie auto Renegade REN 1...

Magazine IT de incredere

Parere SKODA Octavia 3 2.0TDI 150CP

Achizitie telefon 1000-1200lei
 Unde gasesc o lampa buna pe gaz?

Consulta specialiștii... Und...

Fostul director al Frontex: Comis...

Construire anexa lipita de casa
 Ce folositi pentru urina mirosito...

Socializare in prezenta copiilor

Cont Samsung A32

Hotarare definitiva a instantei, ...
 

Principii & Patterns vs. eficiență

- - - - -
  • Please log in to reply
25 replies to this topic

#1
Rhesus

Rhesus

    Senior Member

  • Grup: Senior Members
  • Posts: 2,882
  • Înscris: 22.04.2014
Întrând în contact cu mai mulți programatori (unii cu zeci de ani de experiență în spate), am remarcat două ... hai să le spunem tipologii.

1. Tipologia programatorului pentru care principiile (și în general tot ce ține de procedee/design patterns/software patterns/best practices/etc.) sunt "sfinte".
2. Tipologia programatorului care consideră eficiența mai presus decât orice (chiar și cu "riscul" incalcarii flagrande a (1.)).

Am încercat să analizez și eu chestia asta, și din experiența mea (limitată față de a lor):

- aplicarea unor șabloane/modele de proiectare ajută atunci când proiectul este de la mediu în sus. Mai mult, atunci când echipa este destul de complexă(mare ca număr), stabilirea unui consens este obligatorie
vs.
- la proiecte mici spre medii, poate să îngreuneze și să complice codul inutil.

Dacă gândim KISS (keep it stupid simple) atunci majoritatea pattern-urilor (Builders, Adapters, Wrappers, Bridge, Decorators, etc.) complică situația. Un conector de 100 de linii de cod poate să ajungă la 500-1000 doar prin aplicarea unui wrapper. Corectitudinea? Identică cu prima variantă ...
Dacă am avea 10 conectori, care moștenesc un anumit pattern, atunci, da, se impune abstractizarea (si implicit code reusability).

Câteodată consider exagerată aplicarea la extrem a abstractizării.

Și atunci, vă întreb: În momentul dezvoltării (chiar în prima fază), cine "câștigă” ... eficiența (cu riscul de a încălca unele principii SoC) sau "cartea" ?

#2
OriginalCopy

OriginalCopy

    I'm harmful, fear me please! :))

  • Grup: Senior Members
  • Posts: 27,268
  • Înscris: 10.08.2006
Un nou nivel de abstractizare face arborele de abstracții mai adânc, deci mai greu de Ă®nțeles.

Cheia e să introduci noi abstracții atunci când acestea aduc beneficii Ă®n cât mai multe părți din cod.

Un programator experimentat va introduce noi abstracții atunci când beneficiile bat dezavantajele, dar le va respinge atunci când dezavantajele sunt prea mari.

ĂŽn funcție de situația concretă din cod, și Ă®n funcție de planurile de viitor.


Și mai e o chestie, Ă®nainte de a vorbi despre abstracții, un programator experimentat va tăia tortul de-a lungul sau de-a latul, Ă®n funcție de toate celelalte cerințe. Ambele variante rezolvă problema, dar unele tăieturi sunt mai eficiente ca altele.



Unul mai experimentat se va gândi și la portițe deschise cu o anumită abordare. Nu trebuie neapărat să implementezi ceva, e suficient să Ă®ți organizezi codul după anumite cerințe care ar putea apare.

Oricum ai da-o, dacă respecți câteva principii, pe care le Ă®ncalci atunci când există alte bube mai mari prin arhitectură, atunci ești pe drumul cel bun.

Printre principii: SOLID, law of Demeter, objects are always in a valid state (read: no setters), use the type system of the language (no getters like getType()), hide vendors behind abstractions, use polimorfism properly.

Edited by OriginalCopy, 19 November 2019 - 22:41.


#3
romio79

romio79

    Active Member

  • Grup: Members
  • Posts: 1,655
  • Înscris: 30.03.2005
la mine a fost ca aici:
https://medium.com/@...eer-db854689243

Edited by romio79, 19 November 2019 - 22:40.


#4
OriginalCopy

OriginalCopy

    I'm harmful, fear me please! :))

  • Grup: Senior Members
  • Posts: 27,268
  • Înscris: 10.08.2006
Un exemplu recent de mid-level bine intenționat, dar care nu vede pădurea de copaci: voia să introducă un nou DTO în cadrul unui refactoring. Refactoringul era deja suficient de mare, și deja lăsa codul într-o situație mai bună (boyscout rule), dar introducerea acelui DTO nu ar fi adus beneficii în cadrul acelui refactoring. Adică ori introducea acel DTO peste tot prin proiect, ori punea acel DTO în backlog pentru mai târziu.

Dacă ar fi introdus acel DTO și l-ar fi folosit doar în acel subsistem, ar fi fost prea puțin. Iar Refactoringul era deja suficient de mare.


Un programator avansat știe când să se oprească din perfectionism și să mai și GTD.

View Postromio79, on 19 noiembrie 2019 - 22:39, said:


La mine la anul 10 e un outputstream acolo.

Funny thing, outputstreamul ala poate fi webul, o imprimanta,...

#5
LOLkekLOL

LOLkekLOL

    Senior Member

  • Grup: Senior Members
  • Posts: 2,348
  • Înscris: 29.07.2019
2 = prosti, cei care fac excese la 1 tot prosti ... prioritatea trebuie sa o aiba designul bun general si bunele practici care facilitateaza MENTENANTA(prea multi afoni nu inteleg asta si nu stiu ce implica, si uneori mai sunt si caposi care cred ca-i un "moft")

eficienta, doar daca e nevoie, daca se numara printre cerinte, daca testele indica probleme..

#6
karax

karax

    Guru Member

  • Grup: Senior Members
  • Posts: 21,839
  • Înscris: 14.10.2017
am si io o intrebare de necunoscator: oare nu sunt cazuri in care simplitatea inseamna eficienta si alte cazuri in care complicarea inseamna eficienta, in sensul ca un cod simplu, sau mai bine zis mic ca dimensiune te duce naibii in n iteratii, insa cu ceva mai mare , ce pare complicat la inceput , ajungi la eficienta?
aici am inteles si eu o chestie, ca nu conteaza neaparat marimea codului sursa , ci de fapt numarul de iteratii generate.

#7
MarianG

MarianG

    be that as it may

  • Grup: Moderators
  • Posts: 31,320
  • Înscris: 10.08.2005
karax, tu vorbesti de implemenatari, colegii vorbesc despre altceva

#8
Rhesus

Rhesus

    Senior Member

  • Grup: Senior Members
  • Posts: 2,882
  • Înscris: 22.04.2014
@OriginalCopy a inteles la ce ma refer.

O sa iau un exemplu concret (la subiect).

1. Cerință: Să se modeleze conceptual ideea unul modul, care conține un set de proprietăți și un set de comenzi. Hai să luăm un dispozitiv wireless, cu care putem comunica și de la care primim diverse valori.

public class Module
{
	 public object P1
	 {
		 get;
		 private set;
	 }
	 public object P2
	 {
		 get;
		 private set;
	 }
	 public Module()
	 {
		 //...
	 }
	 public void Command1() { }
	 public void Command2() { }
}


2. Ulterior, ne dăm seama că vom avea mai multe astfel de dispozitive in aplicatie, cu implementări asemănătoare (mici variațiuni între ele):

public interface IModule
{
		 object P1
	 {
		 get;
		 set;
	 }
		 object P2
	 {
		 get;
		 set;
	 }
	 void Command1();
	 void Command2();
}
public class Module1 : IModule
{
	 // implementare
}


3. Apoi, ne dăm seama că vom avea un set complet diferit de comenzi/proprietati (ca implementare), deoarece aplicația conține n dispozitive, de la n vendori, cu n API-uri diferite. Reorganizăm:
public interface ICommand
{
}
public class Command : ICommand
{
}
public interface IProperty
{
}
public class Property : IProperty
{
}
public class Module
{
	 List<ICommand> CommandList;
	 List<IProperty> PropertyList;
	 // ...
}


În fapt, am pornit de la prima variantă, care nu este greșită la momentul t1.

Dacă ar trebui să programez din start varianta (3.) aș pierde din eficiență (nu computațională): Dacă stai să modelezi fiecare entitate din program la nivelul (3.) - si as mai putea continua -, riști să nu-ți duci taskul la bun sfârșit în timp util...

Iar nivelul de abstractizare de mai sus încă e ok! Dacă am crea și un Builder (IModuleBuilder) și cu implementările aferente, am trece lejer de nivelul KISS ...

Edited by Rhesus, 20 November 2019 - 19:51.


#9
OriginalCopy

OriginalCopy

    I'm harmful, fear me please! :))

  • Grup: Senior Members
  • Posts: 27,268
  • Înscris: 10.08.2006
1. Când citesc cerința, mă duc automat cu gândul la command pattern. Deci fac command pattern din start. Și nu, acele 3 minute în plus la implementarea Command la pasul 1 nu sunt costuri, sunt jucării. Că nu suntem pe plantație, ci e o meserie intelectuală.

Pașii următori sunt apoi mai simpli, relativ la ce obiective ating și ce business value ofer.


Da, chiar despre 3 minute vorbim. Arhitectură nu înseamnă ce bullshit încearcă să îți vândă corporatiștii. Înseamnă pași mărunți dar siguri.


Dar... De ce as face asta la pasul 1? De ce pariez pe infinity din principiul zero-one-infinity?

Pentru că e o decizie importantă și pt că firmele care au succes de multe ori se transformă dintr-un produs marca lor într-un produs whitelabeled.

Peștii mari care vin la clientul tău și îi cer whitelabel plătesc gros, și clientul tău va fi foarte fericit că ai investit acele 3 minute inițiale.


Dar e important să înțelegi la cel nivel de abstractizare alegi calea infinity și nu calea one. O abstractizare la un nivel înalt are un nig bang for the buck.

O abstractizare undeva în colturile întunecate ale arhitecturii nu merită.

Iar așa cum ai expus tu problema, ideea de "a trimite comenzi" pare foarte centrală.

Iar dacă vine cineva și te trage la rost că de ce, faci si tu pe profesionistul: "e pentru error handling". Fără explicații. Și dacă totuși le cere, organizezi un meeting (plătit, desigur), ca să îi explici. Cu următoarea ocazie te va trata cu respect.

A, și foarte important: nu uita să îi spui că această decizie arhitecturală a costat 3 minute. La sfarsitul meetingului de 60 minute, așa, ca să simtă.

#10
Rhesus

Rhesus

    Senior Member

  • Grup: Senior Members
  • Posts: 2,882
  • Înscris: 22.04.2014

View PostOriginalCopy, on 20 noiembrie 2019 - 20:31, said:


You are the best Posted Image.

Problema e că la cum programez eu sunt două șanse:
- fie o altă persoană se prinde din prima ce vreau să fac
- fie, vorba ta, organizez un meeting de 30 de minute ca să înțeleagă ce vreau să fac. Și deloc complicat (părerea mea).

În schimb am văzut proiecte în care nivelul (arborele) de abstractizare a devenit așa de mare, și atât de non-sens, că te prinzi cu urechile. Documenție ? Yok. UML ?!?! Yok. - de fapt, aici voiam să ajung cu topicul. (dacă are sens să merg cu ”principiile” până la sfânta veșnicie).

Sper ca peste 10 ani să nu ajung ca și faza cu outputstream-ul Posted Image

PS1: Ce pretenție poate să aibă de la tine (o corporație, o firmă) să înțelegi cât mai repede, dar să fii cât mai util, toate floricele compuse de vreo minte luminată?

Iar legat de oamenii într-adevăr inteligenți care au o muncă titanică în spate - nu-mi permit să răspund. Tocmai de la ei învăț. Doar că, culmea, tocmai ei nu se leagă.

În schimb, o persoană cu câțiva ani de experiență peste mine, încearcă să o tot țină că: uite nu e bine aici, nu e bine acolo. Ce nu e bine? Hai cu un argument, și modific!

Edited by Rhesus, 20 November 2019 - 22:28.


#11
karax

karax

    Guru Member

  • Grup: Senior Members
  • Posts: 21,839
  • Înscris: 14.10.2017
Spoiler
in cazul asta scuze, nu pot fi fortate companiile sa aiba aceleasi seturi de comenzi si etc. in unele cazuri nu exista alternativa cum ar fi protocolul TCP/IP insa in cazul dat de tine nu stiu cum ar putea sa ajunga companiile la intelegere avand in vedere ca fiecare are propriul stil de algoritmica.

in fine voi stiti mai bine. personal consider ca asa cum exista n companii cu n stiluri , care fiecare ruleaza altfel pe fiecare procesor in parte , niciodata nu se va putea ajunge clar la un compromis in privinta a ceea ce e mai bun
ok bye ma duc pe alte topicuri , oricum cu greu inteleg chestiile de aici

#12
MarianG

MarianG

    be that as it may

  • Grup: Moderators
  • Posts: 31,320
  • Înscris: 10.08.2005
Apreciez mult.
Multumesc pt intelegere

Edited by MarianG, 21 November 2019 - 10:09.


#13
MartinAdelberg

MartinAdelberg

    Member

  • Grup: Members
  • Posts: 866
  • Înscris: 23.08.2019

View PostRhesus, on 19 noiembrie 2019 - 19:20, said:

Întrând în contact cu mai mulți programatori (unii cu zeci de ani de experiență în spate), am remarcat două ... hai să le spunem tipologii.
1. Tipologia programatorului pentru care principiile (și în general tot ce ține de procedee/design patterns/software patterns/best practices/etc.) sunt "sfinte".
Ii gasesti in mediul freelancing, sunt din ce in ce mai rari.Sunt incompatibili cu Agile mindset, vad software ca pe o opera de creatie
Intotdeauna timpul nu este important daca  acest timp le este platit de altcineva care isi permite sa le dea bani cu sacul si de preferat sa nu intrebe

Quote

2. Tipologia programatorului care consideră eficiența mai presus decât orice (chiar și cu "riscul" incalcarii flagrande a (1.)).
Ii gasesti predominant in mediul corporate,  respecta design patterns doar daca timpul le permite.Este full compatibil cu Agile mindset
Timpul de livrare este crucial si sub nici o forma nu trebuie depasit.La extreme daca este, se prefera sacrificarea calitati pentru a termina la deadline, urmand
ca ulterior sa se revina cu un update incremental pt a optimiza zonele unde s-a facut rabat de la calitate pentru a termina la deadline.
Vad software-ul ca pe un serviciu si nu ca pe un produs. Cine furnizeaza primul serviciul respectiv castiga si il poate baga in faliment pe competitorul sau
care lucreaza la un serviciu similar dar inca mai are de lucrat.Cine livreaza primul repede si bine castiga,

Quote

Dacă gândim KISS (keep it stupid simple) atunci majoritatea pattern-urilor (Builders, Adapters, Wrappers, Bridge, Decorators, etc.) complică situația. Un conector de 100 de linii de cod poate să ajungă la 500-1000 doar prin aplicarea unui wrapper. Corectitudinea? Identică cu prima variantă ...
Dacă am avea 10 conectori, care moștenesc un anumit pattern, atunci, da, se impune abstractizarea (si implicit code reusability).
Departamentele de software au arhitecti care asta fac toata ziua.Proiecteaza arhitectura software astfel incat combinatiile de pattern sa avantajeze dezvoltarea rapida
si corespunzatoare a viitorului serviciu software.

Quote

Și atunci, vă întreb: În momentul dezvoltării (chiar în prima fază), cine "câștigă” ... eficiența (cu riscul de a încălca unele principii SoC) sau "cartea" ?
Castiga cel care poate imbina cat mai bine cartea cu eficienta astfel incat sa scoate primul repede si bine acel serviciu software.Iar pt asta ai nevoie de ahitecti si nu doar  programatori care sa faca si arhitectura si dezvoltare in acelasi timp.N-ai avea cum sa livrezi repede un produs in acest caz.

Edited by MartinAdelberg, 21 November 2019 - 21:37.


#14
Rhesus

Rhesus

    Senior Member

  • Grup: Senior Members
  • Posts: 2,882
  • Înscris: 22.04.2014

View PostMartinAdelberg, on 21 noiembrie 2019 - 21:37, said:

Castiga cel care poate imbina cat mai bine cartea cu eficienta astfel incat sa scoate primul repede si bine acel serviciu software.Iar pt asta ai nevoie de ahitecti si nu doar  programatori care sa faca si arhitectura si dezvoltare in acelasi timp.N-ai avea cum sa livrezi repede un produs in acest caz.

Părerea mea e că un programator nu este complet dacă nu acoperă și partea de arhitectură. Altfel e un code monkey. Habar nu are ce se intampla, scrie cod (poate chiar de 2-3 ori mai mult decat primul), si .... e mai eficient! Si se pare ca asta e cautat.

Eu daca cer la un nenea UML sau macar o documentatie (pe care sa o citesc acasa), rade de mine Posted Image.
Voi ce parere aveti? Daca merg la voi, am batut palma, dar inainte de toate cer o documentatie minima (sau UML), incepeti sa radeti cu lacrimi?
PS. Bineinteles, vorbesc de cazul in care sunt integrat intr-un proiect pe tam-nesam.

Am lucrat si in proiecte de freelancing, iar cel putin 1-2 saptamani am acordat modelarii UML...., de aia sunt obisnuit sa am ceva la mana inainte de a lucra la acel ,,ceva”. Mi-am mai luat și intitulatura de programatorul filosof dar nu dus la extrem (am si zis in primul post: chiar sunt contra abstractizarii duse la extrem, ci doar la nevoie) ... și de aici toate hater-urile.

Edited by Rhesus, 21 November 2019 - 23:17.


#15
romio79

romio79

    Active Member

  • Grup: Members
  • Posts: 1,655
  • Înscris: 30.03.2005
eu in 15 ani am vazut uml cam de 2 ori si aia era ceva de genu saptamana viitoare avem audit, hai sa facem repede ceva sa para ca avem documentatie :D

#16
Rhesus

Rhesus

    Senior Member

  • Grup: Senior Members
  • Posts: 2,882
  • Înscris: 22.04.2014

View Postromio79, on 21 noiembrie 2019 - 23:18, said:

eu in 15 ani am vazut uml cam de 2 ori si aia era ceva de genu saptamana viitoare avem audit, hai sa facem repede ceva sa para ca avem documentatie Posted Image
Posted Image Posted Image.

Esti martir...

Edited by Rhesus, 21 November 2019 - 23:48.


#17
MartinAdelberg

MartinAdelberg

    Member

  • Grup: Members
  • Posts: 866
  • Înscris: 23.08.2019

View PostRhesus, on 21 noiembrie 2019 - 23:08, said:

Părerea mea e că un programator nu este complet dacă nu acoperă și partea de arhitectură. Altfel e un code monkey.
Nu, nu este.Sunt joburi separate. Arhitectul este arhitect si programatorul este programator.
Daca programatorul ar face pe arhitectul atunci nu mai are cand se scrie cod(daca este pe Agile)
Daca arhitectul ar face pe programatorul atunci inseamna ca nu are destui oameni ca sa duca la indeplinirea implementarea ahitecturii software in timpul alocat.

Quote

Habar nu are ce se intampla
Si de multe ori chestia este benefica. Modulele de executie sunt separate intre ele prin abstractiuni(interfete) iar fiecare programator isi are modulul
sau unde stie ce date ii intra si ce data trebuie sa scoata.Cam asta consta meseria de programator.
Acelasi lucru se intampla cand proiectezi de exemplu un satelit/locomotiva/vapor.
Cei care fabrica elicea unui vapor n-au nici o treaba cu cei care fabrica sistemul de ancore.
Iar cei care proiecteaza motoarele unui vapor n-ai nici o treaba cu cei care proiecteaza mobila de interior.
Insa la nivel Macro exista un arhitect sau echipa de arhitecti care stie cum sa imbine toate aceste chestii  ca sa iasa la timp vaporul si cu motoare si cu ancore si cu mobila
de interior iar aceste echipe de multe nu stiu de existenta reciproca.

Quote

Eu daca cer la un nenea UML sau macar o documentatie (pe care sa o citesc acasa), rade de mine .
Cum sa iei documentatie acasa ? Acolo sunt chestii confidentiale care nu au voie sa parasesca premisele firmei iar daca se trimit pe mail, atunci se face arhiva parolata
astfel incat daca cumva contul tau este compromis, atacatorul sa nu aiba acces la informatia protejata prin parolata.Vorbim aici de un minim data-governance.

Quote

Voi ce parere aveti? Daca merg la voi, am batut palma, dar inainte de toate cer o documentatie minima (sau UML), incepeti sa radeti cu lacrimi?
PS. Bineinteles, vorbesc de cazul in care sunt integrat intr-un proiect pe tam-nesam.
Daca vii la mine, in prima luna nu lucrezi nimic, ci doar documentatie citesti si apoi esti testat prin discutii libere cat ai retinut din documentatia proiectului.
20 de zile , 8 ore pe zi, citesti la documentatie de te saturi. Si nu ma refer la "polologhie" ci documentatie strict pe subiect, inclusiv cu scheme logice, etc si tot
tacamul.

Quote

Mi-am mai luat și intitulatura de programatorul filosof
Nu inteleg.

View Postromio79, on 21 noiembrie 2019 - 23:18, said:

eu in 15 ani am vazut uml cam de 2 ori si aia era ceva de genu saptamana viitoare avem audit, hai sa facem repede ceva sa para ca avem documentatie Posted Image
Noi tratam software-ul ca pe un serviciu ,insa realizarea sa o facem dupa regulile ingineriei de produs(pt ca si serviciu este un produs in contextul pietei de bunuri si servicii).
Iar in ingineria de produs , echipa de QA face diagramele UML si schemele logice ale softurilor produse de noi, iar acelea sunt anexate la documentatie care este revizuita de arhitectul
respectiv care este repartizat pe X module. Alt arhitect este repartizat pe Y module si tot asa.

#18
OriginalCopy

OriginalCopy

    I'm harmful, fear me please! :))

  • Grup: Senior Members
  • Posts: 27,268
  • Înscris: 10.08.2006

View PostRhesus, on 20 noiembrie 2019 - 22:16, said:




Sper ca peste 10 ani să nu ajung ca și faza cu outputstream-ul Posted Image


De ce?

Anunturi

Bun venit pe Forumul Softpedia!

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate