Algoritmul unei funcționalități noi

La ora de română, fiecare prezentare de proiect are exact trei minute. Teoretic. Practic, mereu cineva depășește, doamna profesoară se uită la ceas, colegii foșnesc, iar ultimul din listă rămâne pe săptămâna viitoare. La finalul orei, diriginta s-a întors spre voi: „Voi nu faceți informatică? Faceți-ne un cronometru care să dea singur semnalul." Aceasta este o comandă — și exact așa arată începutul oricărui program adevărat: cineva vrea o funcționalitate nouă, iar tu trebuie să o transformi în algoritm.

La finalul lecției vei ști să extragi datele de intrare și de ieșire dintr-o cerință spusă în cuvinte, să concepi algoritmul în pași mici și să îl implementezi pe blocuri, verificându-l cu teste alese cu cap.

De la dorință la cerință clară

„Un cronometru care dă singur semnalul" sună clar, dar nu este. Înainte să atingi calculatorul, pui întrebări — la fel cum face orice programator când primește o comandă:

• Cât durează o prezentare? Trei minute, adică 180 de secunde.
• Vreți doar semnal la final, sau și un avertisment înainte? Un avertisment cu 30 de secunde înainte, ca elevul să poată încheia frumos.
• Cum dăm semnalul? Un sunet scurt la avertisment, un mesaj mare pe ecran la final.

Din trei întrebări, dorința vagă a devenit o specificație: un cronometru care numără invers de la 180 de secunde, redă un sunet când mai sunt 30 și afișează „Timpul a expirat!" când ajunge la 0. Abia acum poți lucra.

Datele: ce intră, ce iese, ce ține minte programul

Orice program se poate desena ca o cutie: pe o parte intră date, înăuntru se întâmplă prelucrarea, pe cealaltă parte ies rezultate.

Pentru cronometrul nostru, tabelul datelor arată așa:

Rol	Data	De unde vine
intrare	durata prezentării (180 s)	stabilită de profesoară
intrare	pragul de avertizare (30 s)	stabilit de profesoară
internă	timpul rămas	o variabilă pe care programul o scade singur
ieșire	sunetul de avertizare	redat când timpul rămas atinge pragul
ieșire	mesajul „Timpul a expirat!"	afișat când timpul rămas ajunge la 0

Observă distincția: „timpul rămas" nu este dată de intrare, chiar dacă la început e egal cu durata. Durata o primești; timpul rămas îl calculezi, secundă de secundă. Confuzia dintre cele două e sursa multor algoritmi încurcați.

Algoritmul, în pași mici

Cu datele limpezi, algoritmul aproape se scrie singur. Îl notăm în pseudocod — pași numerotați, în românește, fără nicio grijă de sintaxă:

1. primește durata (180) și pragul (30)
2. timp_rămas ← durata
3. cât timp timp_rămas > 0, repetă:
     3a. așteaptă o secundă
     3b. timp_rămas ← timp_rămas - 1
     3c. dacă timp_rămas = prag, redă sunetul de avertizare
4. afișează „Timpul a expirat!"

Fiecare pas face un singur lucru. Pasul 3 este o structură repetitivă cu condiție: nu știi dinainte de câte ori se execută în orice situație, știi doar când se oprește. Pasul 3c este o decizie cuibărită înăuntrul repetării — verificată la fiecare secundă, adevărată o singură dată.

Implementarea pe blocuri

A doua oră începe la calculator. Deschide Scratch, creează două variabile — timp_rămas și prag — și tradu algoritmul bloc cu bloc. Traducerea e aproape mecanică, pentru că fiecare pas din pseudocod are un bloc corespondent:

Bifează corespondența pe caiet: pasul 2 a devenit blocul „setează", pasul 3 a devenit „repetă până când", decizia 3c a devenit blocul „dacă". Când implementarea urmează algoritmul pas cu pas, orice eroare se găsește ușor: compari lista de blocuri cu lista de pași și vezi imediat unde s-au despărțit drumurile.

Un detaliu de prezentare: bifează căsuța variabilei timp_rămas în lista de variabile, ca valoarea ei să se vadă pe scenă. Colegul care prezintă trebuie să vadă cât mai are — altfel cronometrul e util doar pentru profesoară.

Testarea: cazuri, nu impresii

Programul „pare că merge" nu înseamnă nimic. Testarea serioasă înseamnă cazuri alese dinainte, cu rezultat așteptat scris înainte de rulare:

Cazul de test	Valori	Ce aștept	A trecut?
durată scurtă	durata 5, prag 2	sunet la 2, mesaj după 5 s
valoarea-limită	durata 30, prag 30	sunetul chiar la start?
pragul mai mare ca durata	durata 10, prag 30	fără sunet, doar mesaj

Atenție aici — e greșeala pe care o văd cel mai des: testezi o singură dată, cu valorile „frumoase" din cerință, și declari victoria. Erorile stau la margini: la valori egale, la zero, la cazul „nu se poate". Al doilea rând din tabel e exact un astfel de test: dacă pragul e egal cu durata, sunetul se redă la prima scădere — e ceea ce vrem, sau ar trebui tratat special? Nu există răspuns unic; există doar decizia ta, luată conștient și notată.

Nimeni nu testează cu 180 de secunde reale de fiecare dată — ai pierde trei minute pe rulare. Micșorezi durata la 5, verifici logica, apoi pui valoarea adevărată la final. Testul rapid pe valori mici, verificarea finală pe valori reale: așa lucrează și echipele profesioniste.

Exersează

1. Modifică cronometrul astfel încât pragul de avertizare să fie 60 de secunde, nu 30. Câte blocuri ai schimbat? Dacă răspunsul e „mai mult de unul", variabila prag nu e folosită peste tot unde ar trebui.
2. Adaugă o a doua avertizare: la 10 secunde rămase, personajul își schimbă costumul sau culoarea. Scrie întâi pasul nou în pseudocod, abia apoi adaugă blocurile.
3. Scrie pe caiet tabelul de date (intrare, interne, ieșire) pentru o altă funcționalitate cerută de clasă: un program care alege prin tragere la sorți ordinea prezentărilor. Nu-l implementa — doar datele și algoritmul în pași.
4. Provocare. Adaugă cronometrului un buton de pauză: la apăsarea tastei „p", numărătoarea îngheață; la a doua apăsare, continuă. Indiciu: îți trebuie o variabilă nouă care ține minte starea, cu două valori posibile.

Cronometrul e gata și își face treaba. Dar comenzile nu se opresc niciodată la prima versiune — clasa va cere pauză, praguri colorate, sunete diferite, iar scriptul tău va crește. Săptămâna viitoare înveți cum să-l împarți în bucăți cu nume, ca să nu se transforme într-un ghem imposibil de descâlcit.