Atunci când construiesc o aplicație și mai ales atunci când construiesc PRIMA aplicație, majoritatea începătorilor fac multe greșeli, din două motive: lipsa experienței și nepăsarea față de orice standarde și conduite stabilite, pe baza ideii „nu-mi pasă cum, dar functionează!”. Acest lucru, dacă este combinat și cu lipsa de îndrumare a unui mentor mai experimentat, poate dezvolta o mulțime de obiceiuri proaste în cariera viitorului programator, care sunt foarte greu de înlăturat și corectat, și de cele mai multe ori duc la codul oribil pe care îl vedeți pretutindeni pe internet. Nu voi da nume, dar există țări întregi unde acest lucru a devenit din păcate un fenomen, iar lumea ingineriei software suferă teribil din cauza acestei boli care răscolește din ce în ce mai multe generații de noi programatori.
Deoarece industria ne-a obișnuit să lansăm software-ul mai repede, tot mai repede, cu termene limită tot mai scurte, pentru a rămâne în fața concurenței și pentru a aduce mai multe venituri, programatorii novici cred că obiectivul principal al construirii unui program este acela de a-l termina cât mai repede posibil, iar acest impuls este întărit și de nerăbdarea de a pune împreună luni sau chiar ani de studiu teoretic într-un lucru care în cele din urmă face ceva concret.
Este rău când programatorii scriu cod prost pentru că nu au de unde să știe mai bine. Este și mai rău când știu acest lucru, dar nu le pasă. Ar trebui să fie un subiect foarte alarmant pentru voi dacă vă vedeți făcând vreunul din aceste lucruri:
- crezi că eficiența și performanța nu sunt importante, deoarece computerele sunt super-rapide în zilele noastre și se pot confrunta cu un cod ineficient. Gândești că obiectivul principal este acela de a vedea că funcționează, indiferent cum funcționează.
- crezi că vei repara lucrurile mai târziu. Nu numai că te vei încurca în curând în lucruri care semi-funcționează, dar cu cât vei avansa mai mult, cu atât codul-spaghete va deveni mai interconectat, mai încâlcit, și cu atât va fi mai greu să remediezi lucrurile fără a strica multe alte coduri, sau fără a re-scrie părți de cod.
- lipsa de planificare a lucrurilor. Scopul tău este scrierea directă a următorului joc Warcraft, nu ai nicio idee despre pașii necesari, dar sari direct în cod, crezând că vei înțelege ce și cum pe măsură ce avansezi.
- începi proiecte ce sunt o provocare mult prea grea. Știi că nu ai abilitățile teoretice necesare pentru a scrie astfel de lucruri, dar ești sigur că vei citi câteva articole minime atunci când este necesar și, chiar mai rău, vei folosi coduri care nu știi ce sunt și cum funcționează, însă continui să crezi că vei învăța ciugulind câte puțin de ‘ici, de ‘colo, în timp.
- devii copy – paste script kiddie. În cele mai multe cazuri, ești mai rău decât cei din secțiunea de mai sus. Nu știi nimic despre programare, nu îți pasa deloc despre învățarea lucrurilor teoretice, tot ce îți pasă este cod care „merge”, pentru a impresiona colegii de clasă. Ești expert în copierea codurilor găsite pe Google, rezultând în cele din urmă în fragmente de cod risipite, lipite jalnic într-o monstruozitate plină de petice peste petice, care reușește cumva să îndeplinească o sarcină.
- comentariile sunt pentru tine o pierdere de timp și spațiu. Tipul de programator care își amintește orice și nu are nevoie de memento-uri stupide prin tot codul. Ce importanță are dacă nimeni altcineva nu înțelege codul scris de tine sau pierde ore și ore descifrând ceva care ar fi luat 15 minute de citire a comentariilor? Mai târziu, te dai cu capul de pereți, când trec câteva luni și îți dai seama că ai uitat ce se presupune că ar trebui să însemne sau să efectueze codul respectiv.
- insiști asupra soluțiilor de o singură linie. Opusul programatorilor din primul paragraf. Crezi că performanța este singurul lucru important și încerci să strângi 30 de linii de cod într-o singură linie, care nu poate fi citită (deși este eficientă). De asemenea, denumești variabilele x și y, deoarece nu ai nevoie de nume stupide, lungi și descriptive, care mănâncă spațiu.
- ignori complet designul. La urma urmei, ești un programator, nu designer grafic. Arunci butoanele în fereastră cu o catapultă, și rămân acolo unde aterizează pentru restul vieții lor.
- ascunzi mizeria sub covor. Nu îți pasă cu adevărat de erori și excepții și nu faci niciodată vreun log al modului în care programul funcționează.
- re-inventezi roți iar și iar. La fel ca și copierea și lipirea codului de pe Google, evitarea cu totul a Google este o idee foarte proastă. Nu te lupta zile la rând încercând să faci ceva deja existent, și mult mai bine realizat, cel mai probabil. Mai multe creiere sunt aproape de fiecare dată mai bune decât un singur creier.
- ești prea arogant să înveți lucruri noi sau să recunoști că greșești. Codul tău este cel mai bun din lume și oricine altcineva greșește.
- nu ceri ajutor atunci când te blochezi. Există un motiv pentru care internetul roiește cu forumuri legate de programare, unde oamenii solicită ajutor.
- ceri mereu ajutor, chiar și atunci când nu ești blocat. Nu îți permiți să risipești timp prețios, de ce să nu ceri altora să scrie codul pentru tine?
- niciodată nu indentezi sau formatezi codul, sau folosești formate enervante, ciudate, pe care nimeni nu le folosește.
- programele tale reprezintă o singură funcție uriașă. Programul începe și se termină în metoda Main() și nu ai auzit niciodată de modularizarea codului.
- codul tău reprezintă resturile spulberate ale unei explozii nucleare. Îți împarți codurile în piese infinite și mici.
- hardcoding chestii în cod. Niciodată nu te gândești la portabilitate sau versatilitate și niciodată nu-ți pasă de codul flexibil.
Știu că sună ridicol, dar modul corect de codare poate părea la început o glumă proastă. Mulți programatori citesc „regulile” pentru scrierea de coduri corecte și râd, gândindu-se: „ce pierdere de timp!”, fără să-și dea seama de cine râde la urmă. Din nefericire, își dau seama odată cu experiența, în ani de nenumărate ore și zile risipite, care ar fi putut fi salvate, dacă n-ar fi râs și ar fi încercat aceste sfaturi.
Deci, ce presupune construirea unei aplicații în mod corect? În primul rând, citiți nenorocita de teorie! Nu săriți la a scrie rețele neurale artificiale când doar ce ați terminat programul „Bună Lume!”. Acordați-vă timp pentru a citi temele necesare pentru a învăța principiile fundamentale ale programării. Chinuiți-vă să scrieți programe aparent stupide, mici, scrise pentru fiecare lecție. Sunt acolo cu un scop, pentru a vă familiariza cu conceptele explicate, pentru a vă obișnui să scrieți coduri, pentru a vă oferi o experiență de început în programare. Este cunoscut faptul că doar cititul nu este suficient pentru a deveni un programator, așa cum doar practica nu este suficientă fără teorie. Nu o luați pe scurtături, nu săriți peste capitole care la prima vedere par „neinteresante”. Am spus deja de mai multe ori: nu există nicio soluție miraculoasă, nu există niciun truc magic de genul „învăță programare în 30 de zile”. Este nevoie de luni sau de ani de luptă cu adevărat grea pentru a stăpâni părțile fundamentale ale acestui job. Există un motiv pentru care postul se numește INGINER software. În caz contrar, toată lumea ar fi programatori.
Când sunteți încrezători în principiile fundamentale ale programării, atunci și doar atunci puteți începe să vă gândiți la scrierea primului program serios, complex și bogat în opțiuni. Iar următorul pas este PLANIFICAREA! Nu săriți direct la tastatură, scriind cât mai multe coduri din prima zi. Nu fiți cei care cred că abilitățile și erorile pot fi adăugate sau corectate din zbor. Luați un creion și hârtie și începeți să vă gândiți cu adevărat la ceea ce doriți să faceți. Care sunt principalele caracteristici ale programului vostru? Cum ar trebui să funcționeze? Care ar fi cea mai bună soluție pentru implementarea acestora? Ce erori ar putea fi întâlnite? Cum puteți îmbunătăți securitatea? Ce module de cod ar trebui să aibă? Cum sunt conectate și cum interacționează între ele? Ce și cum trebuie să faceți pentru a face codul flexibil, ușor de întreținut, extins, îmbunătățit, reutilizat? Ce structuri de date vor fi cele mai potrivite pentru nevoile voastre? Cum va arăta GUI-ul vostru? Amintiți-vă, oamenii sunt în mare parte creaturi vizuale! Aplicația voastră va suferi foarte mult dacă are un stil vizual oribil, chiar dacă performanțele sunt remarcabile. Câte jocuri super performante, dar cu o grafică oribilă, ați jucat..? Așa că, gândiți-vă! Care este stilul vizual al programului vostru? Cum ar trebui interfața grafică să țină seama de responsivitate (redimensionarea și rearanjarea componentelor interfeței utilizator pe diferite dimensiuni și rezoluții ale ecranului, pentru a profita de spațiul disponibil pe ecran în cel mai bun mod posibil)? Care este fluxul interfeței grafice din aplicație? Cum interacționează diferitele locuri din interfața de utilizator și cum vor folosi utilizatorii interfața grafică de la început până la sfârșit? Gândiți-vă la toate scenariile posibile – dacă, de exemplu, aplicația voastră cere utilizatorilor să se autentifice, ce se întâmplă dacă utilizatorul uită parola? Cum creează utilizatorii conturi noi? Ce se întâmplă când se autentifică? Si așa mai departe.
Dacă programul vostru utilizează o bază de date, ce date trebuie să stocați? În ce categorii distincte pot fi grupate datele voastre? Cum interacționează aceste categorii între ele? Proiectați o diagramă ERM (Entity-Relationship Model) pentru a marca relația dintre date.
În același timp, nu complicați prea mult lucrurile. Nu intrați în detalii minuțioase. Nu adăugați funcții de care nu aveți nevoie. Uitați-vă la planurile voastre după ce le scrieți. Este o listă uriașă? Aveți caracteristici care nu sunt atât de importante pentru funcționalitatea de bază? Chiar aveți nevoie de autentificare Facebook pentru programul vostru? Este cu adevărat nevoie să încărcați datele într-un serviciu bazat pe cloud? Nicio aplicație nu este completă. Vor fi mereu caracteristici noi care vor fi adăugate, îndepărtate, înlocuite, reparate, etc. Începeți prin proiectarea doar a funcționalității foarte importante, de bază. Caracteristici suplimentare vor veni în viitor, când funcționalitatea principală va fi gata. Dacă chiar doriți să planificați aceste lucruri, faceți o listă separată a funcțiilor „de făcut”, care ar putea fi adăugate în viitor, atunci când totul este gata.
Din păcate, cei mai mulți programatori de nivel junior și mediu ignoră acești pași cu totul. Chiar și mai trist, doar câteva universități se deranjează să predea acești pași. Cu toate acestea, nu pot să subliniez îndeajuns cât de important este un plan bine structurat, când petreceți câteva ore planificând înainte de a începe munca efectivă, pentru a avea sentimentul de încredere de a ști ce și cum doriți să faceți pentru tot restul activității de dezvoltare.
Când planificați aplicația, nu planificați un program de tip all-in-one. Nu faceți asta, chiar dacă sentimentul de a face acest lucru este puternic! Este versiunea 1 a programului vostru, la urma urmei. Ideea este să vă distrați în timp ce învățați lucruri noi, nu să construiți următorul Facebook, de la zero.
Următoarea etapă după finalizarea planificării ar trebuie să fie….? Scrierea codului? Nu! Gresit din nou! Știu că deveniți nerăbdători, dar acest pas este la fel de important ca și planificarea. Faceți niște cercetări! Documentați-vă pe Google până când vă rupeți degetele în tastatură! Vedeți dacă altcineva a făcut deja lucrurile pe care urmează să le creați. Încercați să citiți și să înțelegeți aceste coduri, să documentați ce probleme și erori au întâmpinat dezvoltatorii lor și cum le-au rezolvat. Comparați mai multe surse, încercați să faceți o listă de „pentru” și „contra” pentru fiecare soluție, cereți sfaturi. Nu confundați această etapă cu a face o listă de link-uri web de unde puteți copia bucăți de cod pentru programul vostru! Adevărat, am spus că re-inventarea roților nu este un lucru bun de făcut în programare și nu ar trebui să scrieți coduri care au fost deja scrise de alții (și probabil mai bine decât ați face-o voi, ca începători), dar acest lucru este valabil doar pentru programatorii experimentați sau pentru cei cel puțin confortabili în programare. Dacă nu înțelegeți ce face codul pe care îl copiați, nu ar trebui să îl utilizați în primul rând. Da, scopul de a face lucrurile să funcționeze este important, dar la fel de important este și scopul de a învăța ceva din experiență, de a câștiga cunoștințe și experiență practică. Dacă aveți nevoie de un cod care citește și scrie într-un fișier text, dar nu aveți nicio idee despre cum se face acest lucru, poate că ar fi o idee mai bună să cercetați și să vă documentați și să vă construiți un modul propriu care face acest lucru, chiar dacă există tone de soluții deja disponibile pe web. S-ar putea să pierdeți câteva ore, dar veți obține cunoștințe și experiență care vă vor dezvolta partea de programare a creierului, fără a mai menționa că probabil veți fi pregătiți data viitoare când veți avea nevoie de acest tip de funcționalitate, din nou. Cel mai important, veți dezvolta abilitățile de căutare și de filtrare rapidă, de a găsi lucruri specifice legate de problemele viitoare.
În cele din urmă, timpul să începem codarea!
Partea cea mai surprinzătoare pentru programatorii începători ajunși în acest stadiu este că vor observa ușurința în scrierea codului. Aproape că vine în mod natural, chiar dacă nu au scris vreodată o astfel de aplicație. Adevărat, există încă lucruri pe care nu le puteți cunoaște sau anticipa, însă scopul etapelor anterioare a fost atins: știți ce faceți, și faceți în mod corect. Totuși, în acest stadiu, există câteva lucruri asupra cărora trebuie să fiți atenți:
- nu începeți să construiți mai multe module ale aplicației voastre în același timp. Dacă aplicația are o interfață de autentificare afișată mai întâi, scrieți funcția de autentificare până când aceasta este terminată. Nu treceți la fereastra principală, afișată după autentificare, sau fereastra care permite utilizatorilor să personalizeze opțiuni! Acest lucru nu numai că vă va face să rămâneți concentrat pe o singură sarcină la un moment dat, dar vă va ajuta de asemenea să proiectați un cod modular care este autosuficient, decuplat de alte secțiuni și ușor de schimbat. Scrieți-vă programul câte o singură funcție la un moment dat.
- utilizați tone de unități de test. Încercați să vă stricați funcționalitatea propriul program în orice mod imaginabil. Credeți-mă, există o abilitate neîncetată a utilizatorilor programului vostru de a găsi modalități noi și mai inteligente de a vă utiliza programele în moduri în care nu au fost concepute să lucreze. Încercați să testați și să anticipați orice rezultat. Programatorii experimentați numesc aceasta Test-Driven Development (TDD).
- utilizați Git! Știu că nu v-am învățat despre versionare și controlul sursei încă, dar nu există nimic mai rău decât să lucrați zile și săptămâni la programul vostru și să-l pierdeți deoarece ați șters accidental dosarul, fișierul de proiect a fost corupt sau Windows-ul nu mai pornește. Dacă nu știți ce este Git și nu aveți timp să-l învățați (deși vă recomand din inimă să faceți acest lucru, există tone de tutoriale pe YouTube), cel puțin faceți arhive de backup constante programului vostru, astfel încât să puteți reveni la ele în cazul în care se întâmplă ceva catastrofal. Am învățat personal acest lucru pe calea cea grea, pierzând O MULȚIME de lucruri, și credeți-mă, nu doriți să experimentați sentimentul!
- cand vă blocați, nu săriți direct pe forum-uri, cerând ajutor. Încercați diferite modalități de a rezolva sarcina. Căutați pe Google despre subiect. Când vă duceți pe un forum pentru a cere ajutor, ar trebui să fiți pregătiți să arătați ce ați încercat deja. Nu există niciun lucru pe care programatorii să îl disprețuiască mai mult decât lenea și lipsa dorinței de a vă rezolva propriile probleme. Dacă faceți asta, nu vă simțiți ofensați dacă vor începe să vă răspundă ironic și să vă spună verde în ochi că nu sunt mașini de scris teme pentru acasă.
- În cele din urmă, chiar și atunci când rămâneți blocați, sau aveți erori, sau programul nu funcționează așa cum doriți, nu vă descurajați! Nu fiți frustrați, gata să aruncați calculatorul pe fereastră. Poate că este o idee bună să vă ridicați de la computer. Poate ar fi mai bine să trageți un pui de somn bun și să lăsați problema pentru ziua următoare, când creierul vostru este odihnit.
În următoarea lecție, vom începe cu prima fază de scriere a primului nostru program mai complex, planificarea. Rămâneţi aproape!
Tags: practici de evitat în programare, practici recomandate in programare, scrierea primului program
