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

У кого какой опыт есть в этом направлении? Я знаю систему ejudge, которая используется на олимпиадах, однако у нее есть большой минус — она тестирует только задачи, все решение которых написано в одном файле. И с ее помощью нельзя, например, протестировать ООП — проверить наличие необходимых методов, сигнатуры и т.д.

Кто-нибудь пробовал использовать для этого Hudson с какой-нибудь системой тестирования, например Google test? Буду рад услышать чей-то опыт, мысли, предложения.

Здравствуйте, flashnik, Вы писали:

F>Я думаю, есть среди нас те, кто преподает информатику в вузах.
F>Одним из видов учебной активности студентов является выполнение и сдача лабораторных/заданий. Которые мы, преподаватели, должны принимать.
F>Хочется, однако, немного облегчить для себя этот процесс — чтобы совсем неправильные решения отметались сразу и отправлялись на переделку.
Смотря что считать "совсем неправильно".
F>У кого какой опыт есть в этом направлении? Я знаю систему ejudge, которая используется на олимпиадах, однако у нее есть большой минус — она тестирует только задачи, все решение которых написано в одном файле. И с ее помощью нельзя, например, протестировать ООП — проверить наличие необходимых методов, сигнатуры и т.д.
Это не информатика, а программирование.
F>Кто-нибудь пробовал использовать для этого Hudson с какой-нибудь системой тестирования, например Google test? Буду рад услышать чей-то опыт, мысли, предложения.
1. проверка работ по программированию — два шага: а) проверка выполнения. Здесь системы типа ejudge рулят. Но мы не ждали милостей от природы, а написали свою кафедральную. Но так, чтобы можно было автоматизировать создание тестовых данных для проверки проги. Паттерн Template method — РУЛИТ!!!!!
В результате студни сидят в аудитории, препод сидит за свои компом на кафедре. Перед лабой препод пишет два метода на Шарпе: для генерации тестовых данных, для сравнения результата работы студенческой проги и эталонного результата. Студенческая прога, естественно, оформлена по схеме, аналогичной олимпиадной. Студни следят за проверкой по монитору. Выигрышь по сравнению с традиционными системами — можно узнать, на каком тесте вырубилась прога.
Если редакция не зарубит статью, то можно напечатать в РСДН-журнале.
б) проверка КАЧЕСТВА кода. Это — научно-исследовательская работа, которой мы и занимаемся. Тут МНОГО подходов. Но реальных результатов в России (кроме нас) — нет. А мы — на основе обсчета метрик. Написан диссер об измерении показателей качества объектно-ориентированного ПО. На основе нечетких нейронных сетей Ванга-Менделя. Но исследовательской работы — выше крыши. Хотя даже написан диплом, в котором считаются метрики с целью выявить "запахи" по Фаулеру и рекомендовать рефакторинги. Но к сожалению, пацан не захотел дальше в аспирантуру.
В общем, разработок по проверке качества — это на всю мою оставшуюся жизнь хватит... Вместе с моими студентами и аспирантами...

Собственно, сабж...

Здравствуйте, flashnik, Вы писали:

F>Буду рад услышать чей-то опыт, мысли, предложения.

Такие системы в образовании не нужны.
Общение с преподом — это важная часть образования.

Здравствуйте, LaptevVV, Вы писали:


LVV>б) проверка КАЧЕСТВА кода. Это — научно-исследовательская работа, которой мы и занимаемся. Тут МНОГО подходов. Но реальных результатов в России (кроме нас) — нет.

Да дофига результатов, в том числе и в союзе/России...
Лень искать ссылки. Много чего сделали.
Вспомните хотя бы про тот же решарпер с FxCop.
Создать простенькую ЭС для анализа кода — это вообще работа на курсовую/диплом.
Тут проблема даже не столько в механизмах поиска косяков в коде,
а формулировании "правил хорошего тона", с которыми бы соглашались люди...

Здравствуйте, Аноним, Вы писали:

LVV>>б) проверка КАЧЕСТВА кода. Это — научно-исследовательская работа, которой мы и занимаемся. Тут МНОГО подходов. Но реальных результатов в России (кроме нас) — нет.

А>Да дофига результатов, в том числе и в союзе/России...
А>Лень искать ссылки. Много чего сделали.
А>Вспомните хотя бы про тот же решарпер с FxCop.
А>Создать простенькую ЭС для анализа кода — это вообще работа на курсовую/диплом.
А>Тут проблема даже не столько в механизмах поиска косяков в коде,
А>а формулировании "правил хорошего тона", с которыми бы соглашались люди...
Дело не в "правилах хорошего тона", в стандартах качества. Там конкретно прописаны характеристики и показатели качества.
Их надо ИЗМЕРИТЬ. Чего пока никто не делает...

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Аноним, Вы писали:

LVV>>>б) проверка КАЧЕСТВА кода. Это — научно-исследовательская работа, которой мы и занимаемся. Тут МНОГО подходов. Но реальных результатов в России (кроме нас) — нет.

А>>Да дофига результатов, в том числе и в союзе/России...
А>>Лень искать ссылки. Много чего сделали.
А>>Вспомните хотя бы про тот же решарпер с FxCop.
А>>Создать простенькую ЭС для анализа кода — это вообще работа на курсовую/диплом.
А>>Тут проблема даже не столько в механизмах поиска косяков в коде,
А>>а формулировании "правил хорошего тона", с которыми бы соглашались люди...
LVV>Дело не в "правилах хорошего тона", в стандартах качества. Там конкретно прописаны характеристики и показатели качества.
LVV>Их надо ИЗМЕРИТЬ. Чего пока никто не делает...

Сдандарты качества — это и есть "правила хорошего тона"/метрики,
о которых удалось договориться и которые удалось зафиксировать неким
уважаемым коллегами комитетом по страндартицизации.
До этого можно говорить только о неких показателях качества
про которые кто-то верит, что в них есть смысл.

Ну а различные измерения на текстах программ, в том числе и с целью оценить качество
в рамках некой модели качества, — этим уже занимаются давно.

Что, конкретно предложили мерить у вас, что никто никогда в мире до этого не делал?
И почему именно эти метрики интересны с точки оценки качества?
Если несложно, то киньте в меня ссылками на эти работы.

Здравствуйте, Аноним, Вы писали:

LVV>>Их надо ИЗМЕРИТЬ. Чего пока никто не делает...
А>Сдандарты качества — это и есть "правила хорошего тона"/метрики,
А>о которых удалось договориться и которые удалось зафиксировать неким
А>уважаемым коллегами комитетом по страндартицизации.
А>До этого можно говорить только о неких показателях качества
А>про которые кто-то верит, что в них есть смысл.

А>Ну а различные измерения на текстах программ, в том числе и с целью оценить качество
А>в рамках некой модели качества, — этим уже занимаются давно.

А>Что, конкретно предложили мерить у вас, что никто никогда в мире до этого не делал?
А>И почему именно эти метрики интересны с точки оценки качества?
А>Если несложно, то киньте в меня ссылками на эти работы.
Давайте по мылу. Мое мыло — в профиле. Жду сообщения. В ответе — файлы просто пошлю.

LVV>Дело не в "правилах хорошего тона", в стандартах качества. Там конкретно прописаны характеристики и показатели качества.
LVV>Их надо ИЗМЕРИТЬ. Чего пока никто не делает...
Может статью напишите. Журнал же ВАКовский. А то вот Как не стоит писать код

Автор(ы): Огинский Евгений Владимирович, Бурда Роман Вадимович
Дата: 04.06.2011
В статье рассматриваются некоторые ошибки, которые часто встречаются в коде програм. Даны рекомендации, как не стоит писать код, на какие этапы разработки кода нужно обращать внимание в первую очередь.

уже пишут .

Здравствуйте, Dym On, Вы писали:

LVV>>Дело не в "правилах хорошего тона", в стандартах качества. Там конкретно прописаны характеристики и показатели качества.
LVV>>Их надо ИЗМЕРИТЬ. Чего пока никто не делает...
DO>Может статью напишите. Журнал же ВАКовский. А то вот Как не стоит писать код

Автор(ы): Огинский Евгений Владимирович, Бурда Роман Вадимович
Дата: 04.06.2011
В статье рассматриваются некоторые ошибки, которые часто встречаются в коде програм. Даны рекомендации, как не стоит писать код, на какие этапы разработки кода нужно обращать внимание в первую очередь.

уже пишут .
Дык Пишем. И не в один, а в несколько разных...