Рекомендации по выполнению практических работ по программированию от МВ
Материал из Вики ИТ мехмата ЮФУ
Версия от 00:04, 9 февраля 2009; Admin (обсуждение | вклад)
Принимать практические работы, как правило, довольно весело. Такое количество «перлов» редко где встретишь. Однако довольно часто количество переходит в качество, причем весьма нехорошее. Соответственно, несколько простых требований к практическим работам, которые предназначаются для сдачи, и к самому процессу сдачи таковых работ:
- Программа (проект, модуль, библиотека и проч.) должна работать, то есть решать поставленную задачу. Это значит, что она должна запускаться! И работать! Правильно!
- Хорошим тоном считается сначала продемонстрировать работу программы, а уж потом любезно продемонстрировать исходные коды, тексты и проч.
- Алгоритм – это, конечно, сложная штука. И определений у этого термина много. И свойств. Некоторые даже нужно знать. В том числе – массовость. И если преподаватель просит выполнить программу с другими исходными данными – это он не со зла, это просто массовость алгоритма проверяется.
- Не пишите программ для экстрасенсов. И для любителей транслита. Если после запуска программы на черном экране мерцает курсор в ожидании ввода или же написано «Vviditi chislo:» – это не к добру. Даже консольное приложение на C несложно «научить» говорить по-русски. Ну, или на чистом человеческом английском – кому как нравится.
- Программы нужно комментировать. Обязательно.
- Программы нужно писать с отступами. Но не с художественными, а с правильными.
- Алгоритм должен быть эффективным. Например, кроме сортировки «пузырьком» есть еще и другие. Вычислять степень через логарифмы – плохая идея. Сортировать файлы тем же «пузырьком» – плохая примета.
- Нет такого критерия оценки программы – «работает/не работает». По крайней мере, преподаватели о таком критерии ничего не слышали.
- Нет «прошлых» тем. Например, если алгоритм Евклида был изложен на первом курсе, то находить НОД перебором в лоб на втором курсе просто потому, что это легче и быстрее записать – это плохая примета. Даже если он играет лишь вспомогательную роль.
- Не бывает быстрых компьютеров. В принципе. Это все сказки. Поэтому программы надо писать в расчете на медленные и задумчивые машины, ужасно ограниченные в памяти, дисковом пространстве и флопсах.
- Приносить на носителях или присылать по почте материалы с вирусами допустимо только в том случае, если вы – автор этого вируса. И сдаете задание по курсам наподобие «Информационная безопасность» или «Системное программирование».
- Присылать по почте весь проект целиком – плохо. Если проект в виде архива занимает мегабайты – то либо это плод работы нескольких лет, либо что-то тут не так (иногда, правда, бывают исключения – изображения, звук и т.д.). Как правило, временные и исполняемые файлы пересылать совсем не обязательно. А таковыми обычно являются все файлы объемом более нескольких десятков килобайт.
- Вольности в выборе инструментария имеют свои пределы. Если есть какой-то язык или библиотека, в котором поставленное задание решается «в пять строк», то лучший вариант – выполнить задание двумя способами.
Вообще-то, при приеме работ на саму работу можно и не смотреть. Оценки можно и по ключевым фразам выставлять (практически все «жизненные»):
Неудовлетворительно:
- «она почему-то не работает»;
- «ну ведь она же работает!!!!!»;
- «вчера свет отключали»;
- «у меня винчестер полетел»;
- «я тут в Гугле нашел …»;
- «я давно ее написал, не помню, что эта функция делает»;
- «нет, что вы, я сам писал! А от программы соседа моя отличается! Вот, посмотрите, в 23 строке вместо i счетчик j назван!»;
- «у вас Delphi неправильный, я вот на 7 писал – и все работало!»;
- «оператор отказался копировать исполняемые файлы, а исходники я дома забыл».
Удовлетворительно:
- «она ПОКА не работает в других случаях»;
- «ну и что, что утечка памяти – сейчас везде сборка мусора. И вообще это не утечка, это такая стратегия работы»;
- «ну я же торопился, потому так и написал. А вообще я хорошо пишу!»;
- «не обращайте внимания на предупреждения компилятора – это бета-версия»;
- «конечно, я знаю, что файлы надо закрывать»;
- «я торопился, поэтому не вынес этот метод в отдельный модуль. Ну и что, что он 5 раз встречается в разных местах, это мелочи»;
- «ну я же торопился, потому так и написал. А вообще я хорошо пишу!»;
- «да я как-то привык на транслите писать»;
- «вот, для запуска нажмите кнопку с надписью «Button1».
Хорошо/отлично:
- «эта кнопка для отработки особого случая»;
- «к сожалению, руководство пользователя не успел дописать»;
- «конечно, тестировал – вот, смотрите»;
- «да, и в этом случае тоже работает, я проверял».
Тут, конечно, доля шутки есть. Но гораздо меньшая, чем кажется на первый взгляд.