Indicații pentru teme
- Ultima modificare: 10 noiembrie 2024
Temele urmăresc exersarea cunoștințelor și abilităților voastre.
Așadar, urmărim nu doar cod care “merge”. Rezolvările voastre trebuie să nu fie predispuse la erori și să poată fi citite/parcurse/înțelese cu ușurință.
De asemenea, urmărim aplicarea principiilor orientate pe obiect. Acesta este unul dintre scopurile materiei și depășește limbajul de programare cu care lucrăm. Șansele sunt ca majoritatea codului pe care îl veți scrie ca software engineers să fie orientat-obiect. Vom urmări cu strictețe respectarea acestor principii în temele voastre.
Do's
- Alocați suficient timp temelor. E improbabil ca o rezolvare într-un all-night coding sprint să fie de calitate.
- Nu scrieți codul din prima, ci alocați timp abordării și design-ului.
- Fiți consecvenți unui coding style.
- Când scrieți README-ul pentru teme:
- Încercați să creați README-uri care să reflecte structura internă a proiectelor voastre (ierarhii de clase, ierarhii de pachete), dar și interacțiunea dintre entități mai ales când descrieți cum ați reușit să rezolvați o cerință din temă.
- Nu reproduceți cerințele din enunț și/sau comentariile din cod.
- Exprimați-vă concentrat = clar și concis.
- Este de apreciat să ne descrieți chiar și problemele pe care le-ați avut și cum ați ajuns la soluțiile actuale.
- Dacă folosiți structuri de date/algoritmi avansați, design pattern-uri sau chiar mecanisme mai avansate Java, este bine să menționați aceste lucruri în README, deoarece în unele etape acestea pot fi considerate puncte bonus.
- Apreciem foarte mult feedback-ul vostru, deci puteți lăsa la final un feedback constructiv care va fi folosit pentru ajustarea temelor viitoare.
- Lungimea README-ului nu trebuie să fie copleșitoare, vă recomandăm să vă incadrați în maxim 100 de rânduri, câte 80 de caractere pe linie.
- Comentariile din cod:
- Puneți comentarii în cod semnificative deasupra semnăturii metodelor folosind JavaDoc.
- Comentariile trebuie sa fie concise și să descrie funcționalitatea de bază a metodei.
- Puteți scrie comentarii și în corpul metodelor dacă aveți un flux mai complicat de instrucțiuni, dar codul vostru Java ar trebui să fie destul de ușor de înțeles dacă vă folosiți de funcționalități POO.
- Despre organizarea codului:
- Organizați codul cât mai bine în pachete și clase.
- Clasele ar trebui să fie scurte și să conțină metode foarte bine modularizate.
- Un proiect bun sau chiar enterprise conține sute de clase, tocmai pentru a decupla cât mai bine funcționalitățile aplicației.
- Despre feature-uri:
- Încercați să folosiți cunoștințe avansate din lab pentru a rezolva cerința temei, deoarece acestea vă pot învăța sa creați un cod mai sigur prin mecanisme de error handling sau sincronizare sau chiar un binar mai mic și mai ușor de înțeles prin folosirea unei sintaxe mai scurte.
- Folosiți feature-uri noi Java dacă vă ajută.
- Folosiți Git pentru a vă versiona proiectul. Trebuie să aveți minim 3 commit-uri sugestive.
- Soluția voastră trebuie să folosească cât mai mult concepte POO învățate la laborator.
- Folosiți cu încredere forumurile pentru orice: neclarități, coding style, best practices, etc.
- Folosiți principiile Object Oriented:
- Păstrați încapsularea
- Folosiți polimorfismul
- Abstractizați și programați "by contract"
- Respectați principiile SOLID, DRY și KISS.
Disclaimer: șansele sunt ca temele să fie mai dificile decât laboratoarele.
Pentru rezolvarea lor, deși nu vă cerem tehnici sau cunoștințe în plus față de laboratoare, va fi probabil nevoie de mai multa documentare individuală.
Vă stăm la dispoziție pe forumuri, teams sau pe email pentru a vă răspunde la întrebări.
Don'ts
- Evitați folosirea keyword-ului instance of, acesta nu respectă principiile POO, singura excepție fiind în folosirea lui pentru generarea metodei “equals”.
- Codul înghesuit și nespațiat este greu de înțeles, apelați la IntelliJ pentru a vă formata automat proiectul.
- Nu folosiți nume nesugestive pentru variabile, clase și metode. Clasele descriu containere sau entități, variabilele reprezintă în general substantive, iar metodele încep adesea cu un verb.
- Nu folosiți snake_case pentru denumirea claselor, variabilelor și a metodelor. Pachetele pot fi denumite urmând sintaxa camelCase, dar și sintaxa snake_case.
- Nu creați toate clasele într-un singur pachet. Folosiți cât mai multe pachete pentru a grupa logic codul, puteți crea chiar pachete în pachete.
- Nu denumiți constantele necorespunzător. Folosiți litere mari și delimitatorul “_”.
- Nu lăsați cod comentat în proiect.
- Nu includeți fișiere care nu sunt relevante în arhiva proiectului.
- Nu hardcodați testele.
- Evitați programarea în stil C (imperative programming).
- Evitați să includeți cod inutil sau cod care îngreunează execuția programului.
Despre forum:
- Pentru clarificări vă recomandăm să folosiți forum-ul aferent temei, urmând ca întrebarea voastră să primească un răspuns cât de curând (să țineți cont că în weekend se poate răspunde cu o întârziere mai mare).
- Evitați întrebările foarte specifice care oferă hint-uri la soluționarea temei.
- De asemenea, verificați forumul periodic pentru update-uri și pentru întrebări ca să nu se creeze intrebări duplicate.
Despre programarea în stil C:
- Folosiți cât mai multe concepte POO (moștenire, polimorfism, upcast, overloading, overriding etc.)
- Gândiți temele ca entități care interacționează cu alte entități pentru a programa în stilul POO.
- Unele funcționalități pot fi doar niște metode, dar pot apărea următoarele probleme:
- Să spunem că aveți de implementat o funcționalitate care printează eating, speaking, playing într-un mod special pentru fiecare tip de animal care vă este oferit la input.
- Acestea pot fi reprezentate direct ca metode specifice pe care le puteți apela în cadrul unui switch-case.
- Ce faceți dacă trebuie să mai introduceți câteva animale? Ar trebui să creați noi metode în clasa voastră unde procesați logica ceea ce ar face fișierul greu de citit.
- Ce faceți dacă trebuie să adăugați funcționalități noi pentru fiecare tip de animal? Din nou, adăugăm foarte multe metode, ceea ce ar reduce lizibilitatea codului.
- De asemenea, puteți să aveți foarte mult cod duplicat care ar fi putut fi encapsulat într-o clasă Animal care ar fi putut fi moștenită de clasele voastre specializate (ex. Wolf, Dog, Cat etc.).
- Totodată dacă nu aplicați corect conceptele POO este posibil să ajungeți la situații în care apelați instance of ca să verificați ce clase trebuie să apelați ceea ce vă reduce codul la o formă de cod scrisă în C (soluția ar fi să folosiți upcasting și o metodă generică suprascrisă conform laboratului în care vi se prezintă upcast/downcast, moștenire, overloading, overriding).
- Dacă analizați situațiile de mai sus vă puteți da seama că limbajele de tip POO vă reduc drastic din cod și vă oferă extensibilitate pe viitor, adică orice programator vă poate extinde codul mult mai ușor dacă va fi nevoie de feature-uri noi în proiect.
Depunctări generale pentru teme
Temele pe care le primim trebuie să compileze și să ruleze pentru a avea posibilitatea de punctaj non-zero.
Vom aplica depunctări legate de calitatea codului și a abordărilor temelor. Din 10 puncte:
- Lista nu este exhaustivă. Evaluatorii pot aplica depunctări mai mari decât cele prezentate aici, în funcție de numărul de apariții ale greșelilor sau de gravitatea lor.
- Pentru abateri minore (de exemplu un nume de metodă folosit neadecvat, in toată tema), se vor pune doar observații cu -0.0.
- Dacă aveți întrebări legate de barem puteți să ne contactați pe forum/mail sau Teams.
