Differences
This shows you the differences between two versions of the page.
|
poo-ca-cd:administrativ:barem_teme [2020/08/15 16:12] florin.mihalache |
poo-ca-cd:administrativ:barem_teme [2024/11/10 17:58] (current) florian_luis.micu [Don'ts] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Indicații pentru teme ===== | ===== Indicații pentru teme ===== | ||
| + | |||
| + | * Autori: [[miculuis1@gmail.com | Florian-Luis Micu]], [[sorinabuf@gmail.com | Sorina-Anamaria Buf]], [[stefancocioran@gmail.com | Ștefan Cocioran]] | ||
| + | * Ultima modificare: 10 noiembrie 2024 | ||
| Temele urmăresc exersarea cunoștințelor și abilităților voastre. | Temele urmăresc exersarea cunoștințelor și abilităților voastre. | ||
| Line 5: | Line 8: | ||
| 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ță. | 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 OO. 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. | + | 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. |
| - | ==== Recomandări ==== | + | ==== Do's ==== |
| * Alocați suficient timp temelor. E improbabil ca o rezolvare într-un all-night coding sprint să fie de calitate. | * Alocați suficient timp temelor. E improbabil ca o rezolvare într-un all-night coding sprint să fie de calitate. | ||
| Line 13: | Line 16: | ||
| * Fiți consecvenți unui [[:poo-ca-cd:administrativ:coding_style_ide|coding style]]. | * Fiți consecvenți unui [[:poo-ca-cd:administrativ:coding_style_ide|coding style]]. | ||
| * Când scrieți README-ul pentru teme: | * Când scrieți README-ul pentru teme: | ||
| - | * nu reproduceți cerințele din enunț și/sau comentariile din cod | + | * Î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ă. |
| - | * explicați ideile, deciziile și abordările voastre | + | * Nu reproduceți cerințele din enunț și/sau comentariile din cod. |
| - | * exprimați-vă //concentrat// = clar și concis | + | * Exprimați-vă concentrat = clar și concis. |
| - | * formatați-l corespunzător - linii de 80 de caractere max, paragrafe, etc | + | * 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 cu încredere forumurile pentru orice: neclarități, coding style, best practices, etc. | ||
| * Folosiți principiile //Object Oriented//: | * Folosiți principiile //Object Oriented//: | ||
| - | * păstrați încapsularea | + | * Păstrați încapsularea |
| - | * folosiți polimorfismul | + | * Folosiți polimorfismul |
| - | * abstractizați și programați [[http://www.javapractices.com/topic/TopicAction.do?Id=194|"by contract"]] | + | * Abstractizați și programați [[http://www.javapractices.com/topic/TopicAction.do?Id=194|"by contract"]] |
| + | * Respectați principiile [[https://medium.com/@hlfdev/kiss-dry-solid-yagni-a-simple-guide-to-some-principles-of-software-engineering-and-clean-code-05e60233c79f|SOLID, DRY și KISS]]. | ||
| <note important> | <note important> | ||
| Disclaimer: șansele sunt ca temele să fie mai dificile decât laboratoarele. | Disclaimer: șansele sunt ca temele să fie mai dificile decât laboratoarele. | ||
| Line 27: | Line 48: | ||
| 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ă. | 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 sau la email-urile de pe pagina principală. | + | Vă stăm la dispoziție pe forumuri, teams sau pe email pentru a vă răspunde la întrebări. |
| </note> | </note> | ||
| - | ==== Depunctări generale pentru teme ==== | + | ==== Don'ts ==== |
| - | Temele pe care le primim **trebuie să compileze și să ruleze** pentru a avea posibilitatea de punctaj non-zero. | + | * 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. | ||
| - | Vom aplica mici depunctări legate de calitatea codului și a abordărilor temelor. Din 10 puncte: | + | <note tip> |
| + | 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. | ||
| + | </note> | ||
| - | **Coding style si organizare:** | + | <note warning> |
| - | * -0.1 - cod înghesuit sau prea spațiat | + | Despre programarea în stil C: |
| - | * -0.2 - warning-uri de compilare | + | * Folosiți cât mai multe concepte POO (moștenire, polimorfism, upcast, overloading, overriding etc.) |
| - | * verificați import-urile, variabilele nefolosite, etc | + | * Gândiți temele ca entități care interacționează cu alte entități pentru a programa în stilul POO. |
| - | * între -0.1 și -0.4 - nepăstrarea consistenței pentru comentarii - fie sunt toate comentariile în engleză fie sunt toate în română. | + | * Unele funcționalități pot fi doar niște metode, dar pot apărea următoarele probleme: |
| - | * între -0.1 și -0.4 - nepăstrarea consistenței pentru denumiri - fie sunt toate n engleză fie în română. Puteți avea însă denumirile și comentariile în limbi diferite. | + | * 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. |
| - | * între -0.1 și -0.3 - denumiri nepotrivite pentru metode, variabile, clase | + | * Acestea pot fi reprezentate direct ca metode specifice pe care le puteți apela în cadrul unui switch-case. |
| - | * -0.1 - bucăți de cod comentat | + | * 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. |
| - | * -0.5 - toate clasele intr-un singur fisier | + | * 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. |
| - | * -0.3 - toate sursele puse intr-un pachet | + | * 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.). |
| - | * -0.1 - includerea altor fișiere care nu au legătură cu cerința | + | * 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). |
| - | * -0.1 - includere folder bin in arhivă | + | * 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. |
| + | </note> | ||
| + | ==== Depunctări generale pentru teme ==== | ||
| - | **Documentare:** | + | Temele pe care le primim **trebuie să compileze și să ruleze** pentru a avea posibilitatea de punctaj non-zero. |
| - | * între -0.1 și -0.5 - comentarii absente sau irelevante | + | |
| - | * -0.1 - comentarii de tip TODO în cod | + | |
| - | * (variabil, începând de la -0.2) Javadoc necorespunzător, incomplet, irelevant; inclus și documentarea lipsă sau incorectă a parametrilor metodelor | + | |
| - | * -0.1 - lipsă Javadoc generat sau script de generare. Această depunctare nu se va aplica dacă pentru o anume temă nu este necesară exportarea de documente Javadoc. | + | |
| - | * (variabil, în funcție de alocarea punctajului fiecărei teme) Readme necorespunzător, lipsă, conținut irelevant, etc | + | |
| - | **Design, implementare:** | + | Vom aplica depunctări legate de calitatea codului și a abordărilor temelor. Din 10 puncte: |
| - | * -0.5 - cod duplicat | + | |
| - | * între -0.1 și -0.3 hardcodări | + | |
| - | * folosiți constante în locul valorilor numerice/String-urilor literali | + | |
| - | * -0.1 - metode șau variabile nefolosite | + | |
| - | * între -0.1 și -0.5 - metode lungi (> 100 de linii) care ar fi putut fi sparte, bucăți mari de logică în main etc | + | |
| - | * -0.1 - print-uri prin cod | + | |
| - | * între -0.2 și -0.5 - ruperea încapsulării | + | |
| - | * între -0.2 și -0.5 - modificatori de acces folositi necorespunzator (e.g. metode lăsate publice care de fapt ar trebui să fie private) | + | |
| - | * -0.1 - instanceof-uri și teste de tip in situații în care putea fi folosit polimorfismul | + | |
| - | * -0.5 - folosirea tipurilor "raw" în loc de tipurile parametrice (generic) e.g. ''new ArrayList()'' în loc de ''new ArrayList<String>()'' | + | |
| - | * (variabil, -0.2 până la -2 sau peste) design rigid, greoi, inextensibil, bug-prone | + | |
| - | 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. | + | {{:poo-ca-cd:administrativ:barem_1.png?600|}} |
| - | + | {{:poo-ca-cd:administrativ:barem_2.png?600|}} | |
| - | Pentru abateri minore (de exemplu un nume de metodă folosit neadecvat, in toată tema), se vor pune doar observații cu -0.0. | + | {{:poo-ca-cd:administrativ:barem_3.png?600|}} |
| - | + | {{:poo-ca-cd:administrativ:barem_4.png?600|}} | |
| - | Ce considerăm util să conțină un fișier README pentru o temă la POO: | + | {{:poo-ca-cd:administrativ:barem_5.png?600|}} |
| - | * componentele soluției: rolurile lor și relațiile dintre ele | + | {{:poo-ca-cd:administrativ:barem_6.png?600|}} |
| - | * **nu** este necesar să luați pe rând fiecare clasă și să îi descrieți câmpurile și metodele, pentru asta există javadoc. | + | {{:poo-ca-cd:administrativ:barem_7.png?600|}} |
| - | * flow-ul dintre componente - e.g. cum se realizează o anumite acțiune, ce clase sunt implicate. | + | |
| - | * probleme întâmpinate (dacă ați avut) | + | |
| + | <note important> | ||
| + | * 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. | ||
| + | </note> | ||
