Комментарии 43
Ваш подход вызывает аналогию с обучением плаванию.
Кинули пока не умеющего плавать человека посреди километрового пролива и сказали «плыви». Мол когда придёт время в реальности плыть вы столкнётесь с тем же окружением и теми же проблемами. Отсюда вытекает вполне логичный вопрос: а нафига нужно такое обучение?
Так вот, обучение так не работает. Вы не даёте человеку возможность учится думать, хотя цели у вас именно такие. Потому что для новичка сам процесс поиска ошибки при известных входных данных — это уже обучение. А когда вы в самом начале пути начинаете топить, то все силы и стремления тратятся на преодоление бессмысленного стресса.
Аргументы ваших сотрудников которые топят за то чтобы не показывать входные данные напоминают дедовщину, мол мы в своё время были в таких условиях, теперь и вы терпите.
Я правильно понимаю, что вы хотели сгладить негатив после недавней критической статьи? Мне кажется что наиболее эффективно было бы сделать работу над ошибками и публично об этом рассказать, а не просто в очередной раз, другими словами рассказывать про проект.
Мне кажется что наиболее эффективно было бы сделать работу над ошибками и публично об этом рассказать
Ээээм, но у чуваков же в публичном посте
Кинули пока не умеющего плавать человека посреди километрового пролива и сказали «плыви». Мол когда придёт время в реальности плыть вы столкнётесь с тем же окружением и теми же проблемами. Отсюда вытекает вполне логичный вопрос: а нафига нужно такое обучение?
Если я правильно поняла, то ваш комментарий относится к закрытым тестам. Тут не могу согласиться с вашей аналогией про жесткое обучение плаванию. Открытие тестовых кейсов — не единственный способ помочь студентам. Мы подробно рассказываем, что делать, если код не работает, какие подходы стоит попробовать.
К тому же есть несколько человек, к которым можно обратиться за помощью, если что-то не получается, они всегда помогут и могут даже выдать тест, если это кажется целесообразным.
Я правильно понимаю, что вы хотели сгладить негатив после недавней критической статьи? Мне кажется что наиболее эффективно было бы сделать работу над ошибками и публично об этом рассказать, а не просто в очередной раз, другими словами рассказывать про проект.
Что касается работы над ошибками – именно о ней мы и рассказали. В недавней критической статье был описан случай из сентября 2020 — ошибки того времени мы уже исправили, и об этом рассказываем в посте.
Да, действительно, я не возвращался к перечитыванию комментариев. Спасибо за проделанную работу. Хотя я бы на вашем месте сослался на комментарий или исходную статью с критикой, мол поступали негативные отзывы которые подтолкнули нас к решительным действиям.
Я субъективно считаю, что сложившаяся ситуация достаточно типична для многих крупных продуктовых компаний. Очень хорошо, когда кто-то вмешивается и радикально подходит к решению вопроса. Но нередки ситуации, когда на конечных пользователей забивают болт и продолжают тупо грести деньги. И будучи рядовым разработчиком у меня не было ни инструментов ни желания чтобы переть против руководства, которое считало что +- пару недовольных клиентов всегда будут.
Резюмирую насчёт тестов. Если я правильно понял, то в какой-то момент подключается куратор. Которому должно быть достаточно одного взгляда на набор входных данных, чтобы понять в чём ошибка. Так вот, не обязательно сразу раскрывать непосредственно данные, а в индивидуальном порядке намекнуть, мол у вас нет проверки на отрицательные числа. И только через некоторое время, если уж совсем никак, открыть входные данные. По идее это не будет слишком дорого в плане временных затрат ваших сотрудников, которые работают с клиентами.
А ещё можно сделать жирную надпись типа «Вы действительно хотите увидеть входные данные? Выражая своё согласие вы подтверждаете то, что ничему сами не научитесь». Всё таки это не массовый школьный экзамен, а люди идут к вам осознанно за определёнными навыками.
Так и происходит. Наставник смотрит на тест, на код и пытается навести на мысль о том, что могло пойти не так. Иногда может задать наводящий вопрос. Иногда может прокомментировать ошибку в коде программы, когда проблема не связана с основным алгоритмам, а касается каких-то частностей. В редких случаях может выдать тест. Ещё бывает, что наставник придумывает сходный тестовый пример и обсуждает со студентом, как программа будет работать на нём. Всё зависит от конкретной задачи и конкретной ошибки.
Это вообще феерически, когда ответ верный, получен он не той функцией, что ожидал автор задачи, поэтому задача валится с неинформативной ошибкой, а саппорт через чат в ответ на критику просто даёт «правильный ответ». Или когда у вас полуфабрикат кода на 50 строк, где в случайных местах «недописаны строки» (и не везде по комментариям в коде понятно, что там что-то надо дописать", а в описании задачи вообще написано «постройте гистограмму», ничего про дописки нет.
Отдельная боль — то что разные уроки сделаны разными людьми. Поверьте, это очень бросается в глаза. Подходы очень разные были у людей. Где-то кода минимум, где-то простыни, где-то надо делать функцию, а где-то выводить в STDOUT.
И в том после, МНЕ КАЖЕТСЯ, основная претензия была именно к отношению со стороны компании, а не к технической реализации. И публикуя пост какие вы молодцы, вы лишь подтверждаете точку зрения автора предыдущей статьи.
P.S. не подумайте, что мне не нравится Яндекс.Практикум. На фоне той дичи, что сейчас на рынке творится, у вас один из лучших продуктов. И при его объёме очень сложно сохранить планку, это я прекрасно понимаю. Вы делаете важное и нужное дело.
По поводу вариативности принимаемых решений в тренажере, мы постоянно пытаемся улучшать качество проверок. Действительно, на старте программы в большинстве задач были жёсткие критерии проверки, которые предполагали строгое соответствие авторскому решению. Сейчас мы изменяем наши проверки на парсинг AST (Abstract Syntax Tree), это позволяет нам сделать проверку более гибкой, а также лучше понимать где ошибается студент, чтобы выдавать более точную подсказку. В большинстве курсов проверки уже модернизированы.
Уроки действительно пишутся разными авторами. Это позволяет нам подбирать для конкретной темы эксперта, который наиболее полно раскроет её, учитывая свой профессиональный опыт. Сильный разброс по стилическому оформлению появляется где-то начиная с курса «Анализ бизнес-показателей». Это связано с тем, что с увеличением сложности курса всё меньше шаблонных вариантов решения задачи. Например, не существует единого подхода к оценке результатов A/B-тестирования с помощью Python.
Про отношение компании к студентам:
Помимо команды, которая занимается разработкой и поддержанием программы, есть те, кто сопровождает студентов, то есть помогает и заботится. Кураторы, наставники и преподаватели отвечают на вопросы по теории или практике, разбираются с ошибками или сложностями в тренажере и дают мощную поддержку всем, кому она необходима. Команда сопровождения собирает и передаёт обратную связь и ускоряет решение любых спорных ситуаций студентов полной программы. Однако у нас есть партнёрства с университетами, где нет необходимости в наших преподавателях и кураторах, от чего может сложиться не совсем корректное мнение про отношение со стороны компании и команды школы. Поправьте, если мы ошиблись, но вы учились/учитесь на подобной программе. Если у вас есть недовольства или вопросы к устройству курса — свяжитесь с нами через службу поддержки Практикума, мы стараемся помочь каждому, кто к нам обращается.
P.S. У меня не недовольство, я же выше написал, на мой взгляд это проблемы, которые у практикума есть, но в целом продукт очень крутой. Я его нескольким людям рекомендовал вполне искренне (хотя и предупредил о ряде проблем). И мне к счастью, помощь не нужна была за исключением нескольких досадных ситуаций (например как-то раз решал пункт задачи «через один», а грейдер мне всё твердил, что я не то вывожу, ну так сам дурак, всё верно). Мне бы хватило и форума с однокурсниками как на курсере, чтобы не нагружать вендора, но, у счастью, у меня есть бэкграунд. ;-)
И это очень распространенная ошибка.
Вот типичный случай " возьмем пространство признаков и тогда каждая выборка будет представлять собой вектор" — и далее линал полным ходом. Но вот на простой вопрос — с чего это вдруг это пространство этих признаков обладает метрикой, сложением и прочими свойствами? Ответа нет — на курсах это нигде не преподают, ни на каких. А вот по линалу нахвататься формул можно достаточно просто.
Стоит ли открывать тест-кейсы?
Реально какая-то двойственная штука.
А не думали как-то дополнять задачи? Допустим, юзер загрузил свое решение, система говорит ему «Обломись», и тут у юзера выбор.
1. Пойти и реверсить свой код, чтобы самому понять, что там и где не так.
2. Нажать кнопку «Показать, где накосячил», но при этом система тебе на зачтёт эту задачу, а даст вместо нее новую, по той же теме. И вот она уже учитывается.
То есть когда ты понимаешь, где ты архитектурно косячишь и на что обращать внимание при создании кода, а не просто «Ошибка на строке 10 — исправь, будет ОК».
Или такое тоже будет слишком жёстко и завалит студентов задачами?
Сходу видно несколько сложностей в реализации:
1) Платформа не умеет предлагать новую задачу в ответ на неудачную попытку, и вообще гибкости не так много: либо открыть все тесты, либо все закрыть.
2) Нужно решить сколько таких попыток давать человеку и сделать соответствующее кол-во задач на каждую тему. Это уже попроще, чем первый пункт, но всё равно требует времени.
Ну и вижу некоторый минус в том, что изначальная задача останется нерешенной. В этом смысле лучше уж открыть один текст-кейс по запросу, предварительно убедившись, что человек уже попробовал предложенные нами подходы по поиску бага.
В любом случае спасибо за идею, любые такие предложения заставляют лишний раз подумать и может быть в итоге придумать что-то классное.
Для каждой задачи описаны условие и формат входных и выходных данных
Зачем это нужно? Литкод прекрасно обходится без этого, не заставляя заниматься вводом/выводом.
На текущий момент мы придерживаемся мнения, что это тоже прокачивает скилл и готовит к реальной жизни. Ведь в реальных задачах у вас в лучшем случае будет лишь внешнее проявление бага, но не всегда будет понятно, где его искать.
Это болтология. В реальной жизни баг (почти) всегда можно воспроизвести на известных входных данных. Опять же, литкод прекрасно показывает тест, на котором случился TLE или для которого дан неверный ответ. Но у вас свой, особенный, путь, да.
Все это выглядит так, что у вас есть какой-то апологет хардкорного олимпиадного программирования, который и продавил все эти решения, не нужные и вредные для большинства обычных людей, которые пришли учиться. Точно ваши курсы никому советовать не буду, они не про обучение.
В реальной жизни нужно ещё заметить, что баг произошёл. И, если он произошёл давно, то с вероятностью, воспроизвести его уже никак не получится.
Представьте себе, что вы разрабатываете базу данных и сажаете баг, который проявляется в очень редких случаях, но при этом портит данные.
По-моему все-таки "У вас в коде ошибка" — это не особенно похоже на реальность. В реальности мы знаем хоть что-то об ошибке — как она проявляется, в чем она заключается, при каких условиях, почему ее надо исправлять.
Не бывает же так, что начальник просто приходит и говорит "поправь код" и уходит.
И чего плохого в том, что люди будут просто подгонять код так, чтобы он проходил тесты? Если тест можно пройти с помощью подгона, то он плохо написан, недостаточно подробен или недостаточно въедлив.
Так же, как в TDD — мы пишем ровно столько кода, сколько необходимо для прохождения тестов :)
Добавлю еще, что ошибки, вызванные неверным пониманием условий задачи или неверным разбором входных данных, становятся неотличимы от ошибок в алгоритме. А сформулировать условия так, чтобы их абсолютно все с первого раза правильно понимали — скорее всего невозможно.
И сидит потом студент над алгоритмом, ищет ошибку, которой в нем нет. А на самом деле входные данные — символы, а не числа или типа того.
В реальности это сразу было бы в отладчике видно, а тут только угадывать, что там авторы имели в виду под "на вход подаются числа", условно говоря.
Ну или писать в поддержку и тратить дорогостоящее время ваших специалистов.
Но у вас же все-таки курс по алгоритмам, а не по юнит-тестированию?
Я в первую очередь говорю, что в реальной жизни проблемы себя так не проявляют, есть хоть какой-то симптом, хоть какой-то способ понять, в чем дело. Закрытый тест-кейс — это буквально "пойди туда, не знаю куда, найди то, не знаю что".
В реальности я не буду сидеть и просто медитировать над кодом, пытаясь понять, что не так, по крайней мере не в первую очередь! Я буду вставлять отладочную печать, читать логи, запускать анализаторы, выполнять код по шагам, буду изолировать проблемное место.
Тем не менее, и мои и ваши аргументы явно основаны на личных предпочтениях. Было бы здорово, если бы мы могли их как-то более весомо подкрепить.
Не попадались ли вам какие-нибудь исследования на эту тему? Можно ли ввести какие-то объективные метрики? Хотя бы, не знаю, сравнить несколько групп с закрытыми и с открытыми тестами.
Еще, кстати, момент — а вы студентам-то в самом курсе объясняете, почему тесты закрыты?
В реальности я не буду сидеть и просто медитировать над кодом, пытаясь понять, что не так, по крайней мере не в первую очередь! Я буду вставлять отладочную печать, читать логи, запускать анализаторы, выполнять код по шагам, буду изолировать проблемное место.
Остается только повторить Ваш вопрос: это курс по алгоритмам?
Вы считаете, что алгоритмы можно понять только с помощью медитации над кодом, а не с помощью отладки?
Баг может проявлять себя только через несколько часов работы с потоком данных в пару сотен мегабит.
Или стрелять раз в месяц ночью.
Или быть в дебрях фьючер библиотеки и проявляться при хитрых условиях недоступности чего-либо внешнего что до этого было доступным.
Да и обычную гонку в непростом коде дебаггером не поймать.
А уж во всяких микросервисах которые имеют привычку стартовать и стопится не моментально и иногда оставлять следы своей прерванной работы столько красоты бывает.
Это все реальные случаи из моей практики.
Навык ловить баг без отдладчика полезный. Не для джунов, конечно. Им рано.
Но у вас же все-таки курс по алгоритмам, а не по юнит-тестированию?
Тестирование на наш взгляд — важная часть обучения алгоритмам.
Если не умеешь реализовывать алгоритм так, чтобы код работал — значит не научился алгоритмам (в нашем понимании).
Чтобы писать рабочий код, надо уметь его тестировать, видеть разные кейсы.
Так что не вижу больших проблем в том, чтобы тренировать навык тестирования в курсе по алгоритмам. В конце концов, студенты приходят к нам за навыком, а не за «лёгкими» галочками напротив задач.
И да, конечно мы рассказываем им почему тесты закрыты и подробно объясняем что нужно делать, если не получается побороть тест.
И да, конечно мы рассказываем им почему тесты закрыты и подробно объясняем что нужно делать, если не получается побороть тест.
Это хорошо!
Тестирование на наш взгляд — важная часть обучения алгоритмам.
Если не умеешь реализовывать алгоритм так, чтобы код работал — значит не научился алгоритмам (в нашем понимании).
Чтобы писать рабочий код, надо уметь его тестировать, видеть разные кейсы.
Тем не менее я не вижу в этом прямой корреляции с закрытыми тестами.
С вашего позволения, я повторю свои аргументы все в одном месте.
- Закрытые тесты не позволяют отделить ошибки в алгоритме от ошибок в разборе входных данных или от "неправильного" прочтения задания, которое почти неизбежно в определенном проценте случаев.
- Закрытые тесты означают, что ваши наставники тратят больше времени на общение со обучающимися, разъясняя вещи, которые можно было бы просто увидеть в результатах тестов (т.е. буквально выполняют работу машин). Время ваших сотрудников, которое оплачивает ваша компания!
- Закрытые тесты скорее всего приводят к большей фрустрации учащихся и к большему уровню недовольства курсом в целом. Понятно, что ваша цель — научить людей алгоритмам, но как знать, сколько из них бросают это дело, потому что "аргх ничего непонятно опять ошибка!"?
- Закрытые тесты не похожи ни на реальное программирование, ни на реальное самостоятельное написание тестов. Неясно, действительно ли они помогают научиться тестировать код, по крайней мере курсы или книги по юнит-тестированию вроде бы такое не практикуют массово?
- Непонятно, приводят ли закрытые тесты к лучшему или худшему уровню понимания алгоритмов или программирования в целом (мне исследований на такую тему не попадалось, но мб я плохо искал). Тем не менее, можно в рамках вашего же курса это проверить — учащихся много, вполне можно устроить небольшое исследование.
- Вероятно, открывать тесты по желанию учащегося было бы разумным компромисом (типа, нажать на кнопочку и согласиться с предупреждением). По факту вы ведь сейчас так и делаете! Только с привлечением живого человека, которому, опять же, нужно оплачивать его время, который не может ответить всем сразу, который мог бы отвечать на более интересные вопросы. А учащийся должен ждать этого ответа какое-то (полагаю, не очень малое) время, что тоже усиливает фрустрацию.
Лично я проходил несколько курсов (в т.ч. 3 или 4 по алгоритмам так или иначе) — тесты везде были открыты. В одном даже вместе с заданием выдавалась пачка тестовых кейсов, которые можно было запускать локально.
На мой субъективный взгляд — это были лучшие курсы с лучшими преподавателями, которые я в жизни видел. Подогнать код под ответ было невозможно, потому что реальные тесты содержали гигантские входные данные, это было проще сделать правильно, чем подогнать!
Видел я и один курс с закрытыми тестами, его я проходить до конца не стал, потому что это выбешивало. В паре заданий прокатило считерить и сдампить тестовый вывод — оказалось, что задание было сформулировано странно я неправильно понял задание.
Соответственно весь мой опыт восстает против закрытых тестов, но опираться только на свой опыт — неправильно. Вероятно опыт ваших сотрудников говорит об обратном.
Поэтому было бы здорово как-то объективно сравнить результаты.
Во-первых, считаю важным проговорить, что вопрос с тестами не решен для нас окончательно, этот пост — один из способов найти истину. Так что дальше прошу рассматривать мои ответы не как попытку отказаться от любого открытия тестов, а как искренние контраргументы.
Закрытые тесты не позволяют отделить ошибки в алгоритме от ошибок в разборе входных данных или от «неправильного» прочтения задания, которое почти неизбежно в определенном проценте случаев.
Да, но ведь ошибки нужно минимизировать в любом коде, не важно, сложный это алгоритмический код или чисто техническая штука. Любой код полезно писать максимально чисто.
Закрытые тесты означают, что ваши наставники тратят больше времени на общение со обучающимися, разъясняя вещи, которые можно было бы просто увидеть в результатах тестов (т.е. буквально выполняют работу машин). Время ваших сотрудников, которое оплачивает ваша компания!
Нам кажется что сценарий
«Тест упал -> иду к наставнику -> наставник задаёт вопрос о логике моего алгоритма/советует вспомнить про краевые случаи -> я отвечаю на вопросы или следую советам наставника, сама додумываюсь до проблемы в коде»
лучше, чем сценарий
«Тест упал -> я взяла тесткейс, нашла в коде баг, поправила, отправила в систему опять»
Несложно заметить, что во втором сценарии я гораздо меньше думаю. Студенты, которые ошибаются и проводят плодотворную работу над ошибками вместе с наставниками, по-моему, лучше и быстрее “набьют руку”. Безусловно, это непростой путь, но он точно результативный.
Закрытые тесты скорее всего приводят к большей фрустрации учащихся и к большему уровню недовольства курсом в целом. Понятно, что ваша цель — научить людей алгоритмам, но как знать, сколько из них бросают это дело, потому что «аргх ничего непонятно опять ошибка!»?
За этим мы следим, стараемся помогать тем, кому сложно. Человек никогда не уходит от нас незаметно, так что все такие случаи известны и посчитаны
Закрытые тесты не похожи ни на реальное программирование, ни на реальное самостоятельное написание тестов. Неясно, действительно ли они помогают научиться тестировать код, по крайней мере курсы или книги по юнит-тестированию вроде бы такое не практикуют массово?
Мы считаем, что да, помогают, это консенсус многих преподавателей и программистов, с которыми мы обсуждали курс.
Наверное, чтобы доказать это или опровергнуть раз и навсегда, нужен эксперимент. Подумаем, как его устроить, чтобы не напугать студентов :)
Непонятно, приводят ли закрытые тесты к лучшему или худшему уровню понимания алгоритмов или программирования в целом (мне исследований на такую тему не попадалось, но мб я плохо искал). Тем не менее, можно в рамках вашего же курса это проверить — учащихся много, вполне можно устроить небольшое исследование.
Опять же, не могу привести исследование сейчас, но думаю, устроим что-то подобное вместе со студентами, которые будут не против.
Вероятно, открывать тесты по желанию учащегося было бы разумным компромисом (типа, нажать на кнопочку и согласиться с предупреждением). По факту вы ведь сейчас так и делаете! Только с привлечением живого человека, которому, опять же, нужно оплачивать его время, который не может ответить всем сразу, который мог бы отвечать на более интересные вопросы. А учащийся должен ждать этого ответа какое-то (полагаю, не очень малое) время, что тоже усиливает фрустрацию.
Мы думаем в сторону того, чтобы дать подсмотреть «по кнопке» несколько тестов. Большинство тестов всё равно довольно объемные и их открытие вряд ли сильно поможет.
Спасибо, что участвуете в обсуждении и предлагаете варианты, нам это важно.
Очень основательный ответ, приятно читать!
В свою очередь рад, что вы вообще идете на обсуждение :)
Да, но ведь ошибки нужно минимизировать в любом коде, не важно, сложный это алгоритмический код или чисто техническая штука. Любой код полезно писать максимально чисто.
Верно, но очень уж обидно тратить целый день на идиотскую ошибку в парсинге, когда вообще непонятно, в чем же ошибка заключается!
Я вот представляю, что я студент-новичок — и реально не знаю даже, с чего начинать-то? В какую сторону думать? Каждую строчку перебирать?
Нам кажется что сценарий
«Тест упал -> иду к наставнику -> наставник задаёт вопрос о логике моего алгоритма/советует вспомнить про краевые случаи -> я отвечаю на вопросы или следую советам наставника, сама додумываюсь до проблемы в коде»
лучше, чем сценарий
«Тест упал -> я взяла тесткейс, нашла в коде баг, поправила, отправила в систему опять»
Несложно заметить, что во втором сценарии я гораздо меньше думаю. Студенты, которые ошибаются и проводят плодотворную работу над ошибками вместе с наставниками, по-моему, лучше и быстрее “набьют руку”. Безусловно, это непростой путь, но он точно результативный.
Вот не факт, не факт. В первом варианте у человека буквально нет выбора, кроме как обращаться за помощью к наставнику. Поможет ли это думать — сильно зависит от человека, далеко не всем приятно сразу "признавать поражение" и просить чужой помощи. Не воспитает ли это рефлекс "чуть что сломалось — беги к старшему"?
В случае открытого теста думать, скорее всего, то же придется — если ошибка в алгоритме и если она не глупая опечатка, то придется придумывать, что с ней делать.
Можно так же возразить, что при этом у студента не будет ощущения, что ему помогали, нет, он всё сам!
За этим мы следим, стараемся помогать тем, кому сложно. Человек никогда не уходит от нас незаметно, так что все такие случаи известны и посчитаны
Это само по себе очень хорошо, но не лучше ли предотвратить страдания, а не "заглаживать вину" постфактум?
Мы считаем, что да, помогают, это консенсус многих преподавателей и программистов, с которыми мы обсуждали курс.
Наверное, чтобы доказать это или опровергнуть раз и навсегда, нужен эксперимент. Подумаем, как его устроить, чтобы не напугать студентов :)
Как видите, здесь в комментариях довольно много людей с противоположным мнением :) Возможно, что ваш консенсус — это следствие confirmation bias и каких-то других групповых когнитивных искажений типа пузыря фильтров? Или еще каких-то умных слов, которыми я пытаюсь сказать, что люди с одинаковым мнением стремяться общаться только друг с другом и соглашаться друг с другом, тем самым укрепляясь в своем мнении.
Опять же, не могу привести исследование сейчас, но думаю, устроим что-то подобное вместе со студентами, которые будут не против.
Отлично :) Надеюсь, что если устроите, то опубликуете результаты!
Мы думаем в сторону того, чтобы дать подсмотреть «по кнопке» несколько тестов. Большинство тестов всё равно довольно объемные и их открытие вряд ли сильно поможет.
Если тесты объемные, то странно, что вы боялись "подгона под ответ"…
Вообще же даже объемные можно предлагать скачать как файл, например, чтобы студент мог локально потестить, было бы желание.
Спасибо, что участвуете в обсуждении и предлагаете варианты, нам это важно.
Пожалуйста :)
Но получается, что тут смешивается 2 вектора: научить алгоритмам и научить тестированию, отладке, дебагу кода. Надо и то и то, но это разные курсы могут быть. Тестирование вообще является отдельным направлением зачастую.
Я бы точно не стал покупать у вас этот практикум, зная, что тесты скрыты. Одно дело когда ты студент, готовишься к ICMP, у тебя горят глаза, и тебе важно прокачать "чуйку". И совсем другое дело, когда времени в обрез, дедлайны, учишь языки, отвозишь ребёнка в школу и назад и т.д… В этом случае ты покупаешь подписку на литкод не для того, чтобы "прокачать чуйку", а чтобы быстро закрыть наиболее ключевые дырки и пойти проходить собес в FAANG. И вот спрашивается на кой чёрт мне эти ваши многочасовые выискивания того, что я, оказывается, забыл обработать какой-то хитрый кейс с переполнением, с -1, или сочетанием более редких факторов. Это ведь всё ещё и за деньги. В общем noway.
То что эти "хитрые кейсы" многочасовые я знаю доподлинно. В бытность студентом я мнооого времени потратил, пытаясь понять, какой же такой кейс я не покрыл. Думаю КПД этого времени было в р-не 5-10%. Всё равно спустя 10 лет я нахожу баги совсем не тем способом, которым пытался найти их тогда.
Мне кажется ответ на ваш опрос в конце строки зависит от аудитории вашего продукта. Если это уже состоявшиеся программисты, то им ваши "принципы" глубоко-фиолетовы и они, взрослые дяди и тёти, сами разберутся, как им учиться. А если студенты или вообще подготовка к олимпиадам, то тут становится всё сложнее. Стоит спросить их напрямую.
Для большей дружелюбности и смещению фокуса именно на алгоритмы, а не программирование почему бы не давать уже написанный код ввода-вывода? Когда у тебя есть уже входные данные, можно сосредоточиться на задаче, а не думать, как оптимальнее считать с диска или консоли (в реальной жизни это тоже довольно редко встречается).
Да, тут потеряется челендж по придумывантю какого-то необычного способа считать данные, чтобы сэкономить и на этом, но это уже продвинутый уровень, а не базовый, на который вы ориентируетесь.
Отдельные задачи «на смекалку» могут иметь нетиповые скрытые тесты, но надо сразу готовиться, что учащихся будет «бомбить» и в задаче эта «подстава» должна быть как-то обоснована.
Иногда тест нельзя сделать публичным потому, что он просто «не влезет» (например, проверка на какие-то свойства очень больших чисел, там важно эффективно использовать память и время, но они и на экран могут не влезть). Надо в таком случае дать возможность или «скачать» тестовые данные, либо объяснить как их сконструировать самостоятельно.
Да, видимо нам стоит как-то в эту сторону двигаться, учиться показывать часть тестов.
P.S. А вы не думали для Тренажёра и Контеста написать плагины для популярных IDEшек, как например один ресурс по обучению Java сделал с IntelliIDEJ — то есть решаются задачи с сайта, но в IDE.
Слабо, просто, в стиле ODS замутить и выложить какой-нибудь бесплатный курс на Хабр? С точно такой же проверяющей системой в гугл… яндекс-формах :)
На мой взгляд тут 2 проблемы:
1. В задание очень мало уделяется формату вывода. Приходится экспериментально выяснять где надо добавить переход на следующую строку, где в конце строки должен обязательно стоять пробел (зачем?...), где не должен. А где программа ничего не должна выводить (а в прошлом задании должна была). При том несовпадение в любом символе сразу бракует всю задачу. Вывел лишний символ — сразу 0 тестов из 25. Убрал — все прошло.
2. Не всегда студент может понять, что конкретно требуется в задаче. Все-таки это обучение. Опять же описание задач в курсе оставляет желать лучшего. В результате студент сделал задачу, даже покрыл ее тестами и все они проходят. Но система говорит «неправильно». И студент не может найти ошибку, потому что он решил не совсем ту задачу, которую ожидает система.
Поэтому я считаю, что тесты должны быть из 2 частей:
1. Открытые, которые позволят проверить «а ту ли задачу решает студент» (а заодно «а в том ли формате он выводит результат»). Самые базовые случаи, без обхвата какими-либо граничными условиями, большими числами и прочими изощрениями
2. Закрытые. Вот здесь как раз должен быть большой охват возможных значений, быть проверены и граничные условия, и большие числа и все остальное.
Такой подход, на мой взгляд, и даст студенту понимание на правильном ли он пути, но и не даст подогнать решение под тесты
Что вас на самом деле ждёт на курсе про алгоритмы в Яндекс.Практикуме