Best practices in development

[danielbuca]

Este vorba de principii generale, s-au scris zeci de carti despre fiecare in parte.
Daca vrei sa discutam despre unul din principii sau sa dezvoltam subiectul esti invitatul meu.

[Chaos]

Best practices in development este o idee foarte buna si chiar merita dezvoltata. Poate asa putem sa facem share de cunostinte.. atat cat stim fiecare.
Eu as propune dezvoltarea in jurul a doua principii: Single Responsibility si Open/Close Principle.
Primul este partial reflectat de punctele 1, 4, 5 in sensul in care o clasa trebuie sa aiba un singur motiv pentru a fi modificata.
Al doilea inseamna deschis la extindere insa inchis la modificari.
Ce parere aveti?
Nu as vrea sa duc discutia pe plan "filosofic"... ci mai degraba "real life" ...

[Marius Mailat]

Nu as vrea sa duc discutia pe plan "filosofic"... ci mai degraba "real life" ...

Real life sugestiile mele sunt urmatoarele:

- alege un limbaj de programare potrivit pentru fiecare necesitate ( Java pentru Ent apps, Delphi pentru desktop tools, PhP pentru siteuri mici, etc etc)
- alege un limbaj de programare in functie de posibilitatile lui de a se extinde, de componentele si third party tools care exista
- patterns, patterns, patterns + 3rd party components
- foloseste un version control system (subversion, source safe etc)
- automatizeaza toate procesele (ex build cu protectie de aplicatie, code signing, installer, etc)

Toate real life.

[Chaos]

@mmariusel - Foarte interesanta abordarea. Si eu sunt de parere ca in development best practices trebuie sa fie de fapt o combinatie intre coding optim si proceduri de lucru bine puse la punct.
Referitor la patterns - as completa si cu de ce sunt importante si e un must know pentru orice developer. Design patterns sunt de fapt best practices pentru o anumita situatie, te scutesc de reinventarea rotii si, de cele mai multe ori simplifica o problema complexa prin spargerea ei in probleme simple dupa cum spunea si daniel mai sus.
Exista si reversul medaliei.. tendinta de a folosi patterns la orice si in orice situatie insa aici intervine partea de eficienta care si ea trebuie sa fie parte din best practices. Unul dintre cele 2 pericole majore in realizarea unei aplicatii este overengineering care e la fel de periculos ca si underengineering cu diferenta ca primul nu e la indemana oricui.
As incheia pentru moment cu: refactorizari continue prin identificarea si rezolvarea de "coding smells" dar si code review ocazional si (daca permit resursele) pair programming (pot sa iasa niste lucruri foarte frumoase in sistemul acesta).