Cum să-ți construiești proiectul

Introducere in programare

FII @ 2016

Pasul 1

?

Cuprins

1. Descompunerea proiectului
2. Proiectare
3. Interfață
4. Implementare
5. Evaluare personală
6. Prezentare

1. Descompunerea

Notă: Preferabil nu așa.

1. Descompunerea

1. Specificații
2. Funcționalități (Features)
3. Posibile probleme în realizarea specificațiilor

1. Descompunerea

1.1 Specificații

1. Descompunerea

1.1 Specificații

Specificațiile reprezintă o descriere cât mai completă a aplicației ce urmează a fi construită.

Din această descriere, ar trebui să poată fi deduse foarte ușor scopul, nivelul de calitate al întregii aplicații, serviciile oferite și utilitatea lor, o listă de opțiuni principale.

1. Descompunerea

1.1 Specificații

Importanță: Foarte mare!

O aplicație nu ar trebui să fie dezvoltată fără o listă de specificații clară și bine pusă la punct. 

Dezvoltarea fără specificații duce de cele mai multe ori la aplicații slab implementate, predispuse la vulnerabilități, forțate să respecte ideologia "Las' că merge ș-așa".

1. Descompunerea

1.2 Funcționalități (Features)

1. Descompunerea

1.2 Funcționalități (Features)

Specificațiile  trebuie să conțină o listă de funcționalități pe care aplicația le va oferi.

Funcționalitatea unei aplicații trebuie să fie mereu legată și să respecte complet scopul acelei aplicații.

1. Descompunerea

1.2 Funcționalități (Features)

Exemplu negativ:

Jocul Mario care îți oferă și posibilitatea de a-i spune prăjitorului de pâine din bucătăria vecinului să facă clătite.

1. Descompunerea

1.2 Funcționalități (Features)

Exemplu pozitiv (glumesc):

1. Descompunerea

1.3. Posibile probleme în realizarea specificațiilor

Notă: Probabil geamul nu trebuia să crape

1.3. Posibile probleme în realizarea specificațiilor

Înainte de dezvoltarea proiectului, este recomandat să identificați posibilele probleme de implementare pe care le veți întâmpina.

Acest pas împiedică dezvoltarea unui proiect imposibil, care stagnează în mijlocul procesului de implementare și ajută și la dezvoltarea unei arhitecturi care să suporte lista de funcționalități.

2. Proiectare

2. Proiectare

2.1 Proiectare arhitecturală

Acest pas presupune să stabiliți modul în care interacționează modulele aplicației voastre între ele și cum comunică cu entități exterioare, acolo unde este cazul.

Acest pas este foarte important. O proiectare incoerentă logic duce la îngreunarea procesului de dezvoltare și apariția unor bug-uri neașteptate.

Notă: De parcă există bug-uri așteptate..

2. Proiectare

2.1. Proiectare arhitecturală

Un exemplu de diagramă UML de clase:

Fig. 2.1.1 - Exemplu de diagrama UML

2. Proiectare

2.1. Proiectare arhitecturală

Figura 2.1.1 descrie relațiile între clasele de obiecte dintr-o aplicație.

O scurtă explicație:

Un <Customer> lucrează direct doar cu un <Order>, dar nu și cu <Order Details>. 

Mai multe detalii în anii următori... sau poate dacă întrebați maimuța pe care ați câștigat-o.

2. Proiectare

2.2. Modularizare

2. Proiectare

2.2. Modularizare

Modularizarea presupune împărțirea codului în module (clase, fișiere cu funcții, etc) astfel încât fiecare modul să aibă un scop precis.

Exemplu: Un fișier plin cu funcții care lucrează strict cu structura denumită "Maimuță".  
Exemplu de funcții: spală_maimuța, hrănește_maimuța.

2. Proiectare

2.2. Modularizare

Modularizarea permite organizarea logică a codului sursă și încurajează lizibilitatea și coerența.

De asemenea, și lucrul în echipă este mai ușor (dacă programul vine cu o listă de specificații pentru fiecare modul).

Importanță: Foarte mare!

2. Proiectare

2.2. Modularizare

Sfat: Gradul de modularizare ar trebui să fie direct proporțional cu nivelul de complexitate a proiectului.

Exemplu negativ (overkill): Crearea unui modul ce afișează la ecran "Felicitări, ai câștigat o maimuță!".. și atât. 

2. Proiectare

2.3. Proiectarea modului de interacțiune

Acest pas presupune stabilirea funcționalităților principale și modul în care acestea se execută atunci când utilizatorul interacționează cu aplicația voastră.

Ce se întâmplă când ceri o anumită funcționalitate?

2. Proiectare

2.3. Proiectarea modului de interacțiune

Did you press the button?

Exemplu negativ: Pentru fiecare apăsare de buton din aplicație, un pop-up cu următoarea întrebare..

3. Interfață

3. Interfață

Importanță: Foarte mare!

Modul în care un utilizator interacționează cu aplicația voastră este crucial.

Interfața aleasă (ex: consolă, aplicație desktop cu formulare, website, etc) trebuie să fie foarte strâns legată de scopul și publicul țintă al aplicației.

3. Interfață

Notă: Consola poate fi un mediu foarte plăcut

3. Interfață - cum să nu

3. Interfață

Aceasta trebuie gândită pentru a fi instinctivă d.p.d.v logic (intuitivă) și cât mai ușor de folosit.

4. Implementare

A.K.A. Partea în care te simți ca un "hacker" din cauza IDE-ul cu temă închisă la culoare și filmelor americane proaste.

4. Implementare

• Implementarea specificațiilor
• Modularizarea codului conform specificațiilor
• Documentarea codului
• Documentarea bug-urilor
• Respectarea unui standard de scriere
• Implementare lizibilă, coerentă

To do list:

4. Implementare

Implementarea trebuie să fie coerentă și să expună prin nume de variabile / module / clase / funcții cât mai mult din logica aplicației.

Importanță: Foarte mare! (no code, no Christmas present!)

4. Implementare

Caracteristici de urmărit:

• Ușurință în mentenanță
• Ușurință în adăugarea de funcționalități noi
• Eficiență
• Utilitatea implementării (poate fi refolosit codul?)
• Dificultate în utilizarea incorectă a codului
• Relevanță (codul vostru are rost?)
• Cost mic în dezvoltare (timp pierdut = cost mare)

4. Implementare - cum să nu

Cod pe care îl poți înțelege peste un an.

4. Implementare - cum să nu

Cod pe care îl poți înțelege peste un an.

// Dear maintainer:

//

// Once you are done trying to 'optimize' this routine,

// and have realized what a terrible mistake that was,

// please increment the following counter as a warning

// to the next guy:

//

// total_hours_wasted_here = 42

4. Implementare - cum să nu

Documentarea asupra soluției unei probleme.

Cum să nu implementezi un vector:

int a1 = 0;  //Poziția pe rândul 1 casuța 1

int a2 = 0;  //Poziția pe rândul 1 casuța 2

int a3 = 0;  //Poziția pe rândul 1 casuța 3

int a4 = 0;  //Poziția pe rândul 1 casuța 4

int a5 = 0;  //Poziția pe rândul 1 casuța 5

int a6 = 0;  //Poziția pe rândul 1 casuța 6

....

Oare cum faci o sortare?

4. Implementare - cum să nu

Funny

#define TRUE rand()

#define FALSE rand()

//Happy debuging :)

4. Implementare - cum să nu

Funny

#define ever (;;)

for ever {

...

}

4. Implementare - cum să nu

Funny

#define if while

4. Implementare - cum să nu

Funny

#define TWO_HUNDRED_AND_EIGHTY_THREE_POINT_ONE 283.1

4. Implementare - cum să nu

Când știi că viitorul programator al aplicației nu e un tip de treabă:

function(klqwrndvp, klqwrmrvp, klqwrrgvp, klqwrrivp, klqwrxmvp, klqwrnevp, klqwrsfvp, klqwradvp) {
    klqwrcgvp = [0, 0, 2, 1], klqwrixvp = Math, klqwrtwvp = klqwrndvp(klqwrsfvp), klqwrisvp = klqwrndvp(klqwrisvp), klqwrmrvp = klqwrndvp(klqwrmrvp), klqwrzovp = 1691;
    while (klqwrzovp > klqwrxmvp.length) {
        klqwrhtvp = klqwradvp(klqwrixvp);
    }
}

5. Evaluare personală

6. Prezentare - cum să nu

I built my own browser

6. Prezentare - cum să nu

I built my own browser

It took 6 years 

6. Prezentare - cum să nu

I built my own browser

It took 6 years 

... to include IE Object

6. Prezentare - cum să nu

Bună ziua,

Aplicația mea are în principal 3 butoane...

6. Prezentare - cum să nu

Bună ziua,

Aplicația mea are în principal 3 butoane...

2 nu fac nimic. Celălalt e Exit-ul.

Concluzie

Întregul proces de dezvoltare a aplicației este important, de la definirea specificațiilor, la proiectare, design, implementare etc.

Este foarte important să acordați atenție fiecărui pas, în așa fel încât proiectul vostru să reprezinte la final un lucru de care să vă mândriți și un produs ce poate fi utilizat cu ușurință și are o rată mare de succes.

Spor la lucru!

Mulțumesc!