Best practices in development

[danielbuca]

Tocmai am scris pe blog un articol despre best practices in development si m-am gandit ca este ok sa-l ofer si comunitatii de aici.

Nu te repeta
Conform acestui principiu, atunci cand scrii cod, trebuie sa eviti sa repeti sectiuni logice similare in mai multe locuri.
Ideea este ca atunci cand vrei sa faci modificari asupra unui segment al aplicatiei pe care o dezvolti sa nu fii nevoit sa faci modificari in mai multe parti ale acesteia.
Principiul se extinde si asupra bazei de date si se cheama normalizare.

Bineinteles ca exista si exceptii de la acest principiu, atunci cand situatia o cere.
De exemplu: poti crea redundanta in baza de date daca asta aduce un plus de performanta aplicatiei.

Urmeaza o conventie
Si acest principiu se aplica atat la cod cat si la baza de date.
Nu conteaza ce conventie atata timp cat tu si ceilalti membrii ai echipei implicate in proiect o urmati.
Folosind aceeasi conventie duce la eficientizarea lucrului in echipa.

Scrie cod pentru oameni
Acest principiu este legat oarecum de cel anterior.
Chiar daca scrii cod folosind aceeasi conventie ca si colegii tai, chiar daca scrii comentarii tot nu este suficient uneori.
Gandeste-te ca alti oameni vor citi acest cod si cu cat inteleg mai repede ce se intampla acolo, cu atat mai repede isi vor face treaba.
Asta inseama ca numele de variabile, de functii, de clase, de tabele si campuri din baza de date sa fie scrise cat mai natural, inteligibil.

Scrie reutilizabil
Atat baza de date cat si codul scris trebuie gandite, in limite rezonabile si atunci cand e posibil, pentru a fi reutilizate.
Chiar daca vorbim de o functie, de o secventa de cod sau de o tabela sau chiar mai mult acestea trebuie scrise in asa fel incat sa le putem utiliza si in alte module ale aplicatiei si in alte aplicatii.
Nu incercati sa scrieti un intreg framework personal de la primul proiect, acesta poate prinde contur in timp.

Revino pe cod pentru optimizari si rescriere
Niciodata nu vom reusi sa scriem cod exceptional de la prima incercare oricat am vrea.
Din cauza aceasta este bine sa ne intoarcem pe cod pentru optimizare.
Deasemenea, putem reveni pe cod pentru a rescrie portiuni din acesta din diverse motive, atat estetice cat si de functionale.

Bineinteles ca aceste principii nu sunt nici perfect si nici suficiente. Sunt doar un punct de plecare sau o sursa de inspiratie.

[Tudi]

You must spread your rep around before bla bla. Dar ai aprecierea mea pentru postul asta. Nu pentru ca as fi programator, ci pentru ca ajuti la popularea forumului cu continut de calitate.

[danielbuca]

Multumesc pentru aprecieri.
Intotdeauna am considerat ca daca toti am oferii experienta noastra celorlalti ne-ar fi mai bine tuturor.

[haos]

Pai doar atat, doar 5?

[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" ...

[danielbuca]

Open/Close Principle este si el un principiu de baza (multumesc pentru reminder) care este foarte important.

Eu, la momentul respectiv, l-am inteles cam asa: in momentul in care construiesti o aplicatie trebuie sa iti construiesti un sistem piramidal plecand de la cele mai simple funtionalitati sau de la cele mai simple entitati si mergand spre functionalitatile sau entitatile de care ai nevoie.

Modul acesta de lucru este foarte bun, l-am folosit si in alte domenii cu succes. Intotdeauna este mai usor sa spargi o problema complicata in probleme mai mici care au rezolvari simple si evidente.

Desi Open/Close Principle se refera strict la development acesta poate fi adaptat si in alte domenii.

Cred ca majoritatea dintre noi am folosit acest principiu, chiar daca nu stiam de el, in unul sau mai multe cazuri. Atunci cand folosim totusi constient acest principiu este foarte benefic pe long term.

[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).

[danielbuca]

Pair programming, uite un lucru care mi s-a parut intotdeauna foarte interesant dar nu am avut niciodata posibilitatea sa experimentez.
E un sistem care ar trebui folosit ocazional, nu permanent, si cel putin cu scop de mentoring / tutoring / knowledge share.

Vreunul dintre voi a experimentat pana acum pair programming ? Please share