В этом посте выражено только мнение автора, которое, безусловно, не является последней инстанцией и не претендует на правоту. Высказывания вначале не являются цитатами и никого конкретно не предполагают.
— Так вы говорите, что вся логика по работе со всеми устройствами собрана в этом классе?
— Да. Это паттерн медиатор.
— За интерфейс пользователя у меня отвечает класс CUserInterface.
— Ну что ж, давайте посмотрим на вашу замечательную программу.
— Ой, я ее дома оставила.
— Таким образом, все объекты игры можно поворачивать вокруг опорной точки.
— А можно пример?
— Хм. К сожалению, в игре ни один объект не поворачивается.
Первое место - игра.
Что-то в духе дендевской убивалки кучи космических кораблей, движущихся косяком. Два человека в команде.
Человек шарил в программировании, нормально выделил подсистемы, попрятал их за интерфейсами.
Довольно строгая иерархия. В общем все как-то хорошо.
Человек выступал первым, даже страшно стало дальше судить.
Что не понравилось — не понятно, чем занимался второй человек из команды. Сдавал электронику?
Единственное замечание — обычно идет разделение логики, которая генерирует структуры для отрисовки, от логики, которая их рисует на 2 потока.
Второе место — оффлайн клиент для айтема.
Шесть человек! Не совсем понятно чем они все занимались.
Есть: пхпшный скрипт, дергающий нужную инфу с сайта. Плюсовый клиент, который тагяет эту инфу и, соответственно, позволяет немножко поиграться с сайтом. Сумбурное выступление, так и не понятыми остались практически все моменты. От безопасности до транзакционности. Да. Интерфейс только консольный.
Третье место — железный проект.
Управление холодильной установкой, кажется. Два человека.
На сколько все хорошо в смысле электроники (подключили девайсы к компу через юсб, весело все настроили, была клевая демка про включающийся от определенной температуры кулер), на столько все плохо в смысле программирования :-(.
В целом ребята неплохо потрудились, но видимо не хватило времени на нормальное проектирование системы. А может и такая задача не стояла...
Респект двум девушкам, которые стали интересно рассказывать про систему моделирования выкроек, но так и не показали ни программу, ни диаграм :-(
Был занятный проект по моделированию сетевых взаимодействий, но он был а) совсем-совсем недописан, б) видно было, что сети ребятам пришлось учить на досуге. Соответственно, смутно поддающаяся осмыслению структура классов.
Трудности, которые есть у всех проектов:
1) UI. Потому что надо делать интерфейс на WinAPI. Причем у тех, кто делает игры - все получается гораздо лучше. Почему?
Потому что в смысле игры понятно, что надо делать некую библиотеку графических примитивов. А в винапи обычно все ограничиваются классом UserInterface, который непонятно что из себя представляет и непонятно как рисуется.
Посему предложение. Предлагаю в рамках курсовых по ТП объединять 2 или 3 людей и предлагать сделать им совместную оконную библиотеку. Это будет их общая часть и работа в команде. Далее эту библиотеку все трое берут и используют в своих основных проектах. Так народ поймет, как действуют рад-контролы, которые потом будут использовать направо и налево.
Точно так же можно поступить с другими библиотеками (файловый менеджмент, хранилище информации а-ля бд, хмл-парсинг, ...). Таким образом, в рамках каждого курсового проекта можно будет поработать в нескольких командах над шареной частью, и останется своя часть, которая всеми этими либами пользуется.
Так студенты поймут отличие инфраструктуры от конкретного проекта, и будут потом легче разбираться с особенностями сторонних библиотек (зачем тут этот метод?!).
2) Время. Не секрет, что в программировании каждый год устаревает 50% твоих знаний :-) Посему чем дальше от появления дотнета, тем древнее выглядит программирование на винапи. При этом хочется сделать чего-то интересное. По сему у меня предложение. Накопленные за 1-2 года такие библиотеки можно сложить в стопочку, и использовать в дальнейшем как данность. К примеру, для курсового по поводу моделирования одежды совершенно не повредит уже написанный кем-то хмл-парсер. Учитывая, что там обязательно найдутся баги, все равно с ним придется немного разбираться.
3) Правильные решения. Студенту очень сложно принять верное решение. Он только-только познакомился с паттернами, еще не понял смысл и выгоды от большинства из них, а от него уже требуются грамотные архитектурные решения. Особенно когда надо все сводить вместе и заставлять работать. Мое предложение — показать студентам полностью законченный проект. При этом можно отдать им на растерзание все диаграммы и более-менее спецификации, а код показывать только на парах. Тут конечно можно возразить, что чем кормить готовым решением, лучше пусть сами придумают. Но придумают ли? Взять любой предмет вроде ТАВТа — там структура (читай архитектурное решение) автомата задается жестко или дается на выбор из нескольких хорошо описанных. А уж как ты внутри наделаешь — дело твое.
Интересно отметить, что все студенты пользовались субвершин контролем, поднятым на кафедре. Также часть студентов занималась проектом на современных платформах. Жаль, что они не были представлены на конкурсе.
Очень жаль, что многие не успевают завершить проект в срок. Учитывая, что народ на третьем курсе, понятно, что они не могут адекватно оценить сложность проекта. Ну а раз это курсовой со строгим сроком сдачи, естественно, что время является самым большим риском. Как известно, программистское сообщество, в попытке отойти от этого риска, особенно проявляющегося в тяжеловесных методиках разработки (70% времени проекта прошло — business value 0), перешло к легковесным аджайл методикам (70% времени проекта — ~70% business value). Может быть стоит и этот курсовой перевести на них?
За такой подход выступает аргумент, что проектирование без знания технологической части (а так оно и есть), это практически проектирование вслепую. Поэтому у большинства и возникает пресловутый класс UserInterface.
Хотя, я вот подумал, а как перевести на аджайл, например, курсовой по автоматам?
