Учебный код и серьёзный код

[zHz00]

Все мы когда-то писали кривой код на лабах по программированию. А кто-то такой код пишет до сих пор по работе.

Учебный код должен выполнять то задание, которое написано на листочке, и его он должен выполнять без ошибок. Если при разрешённых входных данных получается чушь, это должно быть исправлено.

Но что делать с запрещёнными входными данными? Я полагаю, что учебные программы имеют право работать некорректно, если пользователь попрыгал по клавиатуре или нажал кнопки не в том порядке. Потому что смысл упражнения не в том, чтобы сделать законченный продукт. Задача лаб в том, чтобы студент понял ту или иную концепцию и применил её на практике.

Сейчас я пытаюсь вспомнить, требовал ли я от студентов жёстких проверок на всех этапах работы программ или нет? Вроде не требовал. Но если даже требовал тогда, то сейчас моё мнение такое, как я написал выше.

Если, конечно, студент сам захотел и сделал все проверки -- то это замечательно. Потому что такой код уже может считаться серьёзным.

Серьёзный код -- это такой, который корректно отрабатывает все разрешённые взаимодействия с пользователем. Программа может падать, если пользователь покопался в настроечных файлах -- это он сам виноват. Но программа не может падать, если пользователь не там пощёлкал мышкой.

Я не знаю, как принято в современной методологии разработки ПО. Я вижу только то, как делаются проекты у нас на работе и в соседних организациях. А происходит вот что. Любой код начинается как учебный, и сначала пилится основная часть, которая правильно работает при правильных действиях пользователя.

А вот когда это заработало, начинают делать защиту от оператора, от стихийных бедствий и от кота. Это-то и переводит учебный код в серьёзный.

Comments

[Foul thing]

У нас говорят, что давай сначала сделаем Happy path - когда весь процесс от начала до конца работает, если пользователь все делает правильно и все остальные компоненты отрабатывают штатно. Получается рабочий прототип. А уж потом он обвешивается всем остальным.

[Гость]

На олимпиадах в школьные годы давали много балов за хорошую фильтрацию неверных данных, увы(

[e1_huev0]

Я не знаю, как принято в современной методологии разработки ПО. Я вижу только то, как делаются проекты у нас на работе и в соседних организациях. А происходит вот что. Любой код начинается как учебный, и сначала пилится основная часть, которая правильно работает при правильных действиях пользователя.

бизнес-цели как правило имеют высший приоритет, чем качество продукта, хотя бы потому что иначе бизнес не будет считать затраты на получение прибыли оправданными и платить зарплату
вторая причина это неясность того, как наилучшим образом должен выглядеть результат для пользователя/бизнеса, что приводит к частому реинжинирингу, а это делать проще с прототипом

[zHz00]

Foul thing, e1_huev0, ага, т.е. это распространённая практика. Вы меня успокоили.
Гость, про олимпиадное программирование я знаю крайне мало. Я только слышал, что там проверки задач идут автоматически, поэтому можно заработать прилично баллов по задаче, если решить её в простых случаях или решить наполовину.