timeit

Програмиране с Python

Курс във Факултета по Математика и Информатика към СУ

Изберете си проект

Предадени решения

Краен срок:
30.04.2016 23:59
Точки:
0

Срокът за предаване на решения е отминал

Мета

Основна цел на проекта

Темата, която ще си изберете, не е толкова важна за нас. Ние държим да прекарате време с Python и екосистемата около него и да напишете нещо по-голямо, което да ви принуди да направите следните неща:

  • Да отделите време да се преборите с практическите, проблеми, до които неминуемо води всеки един по-голям и по-практически насочен софтуер.

  • Да намерите най-оптималния и ефективен начин за решение на определен проблем, тъй като това е нещо, което всеки програмист прави ежедневно.

  • Да се преборите с построяването и поддържането на инфраструктура за разработване, ако все още нямате добра такава.

  • Да пробвате нещо ново – например, test-driven development, или изобщо писане на тестове. Много е важно да проучите как се прави в съответния език и екосистема (в случая, Python) – с какви инструменти, как да си настроите редактор и помощни програми, така че тестовете да се пускат максимално лесно и да минават максимално бързо. Има какво да се експериментира тук.

Тоест, да научите нови неща - както технологично, така и методологично.

Размер и сложност на проекта

Ако една задача в курса ви носи 6 точки, едно предизвикателство една точка, а един проект — 60, може да направите грубата сметка колко сложен трябва да е проектът. Осланяме се на вашата честност и ви оставяме сами да прецените това.

Като цяло, проектът не трябва да е нещо, което да може да се напише за едно или две денонощия. Може да се наложи да си измислите и да вкарате още функционалност, за да покриете това изискване за сложност. Преценката за това какво е "достатъчна сложност" засега остава във вашето поле. Изисквания за функционалност могат да се измислят винаги, така че може да се приеме, че сложността на дадена идея никога не е ограничена отгоре. Тоест, каквато и да е идеята ви, може да добавяте и да добавяте функционалност, докато не се получи нещо с "достатъчна сложност".

В крайна сметка, ако не се опитвате просто да напишете нещо, което да ви "прекара" през курса, а пишете проекта с цел да пробвате и научите нови неща и подходите сериозно, няма да имате проблем.

Започнете навреме.

Самостоятелни проекти

Проектите в курса са индивидуални. Не се допуска групова работа.

Мотивацията зад това решение е, че при груповата работа става много, много трудно да се определи индивидуалния принос на всеки върху проекта, както и как се е справил с взимането на архитектурни решения, със стиловите аспекти на кода, с подхода към решение на поставения проблем и прочее.

Възможно изключение би било ако всеки прави различен, но самостоятелен модул от проекта и двете неща си комуникират по някакъв начин. Желателно е този вариант да се избягва или да се съгласува много добре с екипа на курса.

Какво да има в предложението за тема

Основната цел на описанието на вашата тема е да се съгласува с екипа на курса сложността на проекта. Тоест, това, което трябва да има в описанието, е достатъчно информация, за да придобием обща представа за приблизителната сложност на проекта.

Едно-две изречения са твърде малко. Страници текст - твръде много.

Не е нужно да сте безкрайно подробни, или пък формални. Нямаме нужда от клас-диаграми или архитектурни рисунки, освен ако не ви сърбят ръцете да ги правите и не мислите, че така ще се спестят ок. 1000 думи.

Обикновено ни е необходимо да се опишат точно основните use cases и от птичи поглед технологиите, които мислите да ползвате и да си "стиснем ръцете" за тези две неща, за да се уверим, че проектът ще е достатъчно, но не и прекалено сложен. Без описанието на тези use cases, няма как да сме сигурни. Понякога питаме и за конкретни технологични подробности, ако преценим, че има нужда и че от това сложността зависи значително.

Какво става, ако не можете да се справите с нещо, за което сме се разбрали да има в проекта ви?

В реалността често се налага да се променят предварителните изисквания. Допустими са малки вариации в предварително уговорената тема. За по-големи промени, ни пишете. Например, ако ударите на камък в имплементацията на някаква част от вече уговорената функционалност, пишете ни. Или ще ви помогнем, или ще се разберем да отпадне/да се замени с нещо друго. Разбира се, това трябва да стане достатъчно време преди защитата на проектите.

Как да си изберем тема

Помислете какво ви е интересно. Помислете дали нямате реален, практически проблем, който бихте искали да решите за себе си, или за някой друг. В краен случай, харесайте си съществуващ софтуер и опитайте да реализирате някакво парче от неговата функционалност, като го използвате за спецификация.

Изисквания

Очевидното: код.

Кодът трябва да покрива функционалността, описана в заданието. Също така трябва да се държи адекватно във всички случаи: грешен потребителски вход, грешки от околната среда, паднал таван. Под адекватно се има предвид следното: ако е възможно — нека работи правилно, а ако не е — да уведоми потребителя по подходящ начин защо не може да работи правилно.

Unit тестове

Хубаво ще е тестовете ви да покриват възможно най-голяма част от кода и разклоненията в него. Също така нека са поставени в отделни класове (файлове) в зависимост от логичеката структура на проекта ви.

Документация

На този, който ще чете кода ви ще му бъде нужен някой и друг docstring, опитайте се да бъдат максимално полезни за четящия и да казват същественото, а не само това, което може да се види с един поглед в кода.

Version control

Задължително е. Силно препоръчваме да ползвате Git и GitHub. Кодът на проекта трябва да е публичен. Ако все пак държите да ползвате друга version control система, пак ще приемем това изискване за покрито. Важното е да има някакъв version control.

Напътствия

Игри и друг GUI intensive софтуер

Когато сте избрали да пишете неща, наподобяващи игри — или каквито и да е други проекти, изискващи сериозно GUI — постарайте се да "откачите" основния си код максимално много от рисуването/графиката/GUI-то. Целта ви е да имате много ясно разделение и абстракция между "ядрото" на вашия проект и графичния му интерфейс. Добре би било основната логика на проекта ви да се намира изцяло в "ядрото", под формата на класове, модули и прочее, като това ядро предоставя на своите позлватели някакво API. Тоест, стремите се да пишете въпросното ядро все едно пишете библиотека, която ще се преизползва в друг(и) софтуер(и). От там нататък, GUI-то се прави като wrapper на тази библиотека, ползва публичното й API и е един вид pluggable компонент към нея.

Можете да минете и само с кода от основното ядро, който имплементира функционалност без GUI, ако сте писали обилно тестове. Този проект е подходящ шанс за вас да пробвате подхода TDD. Допълнително, това ще ви помогне да покриете едно от изискванията, а именно да имате пълно покритие с unit тестове.

Добре е кода грижещ се за графичната част да бъде възможно най-прост, така че да има възможно най-малка нужда от тестване. Може да минете и с най-просто и дървено конзолно UI, което е тънка обвивка около API-то на "ядрото". Ако сте запалени, може да направите повече от едно GUI. Последното е възможно да ви донесе бонус точки :)

Оценяване

Проверката на функционалността на проектите няма да се прави автоматизирано, което означава че ви се дава свобода да изясните по-дребните детайли.

  • 50% от точките, за верен и отговарящ на условието код. Трябва като минимум да покриете условието на проекта (по ваш избор можете да го разширите, но не и да променяте/пропускате части от него)

  • 30% за стил, другояче казано: за четим код, добър дизайн, лесни възможности за разширяване на програмата ви, достатъчна документация.

  • 20% отиват при добрите unit тестове.

Максимален брой точки: 60