Ce cred ca ar mai trebui predat in liceu/facultate
In liceu si in facultate am intalnit profesori care predau informatica intr-un mod specific matematicii. Aproape la fiecare problema in liceu aparea un tipar: numarul de elemente dintr-un vector era notat cu m sau n, variabila cu care parcurgeam ciclul era i sau j sau k s.a.m.d. Asa te apucai si scriai algoritmul.
Scurt si cuprinzator?
Apoi il citeai si incercai sa intelegi ce ai scris acolo, sa-ti explici cum functioneaza algoritmul si, eventual, de ce ai scris asa si nu altfel. In momentul respectiv, creierul facea un pas in plus: descifrarea a ce inseamna n, ce inseamna i sau k. Poate nu pare mare lucru sa tii minte trei nume de variabile si sensul atasat fiecaruia, dar cand te apuci sa scrii o expresie care le foloseste pe toate trei in acelasi timp, lucrurile parca se complica putin.
M-am uitat de curiozitate pe arhiva educationala de pe infoarena, o initiativa de apreciat de altfel, ce pune la dispozitia vizitatorilor site-ului o serie de probleme pe care aproape orice elev/student le intalneste in scoala. Un lucru care mi-a placut mai putin si pe care il faceam si eu in liceu este economia de litere cand vine vorba de numele variabilelor. Este parca o obsesie generala aceea de a folosi o singura litera pentru numele unei variabile, eventual sa-i mai punem si o cifra in coada in cazurile in care alfabetul nu ne poate oferi mai multe litere.
As vrea ca atunci cand citesc un algoritm sa il citesc natural, sa nu stau la fiecare linie sa-mi spun: “a...este q, si q este notatia pentru... deci...”. Am cautat sa vad de unde vine “zgarcenia” cu care suntem invatati in scoala. Da, scoala ne ofera acest model si ne da impresia ca este "modul corect" de a face lucrurile. Cel putin asa a fost in cazul meu.
Originea zgarceniei
Banuiesc ca originea zgarceniei se gaseste in relatia cu matematica. In problemele de matematica notam cu x,y,z etc. toate variabilele de care avem nevoie si lucrurile chiar merg bine acolo. De ce acolo merg si aici nu? Cred ca in "implementarea" solutiilor problemelor de matematica avem in medie mai putine "instructiuni" si "variabile" pe foaie/caiet decat in cazul problemelor de informatica. Cate rezolvari de probleme de matematica de sute sau mii de “linii de cod” ati vazut? Eu niciuna. Tin minte ca in gimnaziu, cand aveam la matematica o problema a carei rezolvare depasea doua table, apareau dificultati in a intelege de fapt care era valoarea unei "variabile", ce reprezenta ea si unde a fost "modificata" ultima data.
De aici trag concluzia ca informatica nu se mananca in acelasi fel ca si matematica. Profesorii de informatica ar trebui sa tina cont si de lucruri ce tin de modul de scriere al codului. Aceste lucruri le-ar fi folositoare elevilor/studentilor in timpul concursurilor, cand isi recitesc algoritmul, si mai tarziu in cariera de dezvoltatori software. Si asta nu numai la clasa, ci si in toate rezolvarile pe care le propun pentru o culegere de probleme sau pentru un site gen infoarena.
In toti anii de scoala (atat in liceu cat si in facultate) nu am intalnit niciun profesor care sa scrie cod zilnic sau frecvent. Poate de aici rezulta si ignoranta pentru felul in care codul este scris.
Cum ne vindecam de zgarcenie
De ce e important sa scriem cod usor de citit? Jeff Atwood da un raspuns:
If you ask a software developer what they spend their time doing, they'll tell you that they spend most of their time writing code.
However, if you actually observe what software developers spend their time doing, you'll find that they spend most of their time trying to understand code.
Joel Spolsky spune concis:
It's harder to read code than to write it.
Cred ca este datoria fiecarui dezvoltator software sa-si imbunatateasca permanent modul in care scrie cod. Usureaza in primul rand munca sa si, in al doilea rand, pe cea a celor care vor fi nevoiti sa-I citeasca liniile de cod.
O resursa foarte buna pentru vindecarea “zgarceniei” o reprezinta cartea Code Complete, 2nd Edition a lui Steve McConnell, in principal capitolele 31 (Layout and Style), 32 (Self-Documenting Code) si 34 (Themes in Software Craftmanship).
"Write Programs for People First, Computers Second"
In cazul unui proiect cum este arhiva educationala a infoarena este cu atat mai important ca solutiile problemelor sa fie prezentate intr-o maniera cat mai usor de inteles. Principalul scop al unui cititor este sa inteleaga solutia/algoritmul, nu sa piarda timp descifrand codul “destept” sau “concis” al unei solutii.
Scriind cod mai concis, economisesc timp pretios pentru implementarea solutiei
Acest mit ia nastere mai ales in cazul concursurilor de programare, unde viteza de rezolvare a unei probleme este esentiala pentru reusita. Aceasta “economisire” de timp induce de fapt mai multe penalizari de timp in momentul citirii codului.
Steve McConnell:
Making code readable is not an optional part of the development process, and favoring write-time convenience over read-time convenience is a false economy. You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you'd have to do again and again.
Dar daca scriu cod numai pentru mine? Nu conteaza cum il scriu, oricum nu-l citesc decat eu.
Steve McConnell avertizeaza si in privinta acestei capcane:
The idea of writing unreadable code because you're the only person working on a project sets a dangerous precedent. Your mother used to say, "What if your face froze in that expression?" And your dad used to say, "You play how you practice." Habits affect all your work; you can't turn them on and off at will, so be sure that what you're doing is something you want to become a habit. A professional programmer writes readable code, period.
Liceul si facultatea reprezinta perioada in care se formeaza primele obieciuri de programare. Recent am fost neplacut surprins sa vad o lucrare (dealtfel foarte buna) la un concurs de software pentru elevi si studenti, scrisa de un student in anul I, cu experienta declarata de 7 ani de progamare, care pentru citirea propriului format din fisier folosea numai variabile denumite in genul i1...in. Codul respectiv arata foarte “egoist”, scris parca doar pentru autorul lucrarii, fara sa ia in calcul posibilitatea ca cineva sa foloseasca acel cod vreodata.
Chiar daca momentan mi se pare fantezista ideea de a vedea pe vreunul din fostii mei profesori (din liceu sau facultate) urmand sfaturile de mai sus, as fi fost mai mult decat incantat daca as fi invatat cum sa scriu cod de la ei. Probabil ca pentru a te lovi de aceste lucruri trebuie sa fi scris software mai intai.
June 22nd, 2008 - 13:24
eu nu sunt programator/dezvoltator de soft/scriitor sau ceva de genu asta, dar am facut terminat prestigiosul liceu de informatica si prestigioasa facultate de informatica (ma rog, aproape am terminat-o) deci stiu cum se “preda” informatica in scoala.
cred ca problema numarul 1 vine din pregatirea profesorilor. gandeste-te la varsta lor si la ce insemna facultatea noastra cand erau ei in scoala. gandeste-te ca majoritatea sunt profesori de mate! care au dat in ultimii ani niste diferente sau au facut niste cursuri si au voie sa predea si info. in licee, nici macar nu au facut cursuri/dat diferente. predau pur si simplu. ai pretentii prea mari pentru contextul actual din invatamant.
June 22nd, 2008 - 20:09
Bine vezi ca sint 2 aproach la problema, asta de care vorbesti este ala rusesc, inalt teoretic matematic, care la noi nu e inteles ca atare, pentru scopul e matematica algaritmului nu programare, desi asa va fi implementat. Rezultatele rusilor (care ne maninca la capitolul asta pe piine) sint de la Tetris la programele in timp real care traduc comunicatia radio, (e o fima din state care a cumparat din alea si foloseste la traducerea programelor din un limbaj in altul). Cealatata e cea practica de implemntare la care lizibilitate si codul industrila sint de baza. Imagineaza-ti task shedulerul din windows, cum functioneaza el pare contrintuitiv, pentru ca poti sa crezi ca unele teskuri nu vor vedea in veci toamna procesorul, dar matematica algoritmic a fost demostrat ca nu e asa, si practica sustine. Asta e parte 1 a problemei inplementarea cu toate detaiile tehnice a teorei vine scoala 2.
June 22nd, 2008 - 22:01
“Probabil ca pentru a te lovi de aceste lucruri trebuie sa fi scris software mai intai.”
De fapt, cred ca e “Probabil ca pentru a te lovi de aceste lucruri trebuie sa fi citit software mai intai.”
June 22nd, 2008 - 23:22
Bine punctat.
Cred ca ar mai trebuie predat si sloganul
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
June 23rd, 2008 - 11:57
Pe scurt, profesorii ar trebui sa puna accentul nu doar pe rezolvarea algoritmica, ci si pe folosirea de nume sugestive pentru veriabile.
Inavara de cazurile in care variabila corespunde unui concept abstract din matematica cu acel nume (de ex. la o ecuatie de gr. 2, e normal ca necunoscuta sa fie numite ‘x’), sunt multe cazuri unde s epot folosi nume sugestive.
Cauzale pentru care unii profesori inca folosesc nume criptice sunt multe: puterea obisnuintei, obiceiuri mostenite de pe vremea Fortran sau COBOL, unde un nume scurt pentru o variabila insemna si economie de memorie si unde se folosea conventia ca numele variabilei sa indice tipul (i, j,k pentru integer, x, y, z, pentru real etc.).
Teama de nume lungi a ramas si din anii ’80 din primele versiuni de BASIC sau Pascal, unde numele unui identificator era limitat ca lungime destul de strict.
Oricum, am intalnit si profesori de info in varsta care predau si pun accentul foarte des pe cea ce s-ar numi “better code practices”, incluzand naming guidelines, deci se poate…
June 23rd, 2008 - 13:08
Foarte bun post! Are si citate menite sa demonstreze afirmatiile spuse… asa cum imi place mie
.
Concluzia lui ar fi ca putem invata sa programam mai bine (mai readable?) ori de la profi suficient de bine pregatiti, ori de la [tineri] programatori suficient de descuiati incat sa ne impartaseasca experientele lor, nu?
June 23rd, 2008 - 15:50
@psiheea: Poate sunt putin cam pretentios
@MrSmersh: Nu sunt sigur ca am inteles la ce te referi
@Anonymous: De acord
@Monica: Mi-a placut sloganul
@Tudor: Foarte bune completari. Ceea ce spui despre existenta profesorilor care pun accent pe aceste lucruri nu poate decat sa ma bucure.
@Sonia: Multumesc pentru aprecieri!
June 24th, 2008 - 23:58
Better latter than ever
. Numca in domeniul asta are vreo 2 aspecte unul matematic algoritmic si unul industrial. In cel matematic algoritmic nu conteaza daca variabila e x sau”necunoscuta1″. Da in scoala vezi o aplicare in domeniu, dar ele au plecat sau au baza in matematica arida teoretica. In partea industrial care e puternic practica este imperativ sa ai nume de varibile sugestive, si corecte chiar dpv limbii, textEditBoxParola, portCOM, accumulator_reg 
. La noi in scoala se mai viseaza la prima parte matematica, la care multi veniti din matematica clara ori o inteleg mai bine ori spera ca acolo e viitorul de studiu. Eu cred ca matematica in Romania nu are potential in domeniul asta acuma, pentru ca si studiul matematic teoretic e cum e. Dar la industrial facem fatza cu brio (inca)… Invatamintul nu intelege si nu ajuta, sau cel putin nu suficient, dupa 5 ani “din cutie” si fara el sa fie studiat, sau sa fie antrenat on site, nu ai ce face cu un absolvent. Si sa nu spunem ca desi nu e util poate sa si vrea un salariu… 
June 26th, 2008 - 22:48
@MrSmesh: Fara suparare dar eu zic ca te inseli. Nu conteaza cata matematica e intr-un algoritm. Ramane acelasi indiferent daca tu ai variabilele notate cu p, q, r sau cu firstElement, lastElement, currentElement (ca imi bat capul cu asta acum pt. examenul de licenta
). Computer Science este format atat din partea matematizata de algoritmi si chestii cat si de partea de inginerie soft care se ocupa cu arhitecturi extensibile, design patterns, denumirea codului in mod lizibil etc. Tocmai asta e problema – ca multi nu realizeaza asta.
La inceputurile informaticii poate ca se aceptau chestiile astea, cand s-a trecut brusc de la foaie si demonstratie matematica la implementare intr-un limbaj de programare. Si tocmai de aia a aparut Code Complete si naming conventions si tot tacamul, pentru ca s-a observat ca nu merge asa. Pacat ca profesorii nostri nu stiu asta pentru ca ori sunt la catedra dinainte sa-si inventeze Turing masina, ori au ajuns profesori pentru ca nu au gasit altceva mai bun de facut si atunci normal ca perpetueaza ce au invatat de la profesorii pre-Turing. Imi cer scuze de la profesorii care nu se incadreaza in categoriile de mai sus, nu vreau sa generalizez, dar sunt putin acid pentru ca sunt chiar scarbit in momentul de fata de sistemul de invatamant din Romania si nu pot decat sa fiu de acord cu postul vostru.
E aiurea. Sunt multe chestii aiurea. Va dau alt exemplu: software testing. Nu am facut absolut nimic in privinta asta la facultate. La fostul loc de munca am avut mai multi colegi care au terminat aceasi facultate pe care o termin si eu si considerau ca testing inseamna sa butonezi programul ore in sir pana se strica ceva. De unde white-box, black-box, smoke, unit, regression, security, accesibility s.a. testing? Din carti si de pe net ca de la facultate in niciun caz.
June 27th, 2008 - 03:02
am patit asta in liceu, unde ma distram cu matricile, sa pricep cand trebuie sa folosesc m, cand n, cui corespund i respectiv j, bla bla.
intr-o zi ora a fost tinuta de un elev mai mare (busy teacher), si ala a folosit o metoda absolut fenomenala de parcurgere a matricii:
for (l=1 ; l <= nl ; l++)
for (c=1 ; c <= nc ; c++){
do something;
}
scurt si clar.
l stands for linie, c for coloana, nl for numar-linii, nc for numar-coloane. si orice operatii faceam pe matricea aia, mi-o puteam imagina dupa numele variabilei. deh .. nu toti stiu sa predea.
din pacate Politehnica produce inca specialistii, si de acolo iesi cu mentalitate de ceasornicar, fara sa vrei. acu’, desigur, profesorii de informatica ar trebui sa predea doar info, fara influente. dar cand si manualele sunt scrise in modul asta, si alternativa nu e evident necesara, de ce ai face-o?
let them be, I guess. se curata singuri.
June 27th, 2008 - 10:40
Still vezi ca altgoritmica e matematica, si de la un nivel in sus e arida ca atare, x y z. Si nu spuneam ca depinde cita matematica e in un algoritm. Spuneam ca algoritmii pot fi tratati ca matematica cu x y si z si e ok pentru ca ii abordezi matematic. Daca ii abordezi industrial aplicat atunci da trebuie sa aiba totul la standardul industrial. Si vezi ca la un nivel iarasi, nu cred sa vezi in Romania, se valideaza matematic unele chestii, se modeleaza si se interpreteaza, repet cum crezi ca tu ca au fost siguri ca toate procesele din Windows o sa capete procesor? A fost o analiza matemica si algoritmica care a generat sau validat solutia inginereasca, dar repet e alt nivel de lucru.
July 7th, 2008 - 09:33
Problema ridicata de tine e.. ca sa zic asa un fapt bine cunoscut.
motivul pentru care nu se scrie “readable code” e datorat in principal mediilor Borland. Si prin asta intelegeti toti ce vreau sa zic.
Am o MULTIME de colegi care nu s-au prins ca pot da nume semnificative la variabile, si care inca nu ma inteleg de ce tot zic CTRL SPACE
January 13th, 2009 - 15:06
Obisnuinta de a nu da nume semnificative variabilelor vine si de la faptul ca la noi programarea inca se invata cu Turbo Pascal si Borland C++ 3.1 sub DOS. Chiar si la facultate, primele cursuri pe astea se bazeaza. Si in momentul cand nu ai IntelliSense, parca nu iti prea vine sa scrii de mana ‘indexLinie’ sau ‘sumaPartiala’ de fiecare data.
Unii inteleg limitarea tehnica, iar mai apoi cand trec pe IDE-uri ca lumea de Java sau .NET se dau pe brazda. Altii raman cu prostul obicei de a alege litere din alfabet pentru nume de variabile.
Dar ai dreptate, daca vrei sa lucrezi dupa best-practices tre’ sa fii autodidact pt ca multi profii n-au auzit de asa ceva.
January 24th, 2009 - 08:28
Am lecturat in ultima vreme manualele de informatica pentru liceu. In anul 2009 este predat in continuare limbajul “C/C++” (whatever that means) de acum 20 de ani.
Nu cred ca problema este legata de mediul de programare in mod text sau de editorul caruia ii lipseste AutoComplete.
Autorii nu inteleg C++. Ei transmit elevilor mentalitatea de a declara tablouri cu 100 de elemente, de a lucra cu variabile globale (sau cu un domeniu de vizibilitate mult prea cuprinzator), de a nu limita dependentele intre sectiuni de cod…
Elevii invata sa aplice algoritmii unor probleme de jucarie. Le lipsesc abilitatile de a crea programe mai complexe si module mai flexibile. Tehnicile deprinse nu scaleaza in rezolvarea problemelor industriale.
Este “amuzant” de remarcat faptul ca limbajul C++ modern simplifica scrierea programelor corecte si eficiente. Concepte mai interesante (si nu neaparat mai complicate) ar putea fi prezentate mai devreme in programa, facand orele mai atractive.
“[...] Why do I discuss efficiency in the context of programming style and teaching? The styles and techniques we teach must scale to real-world problems. C++ is – among other things – intended for large-scale systems and systems with efficiency constraints. Consequently, I consider it unacceptable to teach C++ in a way that leads people to use styles and techniques that are effective for toy programs only; that would lead people to failure and to abandon what was taught. [...]”
(http://www.research.att.com/~bs/new_learning.pdf)