- Vitaliy Pavlenko
- Oleg Dubynskiy
- Anton Myronyuk
- Anton Velychko
Облачное хранилище файлов. Клиент-серверное приложение. Пользователь может авторизироваться на сервере, загружать файлы поддерживаемых типов (первоначальный вариант - .txt), просматривать список своих файлов, скачивать их и редактировать. Под "редактированием" имеется ввиду поддержка для каждого типа файлов определенных действий. Например, для текстового файла - отображение его содержания на экране, редактирование текста и сохранение, а также вывод статистики о файле (количество символов, слов и т.д.)
Предполагаемые точки расширения\изменения:
- Типы авторизации пользователя (логин\пароль в первоначальном виде)
- Типы поддерживаемых файлов
- Типы действий, которые разрешены для каждого типа файлов
- Тип отображения (консольный клиент, десктоп, браузер)
- Сетевой протокол может быть изменен
Как вы помните из лекций, главная сложность в разработке программ начинается при длительной разработке и поддержке программы (разработка может длиться годами), а также при изменении команды в течение этого периода. Эти моменты сложно однозначно смоделировать в виде лабораторной работы, которые зачастую проверяют изучение какой-то конкретной технологии (алгоритма, подхода и т.д.)
В данном курсе в качестве задания вам предлагается разработать систему именно с точки зрения возможной полноценной (а значит длительной) разработки. Это означает, что сутью задания является не только факт работоспособности вашей программы, а её пригодность для того чтобы быть основой для полноценного продукта. Это подразумевает:
- Наличие возможностей для расширения контентом\функционалом, который не требует при этом переписывания имеющегося кода.
- Достаточная изолированность компонент системы, которая позволяет их достаточно безболезненно подменить (например, возможность перейти на другой сетевой протокол)
Для корректного выполнения задания вам очень пригодится лекция о SOLID
В каждом варианте прописаны точки расширения - это те места, которые точно должны быть изолированы. Например, если в первом варианте тип текущей игры проверяется через switch\case - то есть добавление любой новой игры будет требовать переписывания уже имеющегося кода - это неправильное выполнение задания.
Варианты распределяются внутри группы по договоренности, но так чтобы количество бригад выполняющих разные задания было примерно одинаковым. Используемые технологии не ограничены, но не в ущерб выставленным требованиям. Работа выполняется побригадно (3-4 человека) в следующие сроки:
до 30 марта, задание №1. Каждой бригаде необходимо продумать схему собственного проекта - определить кто какие части будет реализовывать и за счет чего будет достигаться требуемая расширяемость\модульность. Схема не ограничена формальными языками, типа UML (UML не требуется вообще) - вы можете нарисовать схему из кружочков и квадратиков, главное уметь рассказать, что они означают и как решают поставленную задачу.
до 20 апреля, задание №2, реализация варианта в первоначальном виде (одна игра, один тип файл). В качестве графического интерфейса вполне достаточно использовать консоль
до 4 мая, задание №3, реализация индивидуальной задачи - вам будет предложено расширить систему и заменить один из узлов системы.
до 18 мая, задание №4 - задание по TDD
до 8 июня, задание №5 - TBA
Каждое задание оценивается в 10 балов, в случае сдачи после дедлайна максимальная оценка опускается до 5, если работа сдана в течение следующих двух недель. Если работа сдается в срок, превышающий две недели после дедлайна, максимальная оценка опускается до 2.
Проект ведется в открытом репозитории (например, на гитхабе). Для получения баллов каждый участник бригады должен иметь историю коммитов, уметь объяснить свой код и разбираться в проекте в целом. В случае если коммитов от студента в проекте нет ("ой, не получилось", "ой пришлось все перезалить" и так дальше), личная максимальная оценка опускается до 5. Если же вы не выполняли задание вообще, но пытаетесь выехать за счет остальных участников, оценка может опуститься и в 0