Блог пользователя izbyshev

Автор izbyshev, 15 лет назад, По-русски
В школьных командах постоянно возникают проблемы, связанные с организацией работы в команде и общей стратегией. Часто контест проходит "как получится", решения принимаются неосознанно и т.д. Конечно, если это восьмиклассники, это не сильно удивительно, но обучать их всё-таки надо.
Андрей Акиньшин и я решили составить заготовку плана, по которому школьники должны продумать и описать работу в своей команде. Я предлагаю вместе обсудить, дополнить и откорректировать эту заготовку, чтобы она превратилась в нечто разумное. Пока это всего лишь некий сборник правил и советов.
Обращаю особое внимание на то, что в основном план предназначен для не очень опытных команд, составленных из школьников, поэтому, пожалуйста, вспомните то счастливое время, когда будете комментить:)

План описания работы команды:

  • Стратегия
    • Части контеста
      • Старт контеста
        Подумать:
        • Кто пишет заготовку?
        • Кто читает задачи?
        • Кто пишет первую задачу?
        Учесть:
        • Начало контеста должно быть максимально быстрым
        • Желательно подготовить TaskList
        • Следить за монитором: какая задача будет сдана первой
      • Середина контеста
        Учесть:
        • По-хорошему решённые задачи должны опережать кодера. Недопустима ситуация, когда кодер закончил всё кодить, а новых задач для него нету.
        • Обновляем TaskList. Должна быть составлена более или менее чёткая стратегия на остаток олимпиады.
        • Продолжаем следить за монитором. Пытаемся корректировать работу в соответсвии с наиболее популярными задачами.
      • Конец контеста
        Подумать:
        • За сколько времени до конца бросаем все силы на единственную задачу
        Учесть:
        • Нельзя в самом конце распыляться на несколько задач.
    • Распределение ролей
      Для каждой роли расписать всех трёх участников по приоритетам
      • Капитан
      • Кодер
      • Алгоритмист
      • Математик
      • Тестер
      • Наблюдатель за кодером
    • Распределение специализаций - выделить для каждого вида алгоритмов, кто из участников лучше всех может написать программу
      Специализации:
      • Теория графов
      • Алгоритмы на строках
      • Геометрия
      • Математика
      • Динамика
      • Теория игр
      • Комбинаторика
      • Структуры данных
      • Длинная арифметика
    • Порядок тестирования - определить основные виды тестов, составить таблицу - в какой ситуации какие тесты нужно использовать
      Группы тестов:
      • Минимальные тесты
      • Вырожденные случаи
      • Максимальные тесты (в крайнем случае для них пишется генерилка)
      • Граничные
      • Рандомные
      • Тесты, проверяющие конкретные случаи в задаче
      Группы тестов для задач на графы:
      • Граф из нуля вершин
      • Граф из одной вершины
      • Граф из двух вершин
      • Полный граф
      • Пустой граф
      • Полный граф без одного ребра
      • Граф с одним ребром
      • Граф, в котором все вершины выстроены в цепочку
      • Граф, в котором вершины замкнуты в кольцо
      • Рандомный граф
      • Граф, состоящий из нескольких компонент связности
      Группы тестов для задач, в которых есть двумерные массивы:
      • Неквадратный двумерный массив (n <> m)
      • Массив, состоящий из одинаковых элементов
      • Массив, состоящий из разных элементов
    • Действия в типовых ситуациях - подробное описание действий каждого из участников, последовательность действий.
      • Придумывать больше нечего, а компьютер занят.
        • Продумать основную логику следующих для решения задач на бумажке
        • Составить тесты
        • Ещё пописать тесты
      • Отосланное решение упало на первом тесте. Что надо делать?
        • Проверить, что при отправке задача была выбрана правильно
        • Проверить, что входные и выходные файлы в решении названы правильно
        • Внимательно проверить формат вывода - возможно, где-то не хватает пробела или перевода строки
      • Получили Wrong Answer. Что надо делать?
        • Быстро просмотреть код
        • Прогнать программу на тупых тестах
        • Если с ходу не понятно в чём ошибка - распечатать решение, отдать компьютер под другую задачу
      • Получили Time Limit. Что надо проверить?
        • Не зависают ли циклы
        • Недостаточно оптимизированный алгоритм
        • Неверный алгоритм, нужно более оптимальное решение
      • Получили Presentation Error. Что надо проверить?
        • Формат вывода
      • Получили Runtime Error. Что надо проверить?
        • Выход за границы массива
        • Деление на ноль
        • Корень из отрицательного числа
        • Тригонометрические функции, взятые от некорректных значений
        • Бесконечная рекурсия
        • Кривое чтение
      • Получили Output Limit. Что надо проверить?
      • Получили Memory Limit. Что надо проверить?
        • Проверить выделение памяти под массивы
        • Проверить рекурсию
      • Никак не можем найти ошибку. Что надо проверить?
        • Проверить типы данных
        • Зануление переменных
        • Правильность индексов при обращении к массивам
        • Обратить внимание на Warning'и
        • Проверить чтение и вывод данных
        • Границы массивов и соблюдение этих границ в программе
        • Прочитать условие задачи ещё раз. Возможно, это имеет смысл сделать человку, не участвовавшему в решении
        • Рассказать ключевые моменты решения остальным членам команды
  • Описание существующих проблем
    • Проблемы, связанные со знанием алгоритмов
    • Проблемы, связанные со стратегией
  • Стандарт стиля кода
    • Отступы
    • Cтандартные названия для процедур и функций
    • Cтандартные названия для переменных
      • Названия для массивов в зависимости от назначения
      • Названия для переменных некоторого конкретного назначения
    • Стиль для объединения в названии нескольких слов
      • Употребление подчёркиваний
      • Употребление заглавных букв
      Хорошие примеры:
      • stackSize
      • stack_size
      • StackSize
      Плохие примеры:
      • stacksize
      • STACKSIZE
      • stackSIZE
      • stsz
      • sizeofmygoodstack
    • Cтандартные кодерские фичи
  • Расписание тренировок
    • Расписание тренировок на неделю
    • Тематические тренировки
    • Наборы задач для тренировок
  • Проголосовать: нравится
  • +18
  • Проголосовать: не нравится

15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
"Нельзя в самом конце распыляться на несколько задач."

Опыт нашей команды говорит об обратном. Например, сегодня на opencup'е запихнули в последние десять минут две задачи) 
  • 15 лет назад, # ^ |
      Проголосовать: нравится +12 Проголосовать: не нравится
    По нашему опыту, такие удачные концовки происходят раз в 100 лет, а в большинстве случаев решение вести две задачи до последнего приводило к несдаче обеих :)
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Ну, я думаю, тут дело ещё и в том, что у вашей команды в конце редко остаётся много подъёмных задач) А вот у команд среднего уровня - всегда)
    • 15 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      На моей практике это обычно приводило к сдачи той из 2 в которой меньше багов и что самое обидное отладки второй минут через 10 после конца. Хотя в принципе хороший вопрос стоит ли бросать уже написанную задачу когда за некоторое время до конца осталось 2 не отлаженных или лучше распечатать одну из них и чтобы один из 3 думал над ней?
15 лет назад, # |
  Проголосовать: нравится 0 Проголосовать: не нравится
Подчеркнул для себя несколько полезных идей. Большое спасибо.
Хотелось бы задать несколько вопросов.
  1. Что такое ошибка Output Limit?
  2. Так получилось что в команде я капитан, я же основной кодер, математик и алоритмист. Понятно что в начале контеста задачи простые и лучше если я их быстро напишу. В конце наоборот задачи сложные и опять-таки лучше их напишу я. А как лучше поступать когда задачи не слишком простые и не слишком сложные? Не стоит ли в такой ситуации дать написать другим а самому подумать над остальным? И верны ли мои суждения насчет начала и конца?
  3. Сильно ли плохо если у членов команды разные среды написания к которым они привыкли, немного различается сам стиль написания. Стоит ли переучиваться если проблем с пониманием кода друг друга нет?  Еще можно было бы сюда же спросить плохо ли когда пишут члены команды на разных языках но 2 из 3 пишут на с++ а 3 и так собирался его учить. Но я думаю что  есть команды которым этот вопрос актуален, поэтому все таки его задам.
Буду рад услышать мнение более опытных людей по озвученным вопросам.
  • 15 лет назад, # ^ |
      Проголосовать: нравится +5 Проголосовать: не нравится
    Output limit - это когда твоя прога пытается вывести очень много информации.

    Когда это может случиться? Например когда выводишь посимвольно строку и забываешь увеличивать индекс (или проверять достижение конца строки).

    Ясное дело, что программа зацикливается, но за ту отведённую секунду времени она успевает вывести оч много символов.
    В итоге Output Limit она получает быстрее, чем Time Limit.
  • 15 лет назад, # ^ |
      Проголосовать: нравится +5 Проголосовать: не нравится
    Есть ещё усталость, которая может повлиять на качество работы в четвёртый и пятый час. Возможно, имеет смысл отдать какие-то дела, которые лучше всех делаешь ты, другим. Например, написание простых задач, или одной средней задачи в середине. Это, конечно, локальный проигрыш по времени, но он может обернуться выигрышем по задачам в конце контеста.
15 лет назад, # |
  Проголосовать: нравится +9 Проголосовать: не нравится
Небольшое дополнение.

1) При Presentation Error ещё надо проверить, что послана нужная задача и файлы называются правильно. Особенно если на тесте 1.

2) Если никак не найти ошибку — полезно бывает ещё раз кому-нибудь прочитать условие, а также рассказать всем идею решения.
  • 15 лет назад, # ^ |
      Проголосовать: нравится +5 Проголосовать: не нравится
    Gassa, спасибо за дополнения:) Да, "Read the Problem" - великая вещь, сколько раз помогала:)