Очевидното: код.
Кодът трябва да покрива функционалността, описана в заданието. Също така трябва да се държи адекватно във всички слуачаи: грешен потребителски вход, грешки от околната среда, паднал таван. Под адекватно се има предвид следното: ако е възможно — нека работи правилно, а ако не е — да уведоми потребителя по подходящ начин защо не може да работи правилно.
Unit тестове
Хубаво ще е тестовете ви да покриват възможно най-голяма част от кода и разклоненията в него. Също така нека са поставени в отделни класове (файлове) в зависимост от логичеката структура на проекта ви.
Игри и друг GUI intensive софтуер
Когато сте избрали да пишете неща, наподобяващи игри — или каквито и да е други проекти, изискващи сериозно GUI — постарайте се да "откачите" основния си код максимално много от рисуването/графиката/GUI-то. Целта ви е да имате много ясно разделение и абстракция между "ядрото" на вашия проект и графичния му интерфейс. Добре би било основната логика на проекта ви да се намира изцяло в "ядрото", под формата на класове, модули и прочее, като това ядро предоставя на своите позлватели някакво API. Тоест, стремите се да пишете въпросното ядро все едно пишете библиотека, която ще се преизползва в друг(и) софтуер(и). От там нататък, GUI-то се прави като wrapper на тази библиотека, ползва публичното й API и е един вид pluggable компонент към нея.
Можете да минете и само с кода от основното ядро, който имплементира функционалност без GUI, ако сте писали обилно тестове. Този проект е подходящ шанс за вас да пробвате подхода TDD. Допълнително, това ще ви помогне да покриете едно от изискванията, а именно да имате пълно покритие с unit тестове.
GUI-то е добре да е съвсем просто и може да минете без особено тестване там, освен, евентуално, някой друг инреграционен тест. Може да минете и с най-просто и дървено конзолно UI, което е тънка обвивка около API-то на "ядрото". Ако сте запалени, може да направите повече от едно GUI. Последното е възможно да ви донесе бонус точки :)
Документация
Всъщност докуементацията не е задължителна. Ако смятате, че кодът е достатъчно самоописателен — не се тормозете с обемна документация, кратко описание за ключовите класове/функции ще бъде напълно достатъчна. И все пак смятате, че на четящия кода ви ще му бъде нужен някой и друг docstring, опитайте се да бъдат максимално полезни за четящия и да казват същественото, а не само това, което може да се види с един поглед в кода.
Version control
Задължително е. Силно препоръчваме да ползвате Git и GitHub. Няма проблем кодът на проекта да ви е публичен. Ако все пак държите да ползвате друга version control система, пак ще приемем това изискване за покрито. Важното е да има някакъв version control.
Оценяване
Проверката на функционалността на проектите няма да се прави автоматизирано, което означава че ви се дава свобода да изясните по-дребните детайли.
- 50% от точките, за вeрен и отговарящ на условието код. Трябва като минимум да покриете условието на проекта (по ваш избор можете да го разширите, но не и да променяте/пропускате части от него)
- 30% за стил, другояче казано: за четим код, добър дизайн, лесни възможности за разширяване на програмата ви, достатъчна документация.
- 20% отиват при добрите unit тестове.