Стоит ли давать две версии некоторых заданий на выбор: более простую и более сложную (за более простую даётся меньше баллов)?
Особенно меня интересует мнение студентов, которые делают по практике мало или очень мало: отпугивает ли вас сложность заданий? Стали бы вы работать больше, если бы была возможность выбрать задания проще?
Нужно ли посвятить лабораторную/семинар теме модульного тестирования?
Сейчас я склоняюсь к тому, чтобы провести в начале семестра один семинар для обсуждения тестирования.
Скажу так, этот курс хорош и мне он нравится. Я пробовал пропускать парочку лекций @Admin’a, но всё равно возвращался, а значит, всё хорошо. Касательно лекций мы уже обсуждали, что можно попробовать совмещать листы с кодом и диаграммами совместно с презентациями, на которых можно показывать примеры и не тратить время на доску.
По поводу практики. После первого общего проекта устоялось мнение, что задачи составлялись так, будто в них нужно впихнуть невпиху паттерн. И на мой взгляд, было бы чудесно, если было бы какое-нибудь мероприятие типа “вот вам опенсорц проект, давайте найдём там паттерн и объясним зачем он там”.
Было мало гита. И мне кажется, что нужно сделать упор на него в первом задании. Команды revert, reset, show, diff, checkout, remote * и очень важный bisect. А в контрольной работе можно было бы дать уже готовый репозиторий (только не с треугольниками, прошу), и сказать: вот есть баг, найдите коммит, в котором он появился, отмените этот коммит, переключитесь на ветку, в котором появляется графический интерфейс, слейте в мастер, разрешите конфликты.
Семинар для тестирования — нужно. Примеры плохих / хороших тестов, крутые фичи тестовых фреймворков. Возможно, подключение сервера интеграционного тестирования.
Откомментирую еще этот пункт со своей стороны. Кроссплатформенность - это не то главное свойство, которое нами ценится при чтении курса “Паттерны проектирования”. Прекрасно известно, что есть множество разных критериев выбора. Кроссплатформенность - всего лишь одно из них.
Если уж сравнивать C# и Java, то язык C# и фреимворк .NET технологически более совершенный чем Java.
Кроме того, меня удивляет этот вопрос, поскольку у ИТ-шника во главу угла должны ставиться не собственные предпочтения, а спецификация задачи. Если в спецификации написано C#, значит, вопросы про Java неуместны. Вот представьте себе - Вы приходите в фирму, Вам начальник говорит “требуется дописать этот модуль на C#”, а Вы ему говорите “зачем C# - давайте на Java - она существенно более кроссплатформенная!”
Поэтому я бы не вёлся на предпочтения студентов - спецификация есть спецификация.
Здесь вопрос в том, почему спецификация такая, и можно ли её ослабить. В принципе, я ничего против Java в контексте практики по курсу не имею. Я даже в прошлом году хотела один проект дать на Java, чтобы аккуратно поработать с исключениями, но и так всего много.
Работа в команде - это лучшее, что можно было придумать. Гораздо интереснее делать большие проекты, чем колупать маленькие задачки самому. Это уныло(.
Две версии задания придумывать считаю нецелесообразным. С точки зрения программирования, ничего космически-сложного нам сделать не предлагается. А если студент не хочет ничего делать, то он не будет делать и то задание, которое проще, но даёт меньше баллов.
Семинар про тестирование я бы послушал, а то вышло всё как-то странно “Вот вам статья, на следующем занятии контрольная с использованием вот этого вот”. Хотелось бы ещё, чтоб грамотные люди всё рассказали и показали.
По-моему, перед лекциями нужно было потратить 10-15 минут на UML диаграммы, объяснить всякие стрелочки\прямоугольнички. А то поначалу смотришь на них, и думаешь, что это?
Стрелочки и прямоугольники (диаграммы классов) были уже на первом курсе и легко гуглятся. Полагаю, достаточно просто предупредить, что на лекции будет использоваться эта нотация.
Слушайте, ну если студенты за два года (!) не смогли хотя бы приблизительно запомнить, что означают прямоугольнички и стрелочки, то что тут поделаешь. А задания с UML диаграммами были и на первом, и на втором курсе. После того как на лекциях на первом курсе про них рассказали.
Вот. Я этого и ожидал. СтОит Вам сказать, что можно на Java, как начнется “давайте на C++, питоне, на хаскеле, а я хочу на вижуалбейсике, а я на бреинфаке - он тьюрингполный!”
Должен заметить, что нас курс не по языкам программирования, а по паттернам. А проверять это многоцветие - знаете, задача не очень. И исправлять не паттерновские ошибки на разных языках - или не исправлять потому что невозможно одинаково хорошо знать всё.
Вообще, несогласен с @kvark161, первая ссылка в гугле ведёт на отличный гайд о том, что есть UML и как понимать термины композиция, агрегирование, и всё такое. Можно разве что в мудл такую ссылку дать.
Ссылочная vs размерная модель, статическая vs динамическая типизация, переменные/константы vs val-значения/переменные, наследование одиночное vs множественное vs подмешивание (миксины), классические интерфейсы и классы vs трейты и классы vs протоколы и прочее, обобщённое программирование, стандартные типы и библиотеки, и так далее.
Кроме общечеловеческих вещей (избегайте литералов, дублирование кода — это плохо, etc.) при проектировании конечно же надо учитывать и использовать возможности языка. А особенности, идеология и подводные камни у них разные. Особенно в контексте средств ООП.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021