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

Материал из Вики ИТ мехмата ЮФУ
Перейти к: навигация, поиск

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

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


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

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

  • «она почему-то не работает»;
  • «ну ведь она же работает!!!!!»;
  • «вчера свет отключали»;
  • «у меня винчестер полетел»;
  • «я тут в Гугле нашел …»;
  • «я давно ее написал, не помню, что эта функция делает»;
  • «нет, что вы, я сам писал! А от программы соседа моя отличается! Вот, посмотрите, в 23 строке вместо i счетчик j назван!»;
  • «у вас Delphi неправильный, я вот на 7 писал – и все работало!»;
  • «оператор отказался копировать исполняемые файлы, а исходники я дома забыл».

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

  • «она ПОКА не работает в других случаях»;
  • «ну и что, что утечка памяти – сейчас везде сборка мусора. И вообще это не утечка, это такая стратегия работы»;
  • «ну я же торопился, потому так и написал. А вообще я хорошо пишу!»;
  • «не обращайте внимания на предупреждения компилятора – это бета-версия»;
  • «конечно, я знаю, что файлы надо закрывать»;
  • «я торопился, поэтому не вынес этот метод в отдельный модуль. Ну и что, что он 5 раз встречается в разных местах, это мелочи»;
  • «ну я же торопился, потому так и написал. А вообще я хорошо пишу!»;
  • «да я как-то привык на транслите писать»;
  • «вот, для запуска нажмите кнопку с надписью «Button1».

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

  • «эта кнопка для отработки особого случая»;
  • «к сожалению, руководство пользователя не успел дописать»;
  • «конечно, тестировал — вот, смотрите»;
  • «да, и в этом случае тоже работает, я проверял».


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

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