De ce IP?

De ce IP?

Ingineria Programării pentru că altfel terminăm facultate şi nu suntem altceva decât "dactilografi" de cod.

[ Anul acesta ţin 2 laboratoare de IP, şi m-am gândit că ar fi o idee bună să dau şi o motivaţie studenţiilor care şi-au ales această materie. Mi se pare important ca un student să ştie de ce urmează o materie, de ce ar trebui să investească timp în aceea materie. Drept urmare: ]

Din păcate, multe materii, nu neapărat prin natura lor, ci prin modul în care se face notarea temelor, dar mai ales prin modul în care abordăm noi, studenţii, temele, ne obişnuiesc să scriem cod direct, cât mai rapid, cât mai pe ultima sută de metrii, fără documentaţie, fără un plan bine pus la punct.

Problema apare în momentul în care treci la un nivel de proiecte mai complexe.
În momentul în care te angajezi, sau chiar în momentul în care lucrez la lucrare de diplomă. Pentru că atunci când proiectul nu mai este o temă cu o cerinţă bine formulată, cu teste publice, cu o complexitate redusă, ce se poate rezolva cu 2 zile de coding intens şi 8L de cola, sistemul "asta-i cerinţa, hai să-i dăm bătaie la scris cod" nu mai funcţionează.
De ce? pentru că e mai bine să proiectezi o dată şi să scrii de 2 ori ( rar o să fie totul ok chiar din prima, indiferent cât de bine planifici ), decât să te apuci direct şi să scrii de 6 ori.

Astfel, unul din scopurile fundamentale ale acestei materii este să obişnuiască studentul să se apuce de cod doar după care are un plan bine formulat, o structură bine definită a datelor, a modulelor, a cazurilor de utilizare.

Bineînţeles, important este ca studentul să nu reinventeze roata, ci să aplice unul din modelele consacrate. Model consacrat însemând un model care a fost testat şi folosit cu succes de multe ori.

Ingineria Programării pentru ca rar scriem cod pentru noi, în general dezvoltăm programe pentru un client. Drept urmare, trebuie să învăţăm să interacţionăm şi cu un clinet ne tehnic. Este uşor să scrii o temă specificată de un asistent care are un background ingineresc comun.
Pe de altă parte, în general clienţii noştrii nu or să fie ingineri. Or să fie oameni care or să zică "vreau X, Y, Z, iar X să fie aşa, Y am auzit de la un prieten că este foarte tare, iar la Z vreau ceva dar nu prea ştiu ce vreau". Pentru a ajunge de la aşa ceva la un produs finit, este în mod evident nevoie de a realiza o analiză a cerinţelor clientului, o analiză a nevoilor sale, a cazurilor de utilizare., analiză ce trebuie adusă într-un format ce trebuie să permită clientului să verifice dacă este ceea ce vrea, şi armatei de programatori din spatele unui proiect să implementeze ce vrea clientul.

Şi nu în ultimul rând, pentru că spre deosebire de temele din facultate, softul produs la un job este folosit de către un client nu neapărat tehnic. Pentru asta trebuie să ne obişnuim să documentăm ce scriem, să realizăm un user quide, şi totul într-un format cât mai user friendly şi cât mai standarizat.

Pentru mai multe detalii, vă aştept la orele de laborator:)