KeepEasy

Человек так устроен, что запоминает наиболее яркие моменты своей жизни. Одним из таких моментов для меня было преодоление психологической метки в 1000 строк кода. Описываемый проект разрабатывался чуть менее года назад, в рамках курса «Проектирование человеко-машинного интерфейса». И хотя педагоги объявляли целью данного проекта приобретение навыков проектирования и разработки интерфейсов программ, я немного вышел за рамки курсовой работы и столкнулся с некоторыми проблемами разработки, о которых будет этот блог.

Итак, прежде чем будем углубляться в подробности, замечу что большая часть требований относилась к оформлению курсовой работы, нежели к самой программе. Основные требования к ПО были:

• язык программирования — Java
• платформа интерфейса — JavaFX
• под запретом использование любых баз данных
• понятный интерфейс
• вход по паролю, иерархия пользователей

Предметную область я выбрал «Успеваемость студентов на факультете».

Тема выдвигала следующие дополнительные требования к системе:

В системе должны поддерживаться режимы учета учащихся и результатов сдачи экзаменов, анализа сессии по семестрам, по факультетам, специальностям, генерации отчетов отличников и двоечников.

Самым сложным в задании мне показалось хранение данных. Ведь если хранение данных организовать в файлах, то при увеличении количества информации в системе будет усложнено редактирование уже существующих данных, так как придется переписать весь файл, что чревато временными затратами. Не зная на тот момент о третьей нормальной форме, я решил выделить сущности, и их составляющие или же связи между ними. К примеру главной записью оказалась экзаменационная оценка, кроме того что запись должна хранить саму оценку, она так же должна содержать предмет, сессию (какого года, семестра), и кому она поставлена.

Хранение записи в файлах, я организовал следующим образом: каждая строчка — это одна запись, каждая запись содержит несколько видов полей, разделенных специальным символом, выбранным в зависимости от типа хранимых данных. Для уменьшения количества записываемой/считываемой с диска информации, любое поле, которое потенциально может повторяться, я выносил в другой файл, и снабжал его индексом, записывая индекс вместо поля. Таким образом у меня получилась этакая реляционная база данных на минималках.

Паттерны проектирования я ещё не знал, и у меня получился громадный и ужасный код. К примеру, у каждого файла был свой класс, свой тип данных, и свой механизм записи. Таким образом я получил набор классов, отличающихся только по количеству и типу полей, а в остальном идентичных, к слову эти классы не были даже объединены интерфейсом. В конце концов я начал путаться в коде, код стал сложен для редактирования или добавления нового функционала. Сдал до конца недоделанную курсовую работу. Так как отпало желание, что-либо делать: каждое малейшее изменение порождало цепь других.

Посмотреть на проект можно тут: https://github.com/SirojiddinSaidmurodov/StudSystem

Там же можно найти саму курсовую работу, где подробнее описано устройство механизмов записи и хранения данных, а так же общий функционал.

Вместо выводов

1. Если реализация программы требует несколько сущностей, классов, стоит задуматься о применении того или иного паттерна. Так как при увеличении количества кода, рано или поздно что-либо придется менять. Паттерны проектирования позволяют выделить код расположенный к изменению таким образам, что это коснется только данной части программы.
2. Базы данных, неважно выделенные или встроенные, весьма интересная технология упрощающая жизнь программиста. При использовании БД нет надобности о беспокойстве как будут сохранены данные, а когда данных много, а их в последнее время очень много, это становится критичным.