Best practices in development

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.

Citat:

---

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.

---

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.

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

Pai doar atat, doar 5?

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.

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

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.

Citat:

---

Postat în original de Chaos

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.

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

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 :)

Citat:

---

Postat în original de danielbuca

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

---

E exact ce urasc eu, il consider contraindicat in programare. Este insa ideal in debugging/bug solving/optimization. Este doar un alt concept care nu neapart e un best practice.

Eu imi pierd din productivitate 80% daca e langa mine cineva, si nu sunt singurul. Insa pentru situatii de criza, gen bug solving, patch rapid etc, precum si petru optimizare de cod e perfect.

Citat:

---

Postat în original de 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 :)

---

PRO
- se reduc timpii morti (nu stai singur si te uiti pe pereti daca nu ai chef sa scrii codul tau)
- erorile de algoritm (la un nivel mic) se corecteaza pe loc. De exemplu unul din doi tot observa ca al 2-lea for trebuie sa inceapa de la i+1, nu i. Erorile de sintaxa nu le mai amintesc, ele ar trebui corectate semi-automat de catre IDE.
- viteza de lucru este mai mare decat in cazul unui singur om
CON
- 2 oameni lucreaza la un calculator. Daca ambii sunt foarte motivati mai bine (repede) lucreaza singuri.
- cel cu experienta mai putina s-ar putea simti intimidat
Cam astea au fost concluziile mele dupa aplicarea tehnicii de vreo 2 ori (oameni diferiti, proiecte diferite).

Da, sunt de acord cu observatiile dar totusi nu credeti ca ar fi bun si pentru perioadele de training de exemplu? sau pentru sesiuni de tutoring sau knowledge exchange?
Ma gandesc la pair programming ca la un principiu de urmat atunci cand ne gandim la self improvement si nu neaparat la eficientizarea procesului de lucru.

@mmariusel: lol, credeam ca sunt eu mai ciudat pt ca nu pot lucra si numai daca am senzatia ca s-ar putea uita cineva peste umarul meu :)

O resursa relativ noua, 25 Most Dangerous Programming Errors

Le-am citit :)
Interesant (si adevarat) dar mult prea pompos prezentate.

Nu e o metoda eficienta de lucru.. aia e clar (de aceea am si mentionat "daca o permit resursele").
Cu totii avem cred o retinere in a lucra cand cineva se uita peste umarul nostru.. si fiecare are motivele lui.
Cum zicea si alecs, atunci cand sunt doi programatori de nivele diferite cel mai putin experimentat s-ar putea simti intimidat oarecum. Totul trebuie vazut insa constructiv (sau cel putin asa ar trebui sa fie). E incredibil ce transfer de know how se face in felul asta printr-o simpla intrebare "De ce?".
In primul rand.. cel care pune intrebarea primeste un raspuns si in al doilea rand se "sedimenteaza" niste cunostinte in momentul in care raspunzi unei intrebari si de multe ori (cel putin mie mi s-a intamplat) am vazut probleme in ce faceam sau rezolvari mai bune ale unei probleme specifice.
Trebuie sa fiu totusi de acord ca se muleaza cel mai bine la refactorizari si debugging.