Ingineria Programarii: Faza de Implementare

Ingineria programrii
11. Faza de implementare
Florin Leon
Universitatea Tehnic Gheorghe Asachi din Iai
Facultatea de Automatic i Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
Faza de implementare
1. Introducere
2. Procesul de implementare
3. Refactorizarea
4. Analiza static
5. Metrici de implementare
6. Anti-abloane de implementare
7. Managementul configuraiei
8. Concluzii
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Implementarea este faza n care este produs codul

corespunztor proiectului
Se ndeplinesc restriciile de resurse, acuratee i performan

indicate de specificaii
Sistemul este construit ori plecnd de la zero, ori prin

asamblarea unor componente pre-existente
De cele mai multe ori proiectarea nu va realiza o
transformare de 1 la 1 ctre implementare
Este necesar un oarecare efort pentru a scrie codul

corespunztor, iar aceasta este o surs de erori
Erorile de proiectare determin pierderea timpului
programatorilor n a rezolva probleme puse greit
4
Erori
Implementarea nsi este predispus ctre

erori, fiind un proces creator uman
Un programator are 50% anse s descopere
o eroare ntr-un interval de 5-10 linii de cod i
numai 20% anse s o descopere ntr-un
domeniu de 40-50 linii
Documente
Documentele de baz produse n aceast

faz sunt:
Codul surs comentat, respectnd anumite

convenii
Diagrame ale produsului software
Manualul de utilizare
Planul pentru coordonarea configuraiei
(versionare)
Clase de limbaje
Din punct de vedere al semanticii, sunt larg

recunoscute urmtoarele dou clase mari de
limbaje:
Limbaje imperative (procedurale)
Fortran, Basic, Pascal, C, C++, Java, C#
Limbaje declarative
Lisp (de exemplu dialectele Scheme, Common Lisp:

subparadigma funcional), Prolog (subparadigma
logic), Clips
7
Limbaje imperative
ntr-un limbaj imperativ, programatorul controleaz

exact execuia programului, el trebuie s defineasc
modul cum se execut prelucrrile
n general, aceste limbaje suport caracteristicile
programrii structurate:
Secvena
Permite specificarea ordinii execuiei instruciunilor
Selecia
Permite evaluarea unei condiii i luarea unei decizii
Iteraia
Permite existena structurilor repetitive
8
Caracteristici
Diviziunea n module
Structurarea n blocuri
Impune ca un modul s aib un singur punct de intrare i de preferat un

singur punct de ieire
n multe limbaje, tipizarea puternic
Permite descompunerea funcional

n limbajele orientate obiect, programarea structurat este aplicat doar n
interiorul metodelor
Impune ca tipul fiecrei date s fie declarat

Previne aplicarea operatorilor asupra obiectelor incompatibile din punct de
vedere al tipului
Ajut compilatorul n evidenierea erorilor i n compilarea eficient
Recursivitatea
Permite unui modul s se autoapeleze

9
Limbaje declarative
Pornesc cu o concepie diferit de limbajele imperative
Programatorul nu mai controleaz explicit execuia

programului, ci specific ce trebuie realizat, care sunt regulile
care pot rezolva problema
Paii efectivi de rezolvare ai problemei i ordinea acestora

sunt decii de program, nu de programator
Construcia secven i pierde din importan; programul nu

mai poate fi vzut ca o secven de instruciuni de la nceput
pn la sfrit
Programele scrise n limbaje declarative au un aspect diferit

fa de cele scrise n limbaje imperative
10
Programarea: tiin sau art?
Arta
Construirea unor produse care pot aciona asupra

simmintelor
Tradiional, orice talent sau miestrie
gr.
tiina
Adunarea de probe prin observaii i experimente

msurabile i repetabile
Formularea de ipoteze i testarea acestora
11
12
13
JS1k (scripturi JavaScript de 1 KB)
14
Rgba and TBC Elevated (4 KB)
15
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Scopul implementrii
Implementarea afecteaz att testarea ct i

ntreinerea
Efortul de testare este 30 - 50% din efortul de

dezvoltare
Rata de efort ntreinere-dezvoltare: 60:40 80:20
Scopul nu este diminuarea costurilor de

implementare, ci a costurilor fazelor ulterioare
Programele nu trebuie s fie uor de scris,

ci uor de citit i neles
17
Experimentul Weinberg
Cnd programatorii primesc un obiectiv clar, de

obicei l ndeplinesc
ndeplinirea unui obiectiv afecteaz alte obiective
Compromisuri
18
Implementarea incremental
Simplific testarea i depanarea

(engl. debugging)
19
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Refactorizarea
engl. refactoring
Schimbrile succesive conduc la o structur suboptim a codului
Refactorizarea este o schimbare n structura intern a unui

produs software cu scopul de a-l face mai uor de neles i de
modificat fr a-i schimba comportamentul observabil
Crete complexitatea
Scade claritatea
Este o form de proiectare incremental
Rezultate:
Scderea cuplrii
Creterea coeziunii
Respectarea principiului deschis-nchis
21
Refactorizarea
Schimbrile pot introduce noi defecte
Refactorizarea nu se refer la introducerea de noi

funcionaliti
Cele dou activiti trebuie desprite
Refactorizarea mbuntete structura, nu codul
Refactorizarea trebuie efectuat n pai mici

Trebuie s existe teste care s indice locurile unde apar erori
Codul prost scris nu trebuie refactorizat, ci rescris
Refactorizarea nu trebuie s introduc niveluri de

complexitate inutile
Costurile suplimentare ale refactorizrii sunt compensate de
economiile ulterioare
22
Exemplu
Situaia matricol a studenilor

Structura iniial
23
Prima refactorizare
24
A doua refactorizare
25
A treia refactorizare
26
Semnale pentru refactorizare
Urmtoarele situaii sunt semnale pentru necesitatea

refactorizrii:
Cod duplicat
Metode lungi
Clase mari
Liste lungi de parametri
Instruciuni condiionale care determin diferenele de comportament
Generalitate speculativ
Se recomand polimorfismul
Ierarhie de clase n care subclasele au acelai comportament
Comunicare intens ntre obiecte (cuplare puternic)

nlnuirea de mesaje (cuplare inutil)
27
Optimizarea metodelor
Scop: simplificarea i creterea coeziunii
Prin simplificarea interfeei, scade i cuplarea
Extragerea de metode
Pentru metode lungi

O parte a metodei este transformat ntr-o nou metod
Unele din variabilele primei metode devin parametri pentru
a doua
Metodele care returneaz o valoare i schimb starea unui
obiect trebuie partiionate
O metod care schimb schimb starea
O metod care returneaz o valoare
28
Optimizarea metodelor
Adugarea de parametri
Cnd metoda trebuie s ndeplineasc

funcionaliti noi i are nevoie de mai multe
informaii
tergerea de parametri
Cnd nu toi parametrii sunt folosii efectiv
29
Optimizarea claselor
Scop: creterea coeziunii i reducerea cuplrii

Mutarea metodelor
Cnd o metod din clasa A interacioneaz mult cu obiectele
clasei B, metoda poate fi mutat n clasa B
Dac este posibil, prima metod trebuie eliminat cu totul
Dac nu, n clasa A poate fi pstrat un proxy care s delege

apelurile
Mutarea cmpurilor
Dac un cmp din clasa A este folosit mai des de ctre metodele
clasei B, cmpul poate fi mutat n clasa B
Cmpul fiind privat, referinele din clasa A trebuie modificate iar
n clasa B trebuie s se introduc proprieti accesor (get) i/sau
mutator (set)
30
Optimizarea claselor
Extragerea de clase
De obicei funcionalitatea claselor este extins

O clas poate ajunge s aib prea multe responsabiliti
Se creeaz o nou clas i apoi se aplic refactorizrile de
metode i cmpuri
Cuplarea puternic ntre cele dou clase rezultate indic o
partiionare artificial
nlocuirea valorilor de date cu obiecte
Dac asupra unor cmpuri se efectueaz operaii multiple,

acestea pot fi convertite n obiecte
31
Optimizarea ierarhiilor
Scop: utilizarea polimorfismului pentru a facilita

extensiile ulterioare
nlocuirea instruciunilor condiionale dup flag-uri

sau tipul obiectelor cu clase polimorfice
Ridicarea cmpurilor i/sau metodelor
Elementele comune sunt incluse n clasele printe
Elementele variabile sunt incluse n clasele fiu
Invers, coborrea cmpurilor i/sau metodelor pe

nivelurile unde sunt relevante
32
Resharper
Utilitar de la JetBrains, integrat cu mediul de dezvoltare

Visual Studio, care permite:
Evidenierea erorilor
Refactorizarea
Navigarea i cutarea mai uoar
Formatarea i curarea codului
Generarea automat de cod
Suport pentru testarea unitilor
https://www.jetbrains.com/resharper/documentation/
comparisonMatrix_R8_vs2013.html
33
Analiza codului (I)
34
Analiza codului (II)

IList : IEnumerable
35
Navigarea i cutarea
36
Refactorizarea
Schimbarea semnturii unei metode

Convertirea unei clase abstracte ntr-o interfa
i viceversa
Convertirea proprietilor sau indexatorilor n
metode i viceversa
Introducerea de cmpuri, variabile locale sau
parametri
Extragerea de interfee i metode
Mutarea membrilor mai sus sau mai jos n ierarhie
ncapsularea cmpurilor, redenumirile
37
Asistena la scrierea de cod (I)
38
Asistena la scrierea de cod (II)
39
Curarea codului (I)
40
Curarea codului (II)
41
abloane
42
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Analiza static i dinamic
Analiza static verific reprezentarea sistemului

pentru a descoperi eventualele probleme
(de exemplu analiza codului surs)
Analiza dinamic se ocup cu rularea i

observarea comportamentului produsului n
execuie
44
Analiza static
Analiza automat a unui program pentru detectarea

erorilor poteniale i pentru generarea de informaii utile
la depanare
Compilatoarele realizeaz o analiz static restrns, n vederea

generrii executabilului
Instrumentele dedicate au ca scop principal detectarea defectelor
Caracteristici ale analizoarelor statice:
Corectitudinea (engl. soundness): sunt corecte dac nu

detecteaz situaii fals pozitive
Completitudinea (engl. completeness): sunt complete dac nu
rateaz unele defecte existente
Este necesar un compromis
45
Analiza static automat
Analizoarele statice sunt instrumente software

pentru prelucrarea textului surs
Ele parseaz textul programului i ncearc s

descopere condiii potenial eronate
46
Verificri n analiza static
Defecte de date
Variabile utilizate nainte de iniializare
Situaia este posibil n C/C++, dar nu i n C#
Variabile declarate dar nefolosite

Variabile atribuite de dou ori dar nefolosite ntre
atribuiri
Variabile nedeclarate
Posibile violri ale limitelor de vectori
47
Defecte de control
Cod care nu poate fi atins

Ramificri necondiionale n bucle
Defecte de intrare/ieire
Variabile trimise la ieire de dou ori fr atribuiri

intermediare
48
Defecte de interfa
Nepotriviri de tip la parametri

Nepotriviri la numrul de parametri
Neutilizarea rezultatelor unor funcii
Metode neapelate
Defecte de stocare
Pointeri neatribuii
Aritmetic de pointeri
49
Abordarea 1
Cutarea tiparelor
neobinuite n cod:
Operaii idempotente
O variabil intr ntr-o

operaie cu ea nsi
Atribuiri neutilizate
Cod ne-executabil
Ramuri condiionale
imposibil de atins
50
Abordarea 1
Experimentele asupra multor sisteme software

utilizate pe scar larg au indicat c 20-50% din
atenionri sunt fals pozitive
Exist totui o corelaie puternic ntre

problemele de acest fel descoperite i erorile
reale din programe
51
Abordarea 2
Cutarea explicit a defectelor
Folosirea memoriei
neiniializate
Dereferenierea pointerilor
neiniializai
Dereferenierea pointerilor nuli
Dereferenierea pointerilor
invalizi
Dereferenierea sau returnarea
pointerilor la memorie eliberat
Scurgeri de memorie sau alte
resurse (de exemplu fiiere)
Returnarea pointerilor la
variabile locale din stiv
Diviziuni cu 0
dac size = 1, result nu este dezalocat

(scurgere de memorie)
dac size 0, se acceseaz
(derefereniaz) pointerul neiniializat
n linia 10
dac malloc nu poate aloca memorie,
se derefereniaz pointerul neiniializat
52
Utilizarea analizei statice
Valoroas mai ales cnd se folosete un limbaj

slab tipizat precum C-ul, unde multe erori nu
sunt detectate de compilator
Mai puin necesar n cazul limbajelor puternic

tipizate precum C# sau Java, care pot detecta
multe erori la compilare
53
FxCop
FxCop este un instrument de analiz static a codului care verific assembly-urile

.NET n conformitate cu recomandrile companiei Microsoft
54
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Metrici
Msuri pentru:
Dimensiune
Complexitate
56
Metrici de dimensiune
Dimensiunea ca numr de linii de cod

Ce este o linie de cod?
engl. line of code, LOC
n general, o linie nevid, care nu este comentariu
Msur corelat cu productivitatea, costul i

calitatea (defecte / KLOC)
Bunele practici curente: mai puin de 1 defect / KLOC
57
Metricile Halstead
Fie:
Vocabularul programului:
Lungimea programului:
numrul de bii necesari
pentru reprezentarea
unic a fiecrui element
Volumul programului:
Experimentele au demonstrat c volumul programului este puternic corelat

cu dimensiunea n LOC
58
Metrici de complexitate
Complexitatea indic nivelul de dificultate la

nelegerea unui modul
Metrici:
Dimensiunea: complexitatea crete cu dimensiunea

codului i cu numrul de decizii
Complexitatea ciclomatic: M = e n + 2p
vezi cursul 4, Faza de proiectare, seciunea Proiectarea

detaliat
59
Msura Halstead
Orice program trebuie s aib cel puin 2 operatori:

unul pentru apelul de funcii i unul pentru sfritul
instruciunii
n1 / 2 este nivelul relativ de dificultate datorat numrului

mai mare de operatori din program
N2 / n2 este numrul mediu de utilizri ale unui operand
Uurina de scriere sau citire
Un apel ctre alt modul este considerat un operator

Toi parametrii sunt considerai operanzi ai acestui operator
60
Variabile vii
engl. live variable
Pentru a scrie sau citi instruciunile, un programator trebuie

s in minte o serie de variabile, inclusiv altele dect cele
implicate direct n instruciunea curent
O variabil este vie de la prima pn la ultima refereniere

dintr-un modul, incluznd toate instruciunile intermediare
Pentru o instruciune, numrul de variabile vii reprezint o

msur a dificultii de nelegere a acelei instruciuni
Extindere la un modul: definirea numrului mediu de

variabile vii
61
Anvergura
engl. span
Numrul de instruciuni dintre 2 utilizri succesive ale

unei variabile
Dac o variabil este refereniat de n ori, atunci are

n 1 anverguri
Anvergura medie este numrul mediu de instruciuni

executabile dintre 2 referiri succesive ale unei variabile
62
Discuie
Complexitatea ciclomatic este definit doar pe

baza logicii de control
Variabilele vii sunt definite doar din punct de

vedere al utilizrii datelor
Anvergura este tot o msur a utilizrii datelor;

cu ct anvergura este mai mare, cu att modulul
este mai complex
63
Metrici n .NET Reflector
64
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Anti-abloane de programare
Accidental complexity
(Complexitatea accidental)
Action at a distance
(Aciunea la distan)
Blind faith (Credina oarb)
Boat anchor (Ancora de
vapor)
Busy waiting (Ateptarea
activ)
Caching failure
(Depozitarea eecului)
Cargo cult programming

Coding by exception
(Codarea prin excepii)
Error hiding (Ascunderea
erorilor)
Expection handling
Hard code
Magic numbers (Numerele
magice)
Lava flow
Spagetti code
Pentru explicaii, vezi suportul de curs

66
Anti-abloane metodologice
Copy and paste programming
Improbability factor (Factorul de improbabilitate)
Low hanging fruit
Premature optimization (Optimizarea prematur)
Programming by permutation (Programarea prin

permutri)
Reinventing the wheel (Reinventarea roii)
Reinventing the square wheel
Pentru explicaii, vezi suportul de curs

67
1. Introducere
3. Refactorizarea
4. Analiza static
8. Concluzii
Managementul configuraiei
Pe parcursul ciclului de via al unui proiect de

dezvoltare software sunt create i actualizate un
mare numr de elemente, precum module de
cod surs, cerine de modificare etc.
Pentru gestionarea acestora trebuie s existe un

set de proceduri bine definite, care poart
numele de managementul configuraiei
69
Definiii (standarde IEEE)
Linie de baz (engl. baseline)
O specificaie sau un produs care a fost analizat i

acceptat n mod formal, care servete n continuare ca
baz pentru dezvoltarea viitoare i care poate fi modificat
numai prin proceduri formale de control al modificrilor
Articole de configuraie (engl. configuration items)
O colecie de elemente hardware sau software tratate ca o

unitate n scopul gestionrii configuraiei
Exemple: fiiere surs, module de cod obiect, specificarea

cerinelor, documentaia de proiectare, planul, cazurile i
rezultatele testrii, manualul utilizatorului etc.
70
Noiuni
Controlul surselor
Reine structura directoarelor i fiierelor de cod surs

ale proiectului dezvoltat i gestioneaz modificrile i
accesul concurent la acestea
Controlul versiunilor
Un sistem de control al surselor care memoreaz

modificrile fcute asupra fiierelor i permite
inspectarea, regsirea i compararea oricror variante
(versiuni) ale unui fiier pe durata ntregului ciclu de
dezvoltare
71
Cerere de modificare
Modificarea este trimis comisiei de control al

configuraiei (CCC)
CCC evalueaz cererea, care poate fi aprobat,

respins sau amnat dac sunt necesare mai
multe informaii. Dac este aprobat, se stabilete
un termen de implementare
CCC se asigur c toate articolele de configuraie

afectate de schimbare vor fi actualizate
corespunztor
72
Numerotarea versiunilor
Schema GNU: versiunea major, versiunea minor i patch-ul

(triplet de ntregi)
ntre dou versiuni majore, n produs au loc schimbri majore ale

funcionalitii i nu este garantat compatibilitatea napoi
ntre dou versiuni minore ale aceleiai versiuni majore trebuie s existe
compatibilitate
Rolul unei versiuni minore este introducerea unor funcii noi. Funciile
vechi nu sunt ndeprtate; totui documentaia programului l poate
avertiza pe utilizator c la anumite funcii se va renuna n viitor (sunt
marcate ca obsolete sau deprecated)
Patch-ul nu poate realiza dect schimbri n implementarea unor funcii.
De obicei, rolul su este corectarea unor defecte ale programului
Aceste reguli nu se aplic ns i pentru programele n versiuni alfa sau
beta (0.X)
Microsoft .NET: major, minor, build, revision

73
Instrumente de control
al versiunilor
Alturi de alte produse, menionm:
Microsoft Visual SourceSafe (VSS)

Concurent Versions System (CVS)
Subversion (SVN)
Microsoft Team Foundation Server (TFS)
74
Microsoft Visual SourceSafe
Sistem de control al versiunilor destinat n

special dezvoltrii software, dar util pentru
gestionarea versiunilor oricrui tip de documente
Previne pierderea accidental a fiierelor
Permite revenirea la o versiune anterioar
Permite partajarea i mbinarea fiierelor
Permite lucrul cu proiecte ntregi
75
Check in
76
Check in
77
Proiectele SourceSafe
78
Check out
79
Memorarea versiunilor
Pentru fiiere surs

se recomand
memorarea tuturor
versiunilor
Pentru fiiere
binare se poate
reine numai ultima
versiune
80
Lock-Modify-Unlock
Un dezvoltator preia
(checks out) un fiier
n mod exclusiv
Lucreaz asupra lui
n acest timp fiierul
este blocat pentru
ceilali dezvoltatori
Primul dezvoltator
ncarc la loc (checks
in) fiierul
Fiierul este deblocat
81
Preluarea non-exclusiv
82
Copy-Modify-Merge
83
Modificrile
84
Check in multiplu
85
File Difference
86
File Difference (Format Visual)
87
Merge (mbinarea)
Versiunea de baz
Versiunea surs
Versiunea destinaie
88
mbinarea: conflicte
89
Share (partajarea)
Permite ca un fiier c fie partajat de mai multe proiecte

Dac fiierul este modificat ntr-un proiect, schimbrile
se vor reflecta simultan i n celelalte proiecte
90
Branch (ramificarea)
Permite ca dup partajare (Share), fiierele comune s devin

independente
Exemplul 1
Exemplul 2
2 proiecte foarte asemntoare pentru 2 clieni diferii
O mare parte a proiectelor este comun
Unele fiiere specifice sunt diferite
Se partajeaz un proiect (recursiv) i se ramific fiierele
specifice
91
Cloak (ascunderea)
Proiectele de
dimensiuni mari, care
se modific rar, pot fi
ignorate n cadrul
operaiilor recursive
Fereastra de
proprieti pentru
directoare/proiecte,
nu pentru fiiere
92
Label (etichetarea)
Permite etichetarea fiierelor sau proiectelor
O scurt descriere n vederea identificrii mai uoare
File Label... / Show History...
93
Concluzii
Implementarea este faza n care este produs codul proiectat,

ndeplinind restriciile de resurse, acuratee i performan
indicate de specificaii
Exist limbaje imperative (procedurale), precum C/C++, Java,
C# i limbaje declarative, precum Lisp, Prolog, Clips
Alegerea unui limbaj trebuie s in seama de natura
proiectului, de timpul dorit pentru implementare i de
experiena echipei
Structura programului trebuie optimizat ori de cte ori este
necesar prin refactorizare
Visual SourceSafe este un instrument des utilizat pentru
controlul versiunilor
94

Ingineria Programarii: Faza de Implementare

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ingineria Programarii: Faza de Implementare

Încărcat de

Drepturi de autor:

Formate disponibile

Ingineria programrii

11. Faza de implementare

Implementarea este faza n care este produs codul

Se ndeplinesc restriciile de resurse, acuratee i performan

Sistemul este construit ori plecnd de la zero, ori prin

Este necesar un oarecare efort pentru a scrie codul

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Implementarea nsi este predispus ctre

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Documentele de baz produse n aceast

Codul surs comentat, respectnd anumite

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Din punct de vedere al semanticii, sunt larg

Limbaje imperative (procedurale)

Fortran, Basic, Pascal, C, C++, Java, C#

Lisp (de exemplu dialectele Scheme, Common Lisp:

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

ntr-un limbaj imperativ, programatorul controleaz

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Impune ca un modul s aib un singur punct de intrare i de preferat un

n multe limbaje, tipizarea puternic

Permite descompunerea funcional

Impune ca tipul fiecrei date s fie declarat

Permite unui modul s se autoapeleze

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Pornesc cu o concepie diferit de limbajele imperative

Programatorul nu mai controleaz explicit execuia

Paii efectivi de rezolvare ai problemei i ordinea acestora

Construcia secven i pierde din importan; programul nu

Programele scrise n limbaje declarative au un aspect diferit

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Programarea: tiin sau art?

Construirea unor produse care pot aciona asupra

Adunarea de probe prin observaii i experimente

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Programarea: tiin sau art?

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Programarea: tiin sau art?

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Programarea: tiin sau art?

JS1k (scripturi JavaScript de 1 KB)

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Programarea: tiin sau art?

Rgba and TBC Elevated (4 KB)

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Implementarea afecteaz att testarea ct i

Efortul de testare este 30 - 50% din efortul de

Scopul nu este diminuarea costurilor de

Programele nu trebuie s fie uor de scris,

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Cnd programatorii primesc un obiectiv clar, de

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Simplific testarea i depanarea

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Refactorizarea este o schimbare n structura intern a unui

Este o form de proiectare incremental

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Schimbrile pot introduce noi defecte

Refactorizarea nu se refer la introducerea de noi

Cele dou activiti trebuie desprite

Refactorizarea mbuntete structura, nu codul

Refactorizarea trebuie efectuat n pai mici

Codul prost scris nu trebuie refactorizat, ci rescris