Рекомендации по выполнению практических работ по программированию от МВ

Принимать практические работы, как правило, довольно весело. Такое количество «перлов» редко где встретишь. Однако довольно часто количество переходит в качество, причем весьма нехорошее. Соответственно, несколько простых требований к практическим работам, которые предназначаются для сдачи, и к самому процессу сдачи таковых работ:

1. Программа (проект, модуль, библиотека и проч.) должна работать, то есть решать поставленную задачу. Это значит, что она должна запускаться! И работать! Правильно!
2. Хорошим тоном считается сначала продемонстрировать работу программы, а уж потом любезно продемонстрировать исходные коды, тексты и проч.
3. Алгоритм – это, конечно, сложная штука. И определений у этого термина много. И свойств. Некоторые даже нужно знать. В том числе – массовость. И если преподаватель просит выполнить программу с другими исходными данными – это он не со зла, это просто массовость алгоритма проверяется.
4. Не пишите программ для экстрасенсов. И для любителей транслита. Если после запуска программы на черном экране мерцает курсор в ожидании ввода или же написано «Vviditi chislo:» – это не к добру. Даже консольное приложение на C несложно «научить» говорить по-русски. Ну, или на чистом человеческом английском – кому как нравится.
5. Программы нужно комментировать. Обязательно.
6. Программы нужно писать с отступами. Но не с художественными, а с правильными.
7. Алгоритм должен быть эффективным. Например, кроме сортировки «пузырьком» есть еще и другие. Вычислять степень через логарифмы – плохая идея. Сортировать файлы тем же «пузырьком» – плохая примета.
8. Нет такого критерия оценки программы – «работает/не работает». По крайней мере, преподаватели о таком критерии ничего не слышали.
9. Нет «прошлых» тем. Например, если алгоритм Евклида был изложен на первом курсе, то находить НОД перебором в лоб на втором курсе просто потому, что это легче и быстрее записать – это плохая примета. Даже если он играет лишь вспомогательную роль.
10. Не бывает быстрых компьютеров. В принципе. Это все сказки. Поэтому программы надо писать в расчете на медленные и задумчивые машины, ужасно ограниченные в памяти, дисковом пространстве и флопсах.
11. Приносить на носителях или присылать по почте материалы с вирусами допустимо только в том случае, если вы – автор этого вируса. И сдаете задание по курсам наподобие «Информационная безопасность» или «Системное программирование».
12. Присылать по почте весь проект целиком – плохо. Если проект в виде архива занимает мегабайты – то либо это плод работы нескольких лет, либо что-то тут не так (иногда, правда, бывают исключения – изображения, звук и т.д.). Как правило, временные и исполняемые файлы пересылать совсем не обязательно. А таковыми обычно являются все файлы объемом более нескольких десятков килобайт.
13. Вольности в выборе инструментария имеют свои пределы. Если есть какой-то язык или библиотека, в котором поставленное задание решается «в пять строк», то лучший вариант – выполнить задание двумя способами.

Вообще-то, при приеме работ на саму работу можно и не смотреть. Оценки можно и по ключевым фразам выставлять (практически все «жизненные»):

Неудовлетворительно:

• «она почему-то не работает»;

• «ну ведь она же работает!!!!!»;

• «вчера свет отключали»;

• «у меня винчестер полетел»;

• «я тут в Гугле нашел …»;

• «я давно ее написал, не помню, что эта функция делает»;

• «нет, что вы, я сам писал! А от программы соседа моя отличается! Вот, посмотрите, в 23 строке вместо i счетчик j назван!»;

• «у вас Delphi неправильный, я вот на 7 писал – и все работало!»;

• «оператор отказался копировать исполняемые файлы, а исходники я дома забыл».

Удовлетворительно:

• «она ПОКА не работает в других случаях»;

• «ну и что, что утечка памяти – сейчас везде сборка мусора. И вообще это не утечка, это такая стратегия работы»;

• «ну я же торопился, потому так и написал. А вообще я хорошо пишу!»;

• «не обращайте внимания на предупреждения компилятора – это бета-версия»;

• «конечно, я знаю, что файлы надо закрывать»;

• «я торопился, поэтому не вынес этот метод в отдельный модуль. Ну и что, что он 5 раз встречается в разных местах, это мелочи»;

• «ну я же торопился, потому так и написал. А вообще я хорошо пишу!»;

• «да я как-то привык на транслите писать»;

• «вот, для запуска нажмите кнопку с надписью «Button1».

Хорошо/отлично:

• «эта кнопка для отработки особого случая»;

• «к сожалению, руководство пользователя не успел дописать»;

• «конечно, тестировал — вот, смотрите»;

• «да, и в этом случае тоже работает, я проверял».

Тут, конечно, доля шутки есть. Но гораздо меньшая, чем кажется на первый взгляд.

Оригинал — здесь.