Cum construiești un algoritm simplu, pas cu pas

Majoritatea elevilor care se blochează la o problemă de programare nu se blochează la sintaxă. Se blochează pentru că sar direct la cod, fără să înțeleagă cu adevărat problema — și scriu instrucțiuni fără să știe exact de ce le scriu. Rezultatul: cod care „cam merge”, dar pe care nu-l pot explica și nu-l pot repara când dă greș.

Un algoritm bun nu începe cu un editor de cod deschis. Începe cu hârtie și un creion, sau, în lipsa lor, cu răbdarea de a gândi problema în cuvinte, înainte de orice sintaxă. Iată exact pașii prin care treci de la o cerință confuză la un program funcțional.

Pasul 1: Înțelege ce ți se cere, nu ce crezi că ți se cere

Citește cerința de două ori și răspunde clar la trei întrebări: ce primești (datele de intrare), ce trebuie să afișezi (datele de ieșire) și ce transformare trebuie făcută ca să ajungi de la una la alta. Sună banal, dar cele mai multe greșeli la exerciții pornesc din citirea grăbită a enunțului — un elev vede „cifre” și presupune că se referă la toate numerele, când de fapt problema cere doar un anumit tip.

Pasul 2: Descompune problema în cuvinte, nu în cod

Înainte să scrii orice linie de C++ sau Python, scrie în limbaj natural ce ai face tu, manual, cu creionul, dacă ai rezolva problema pe hârtie. De exemplu, pentru o problemă care cere verificarea unei proprietăți a cifrelor unui număr, pașii ar putea fi:

1. Iau numărul și îi scot cifrele, una câte una.
2. Le prelucrez pe fiecare, după regula cerută.
3. Verific dacă rezultatul se potrivește cu ce caut.
4. Afișez concluzia.

Testul dacă ai înțeles cu adevărat problema: poți explica soluția unui prieten, fără să folosești deloc cod? Dacă da, ești pregătit pentru pasul următor. Dacă te încurci în explicație, problema nu e încă limpede — și niciun cod scris în graba asta nu va fi limpede nici el.

Pasul 3: Găsește ce se repetă — acolo pui o buclă

Orice pas din descrierea ta care sună a „pentru fiecare…” sau „cât timp mai am…” se traduce direct într-o structură repetitivă (for sau while). Dacă în descrierea în cuvinte ai scris „iau cifrele una câte una, până nu mai am”, asta e semnul clar că ai nevoie de o buclă care rulează cât timp numărul e mai mare decât zero.

Pasul 4: Găsește unde alegi între variante — acolo pui un if

Orice moment în care descrierea ta spune „dacă… atunci…” devine o structură condițională. Elevii confundă des acest pas cu pasul anterior — o buclă repetă, un if alege. O problemă bine descompusă are, de obicei, ambele: o buclă care parcurge datele, și un if în interiorul ei care decide ce se întâmplă cu fiecare element parcurs.

Pasul 5: Alege variabilele de manevră

Pe lângă datele de intrare și ieșire, aproape orice algoritm are nevoie de „variabile de manevră” — locuri unde ții rezultate intermediare cât timp lucrezi. O sumă care se acumulează, un contor, o copie a datelor originale ca să nu le strici în timp ce le prelucrezi. Elevii care sar peste acest pas ajung să scrie cod care modifică variabila originală și pierd datele de care mai au nevoie mai târziu în program.

Pasul 6: Scrie pseudocodul înainte de codul propriu-zis

Pseudocodul e puntea dintre „am înțeles problema” și „am scris programul”. Nu are reguli stricte de sintaxă — scrii pașii algoritmului în românește structurată, cu bucle și condiții marcate clar, fără să te gândești încă la punct și virgulă sau la acolade. Abia după ce pseudocodul curge logic, îl traduci linie cu linie în limbajul de programare ales. Acest pas pare o pierdere de timp pentru mulți elevi grăbiți, dar economisește exact timpul pe care l-ai fi pierdut depanând cod scris direct, fără plan.

Pasul 7: Testează pe cazuri limită, nu doar pe exemplul din enunț

Un algoritm care funcționează pe exemplul dat în cerință nu înseamnă un algoritm corect — înseamnă doar că funcționează pe acel exemplu. Testează separat: cazul cel mai mic posibil (ce se întâmplă cu cea mai mică valoare permisă?), cazul cel mai mare (nu depășești capacitatea tipului de date folosit?), și cazurile „ciudate” — de exemplu, ce se întâmplă dacă răspunsul așteptat e „nu există nicio soluție”? Multe soluții care par corecte pică exact la aceste cazuri, pentru că elevul a gândit problema doar pentru varianta „normală”.

De ce contează asta mai mult decât memorarea sintaxei

Un elev care știe pe de rost sintaxa unui for sau a unui if, dar nu are exercițiul descompunerii unei probleme, se blochează în fața oricărei cerințe puțin diferită de ce a mai văzut. În schimb, un elev care a exersat acești șapte pași, indiferent de limbaj, poate ataca o problemă nouă cu încredere — pentru că știe cum se gândește o soluție, nu doar ce cuvinte cheie trebuie folosite.

Concluzie

Un algoritm simplu nu e simplu pentru că problema e ușoară, ci pentru că a fost descompus corect, pas cu pas, înainte de a fi scris în cod. Regula practică: dacă poți explica soluția în cuvinte, în mai puțin de cinci propoziții, algoritmul e suficient de limpede pentru a fi scris. Dacă nu poți, nu e o problemă de sintaxă — e semn că mai ai nevoie de un pas de descompunere.

La LAN Academy lucrăm cu elevii exact pe acest tip de gândire structurată — de la înțelegerea cerinței, până la pseudocod și cod funcțional — pentru pregătirea la olimpiadele de informatică și pentru cursurile de programare. Vezi cursurile noastre.