Паттерны проектирования приложений — Пожелания/замечания/предложения

У меня тоже есть два вопроса.

  1. Стоит ли давать две версии некоторых заданий на выбор: более простую и более сложную (за более простую даётся меньше баллов)?
    Особенно меня интересует мнение студентов, которые делают по практике мало или очень мало: отпугивает ли вас сложность заданий? Стали бы вы работать больше, если бы была возможность выбрать задания проще?

  2. Нужно ли посвятить лабораторную/семинар теме модульного тестирования?
    Сейчас я склоняюсь к тому, чтобы провести в начале семестра один семинар для обсуждения тестирования.

Скажу так, этот курс хорош и мне он нравится. Я пробовал пропускать парочку лекций @Admin’a, но всё равно возвращался, а значит, всё хорошо. Касательно лекций мы уже обсуждали, что можно попробовать совмещать листы с кодом и диаграммами совместно с презентациями, на которых можно показывать примеры и не тратить время на доску.

По поводу практики. После первого общего проекта устоялось мнение, что задачи составлялись так, будто в них нужно впихнуть невпиху паттерн. И на мой взгляд, было бы чудесно, если было бы какое-нибудь мероприятие типа “вот вам опенсорц проект, давайте найдём там паттерн и объясним зачем он там”.

Было мало гита. И мне кажется, что нужно сделать упор на него в первом задании. Команды revert, reset, show, diff, checkout, remote * и очень важный bisect. А в контрольной работе можно было бы дать уже готовый репозиторий (только не с треугольниками, прошу), и сказать: вот есть баг, найдите коммит, в котором он появился, отмените этот коммит, переключитесь на ветку, в котором появляется графический интерфейс, слейте в мастер, разрешите конфликты.

Семинар для тестирования — нужно. Примеры плохих / хороших тестов, крутые фичи тестовых фреймворков. Возможно, подключение сервера интеграционного тестирования.

2 лайка

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

Если уж сравнивать C# и Java, то язык C# и фреимворк .NET технологически более совершенный чем Java.

Кроме того, меня удивляет этот вопрос, поскольку у ИТ-шника во главу угла должны ставиться не собственные предпочтения, а спецификация задачи. Если в спецификации написано C#, значит, вопросы про Java неуместны. Вот представьте себе - Вы приходите в фирму, Вам начальник говорит “требуется дописать этот модуль на C#”, а Вы ему говорите “зачем C# - давайте на Java - она существенно более кроссплатформенная!”

Поэтому я бы не вёлся на предпочтения студентов - спецификация есть спецификация.

Здесь вопрос в том, почему спецификация такая, и можно ли её ослабить. В принципе, я ничего против Java в контексте практики по курсу не имею. Я даже в прошлом году хотела один проект дать на Java, чтобы аккуратно поработать с исключениями, но и так всего много.

Правильно!

Копать от забора и до обеда!

А самые умные вместо люминия будут грузить чугуний…

Работа в команде - это лучшее, что можно было придумать. Гораздо интереснее делать большие проекты, чем колупать маленькие задачки самому. Это уныло(.

Две версии задания придумывать считаю нецелесообразным. С точки зрения программирования, ничего космически-сложного нам сделать не предлагается. А если студент не хочет ничего делать, то он не будет делать и то задание, которое проще, но даёт меньше баллов.

Семинар про тестирование я бы послушал, а то вышло всё как-то странно “Вот вам статья, на следующем занятии контрольная с использованием вот этого вот”. Хотелось бы ещё, чтоб грамотные люди всё рассказали и показали.

И да, только не треугольники

1 лайк

Хорошо. А если студент захочет писать на Питоне?

Давайте не на Python, а на любом ООП-языке, будь то Scala, Swift или Ruby.

Python ничем не хуже.

Нет, остальное не годится, отличий много.

По-моему, перед лекциями нужно было потратить 10-15 минут на UML диаграммы, объяснить всякие стрелочки\прямоугольнички. А то поначалу смотришь на них, и думаешь, что это?

Стрелочки и прямоугольники (диаграммы классов) были уже на первом курсе и легко гуглятся. Полагаю, достаточно просто предупредить, что на лекции будет использоваться эта нотация.

Да, но какая часть студентов будет с ними разбираться до лекции?

Слушайте, ну если студенты за два года (!) не смогли хотя бы приблизительно запомнить, что означают прямоугольнички и стрелочки, то что тут поделаешь. А задания с UML диаграммами были и на первом, и на втором курсе. После того как на лекциях на первом курсе про них рассказали.

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

А работа в команде - потрясающая вещь. Сложность и интересность заданий увеличивается в разы

1 лайк

Вот. Я этого и ожидал. СтОит Вам сказать, что можно на Java, как начнется “давайте на C++, питоне, на хаскеле, а я хочу на вижуалбейсике, а я на бреинфаке - он тьюрингполный!”

Должен заметить, что нас курс не по языкам программирования, а по паттернам. А проверять это многоцветие - знаете, задача не очень. И исправлять не паттерновские ошибки на разных языках - или не исправлять потому что невозможно одинаково хорошо знать всё.

Вообще, несогласен с @kvark161, первая ссылка в гугле ведёт на отличный гайд о том, что есть UML и как понимать термины композиция, агрегирование, и всё такое. Можно разве что в мудл такую ссылку дать.

@juliet, а в каком смысле сильно разнятся?

Ссылочная vs размерная модель, статическая vs динамическая типизация, переменные/константы vs val-значения/переменные, наследование одиночное vs множественное vs подмешивание (миксины), классические интерфейсы и классы vs трейты и классы vs протоколы и прочее, обобщённое программирование, стандартные типы и библиотеки, и так далее.

Кроме общечеловеческих вещей (избегайте литералов, дублирование кода — это плохо, etc.) при проектировании конечно же надо учитывать и использовать возможности языка. А особенности, идеология и подводные камни у них разные. Особенно в контексте средств ООП.

3 posts were split to a new topic: (ФИИТ 3 курс) Паттерны проектирования приложений — несправедливости!

A post was merged into an existing topic: (3 курс ФИИТ) Паттерны проектирования приложений — несправедливости!