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