На днях написал небольшой текст для своих ( не очень пока опытных ) команд по организации командной работы.
И решил выложить его сюда, чтобы послушать критику, дополнения и уточнения.
Кто хочет почитать, пожалуйте под кат.
1. Начало контеста. Все читают задачи. Через некоторое время один человек находит задачу, которую он 100% быстро сделает(быстро - не более получаса ), и садится за нее.
2. Если нет. Продолжаем чтение. С периодом в 5-10 минут обновляется монитор. Если видите, что сдана за 5-10 минут задача - значит нужно читать в первую очередь ее. Если прочитали, но вы не знаете, как ее решать - попросите прочитать ее других членов команды. Часто бывает, что кого-то клинит на простой задаче. Но всех троих вряд ли заклинит. Ни в коем случае не пересказывайте друг другу условия!!! Важнейшее правило - каждый должен сам прочитать условия всех задач!!! Клинит на простых задачах в 90% случаев из-за неправильного понимания условия.
1. Задачи, которые пока никто из других команд не сдал, не рассматриваются даже как вариант! Рекомендую вам ближайшие полгода придерживаться этого правила. Если вам кажется, что задача, которую никто не сдал - простая, то значительно более вероятно, что вы что-то не поняли, чем то, что все вокруг тупят. Пока не наберетесь опыта, давайте примем это за строгое правило. В свое время нам это помогло.
2. Рекомендую выделить чистый листок на команду. На нем выписать стобиком буквы задач. Вычеркивать на нем сданные задачи, отмечать недобитые, те, которые кто-то делает в данный момент за компьютером, те, по которым есть идеи. Это убережет вас от того, что кто-то думает над задачей, которую вы уже сдали, или которую делает кто-то еще. В любой момент любой участник должен видеть текущее состояние команды, кто над чем работает и ее перспективы, и этот листок этому поможет.
Отмечайте задачи, которые сдало много народу, вычеркивайте те, которые никто не сдал после нескольких часов.
Все задачи, начиная со второй, должны быть переписаны с листочка. Т.е. пока кто-то сидит за компьютером тот, у кого созрела 100% идея по задаче, не сидит, обсасывая ее, а пишет код на листочке. Именно код, со всеми объявлениями переменных, циклами и т.д. Сложно оценить, как это полезно, если ты этого не делал, но поверьте - это действительно ускоряет последующую работу. И не только. В 30% случаях в процессе написания вы поймете, что этот алгоритм не работает. В 30% поймете, что нужны совсем другие структуры данных. Лучше понять это еще не садясь за компьютер!
Если есть формулы - то написание кода заставит их продумать.
Если есть тонкие моменты - типа цикл до i, или i-1 - продумаете это, не тратя компьютерное время.
Если у вас будет вопрос по синтаксису языка - спросите у сокомандника опять же не тратя компьютерное время.
Потом, когда вы будете перепечатывать код, вам не придется перематывать экран туда-сюда, "о, здесь же переменную забыл объявить! о, нужно функцию вначале дописать!", что увеличит концентрацию, а, следовательно, уменьшит количество ошибок. Кроме того, в процессе перепечатки, вы посмотрите на ваш код еще раз, как бы со стороны, что
еще уменьшит количество ошибок.
Еще раз - практика показывает, что в коде, переписанном с бумажки на порядок меньше ошибок.
Единственный минус этого подхода - нужно хорошо знать язык, который вы используете.
Любой контест в идеале выглядит так - человек садится за компьютер, перепечатывает с бумажки код, исправляет пару багов, запускает проверку на "стандартном наборе" тестов, отправляет, встает из-за компа. Садится следующий, перепечатывает с бумажки код и т.д.
Предположим члену вашей команды нужно час, чтобы прочитать условие, придумать решение и написать его на бумажке, и полчаса чтобы его перепечатать с бумажки, отладить и отправить. Нетрудно заметить, что такая команда за контест сдаст 10 задач и займет в итоге первое место. Заманчиво?
Возьмем более реалистичный график. Два часа, чтобы прочитать условие, придумать решение и написать его на бумажке (согласитесь, целый вагон времени!), и час чтобы перепечатать с бумажки и отладить (учитывая размер стандартного решения, на перепечатку нужно 15 минут, т.е. 45 минут на отладку! ). Такая команда сдаст 5 задач, это то, к чему мы сейчас стремимся.
На практике, чаще бывает так - человек написал задачу, отправил, WA18, и что делать? Дать ему отладить, или посадить следующего, который уже написал решение на бумажке и ждет возможности сесть за компьютер?
В каких случаях нужно сажать следующего по очереди за компьютер, а в каких нужно дать человеку отладить задачу?
Сажать другого человека нужно при соблюдении одного из следующих условий:
a) человек в процессе кодинга понял, что этот алгоритм не работает
b) человек отправлял задачу, чтобы проверить - уложится этот алгоритм в TL, оказалось, нет. ( хотя это нештатная ситуация, надо уметь без компа определять )
c) человек не знает где у него ошибка в коде. И у него нет теста на котором его задача не работает. И он уже проверил весь джентльменский набор тестов
В этом случае человек распечатывает свой код, и идет читать его, а также условие за стол. А за комп садится другой. В остальных случаях человек остается за компьютером добивать задачу. Надо верить сокомандникам!
Если, глядя на распечатку, человек понял где ошибка, и знает что нужно исправить пару строк - надо дать ему такую возможность, т.е. посадить обратно!
- Тесты из условия. Их проверить обязательно!!!
- Тесты крайние снизу. Если (0<=N<=50), обязательно первым делом проверяется N=0. Дальше проверяется N=1,2,3,4 и пока не надоест. Если в тесте - строка, нужно проверить строку нулевой длиной, длиной 1, 2, 3 и т.д. Для строк длины 2 - когда они одинаковые в строке, когда разные. Если могут быть пробельные символы - обязательно проверить. Если граф – то проверить и полный, и пустой, а так же линейный, с нулем вершин, одной вершиной или двумя. Могут быть петли – проверить с ними. Мультиребра - то же самое. И т.д. Если есть возможность быстро проверить с десяток тестов - не пренебрегайте.
- Тесты крайние сверху. Если N<=10^9, обязательно проверить 10^9. Даже если вы не знаете ответ для таких значений. Знали бы вы, как часто на таких тестах программы выдают заведомо неправдоподобный ответ или вылетают.
В 90% случаях этого набора достаточно, но наблюдая за первой лигой, я вижу, что даже этот простой набор тестов не соблюдается.
За час до конца капитан определяет, сколько и какие задачи вы планируете досдать, причем реалистично! Т.е. это
- одна в большинстве случаев
- две, если по одной уже что-то весомое написано
- три может быть, только если у вас две недобитых и третья почти написана.
С этого момента все работы над другими задачами прекращаются! Если цель - "одна задача", то это означает что все делают одну! Т.е. один пишет, другой контролирует за монитором, что он пишет, третий пишет тесты, и читает-перечитывает условие. Периодически спрашивая "а вы учитываете, что ...", "а вы рассматриваете такой вариант ...". Да это нудно, но это командная работа, и в момент контеста нужно работать КОМАНДОЙ на достижение максимального результата.
И решил выложить его сюда, чтобы послушать критику, дополнения и уточнения.
Кто хочет почитать, пожалуйте под кат.
На первый час
2. Если нет. Продолжаем чтение. С периодом в 5-10 минут обновляется монитор. Если видите, что сдана за 5-10 минут задача - значит нужно читать в первую очередь ее. Если прочитали, но вы не знаете, как ее решать - попросите прочитать ее других членов команды. Часто бывает, что кого-то клинит на простой задаче. Но всех троих вряд ли заклинит. Ни в коем случае не пересказывайте друг другу условия!!! Важнейшее правило - каждый должен сам прочитать условия всех задач!!! Клинит на простых задачах в 90% случаев из-за неправильного понимания условия.
Середина контеста
2. Рекомендую выделить чистый листок на команду. На нем выписать стобиком буквы задач. Вычеркивать на нем сданные задачи, отмечать недобитые, те, которые кто-то делает в данный момент за компьютером, те, по которым есть идеи. Это убережет вас от того, что кто-то думает над задачей, которую вы уже сдали, или которую делает кто-то еще. В любой момент любой участник должен видеть текущее состояние команды, кто над чем работает и ее перспективы, и этот листок этому поможет.
Отмечайте задачи, которые сдало много народу, вычеркивайте те, которые никто не сдал после нескольких часов.
Идеал, к которому нужно стремиться на каждой тренировке
Если есть формулы - то написание кода заставит их продумать.
Если есть тонкие моменты - типа цикл до i, или i-1 - продумаете это, не тратя компьютерное время.
Если у вас будет вопрос по синтаксису языка - спросите у сокомандника опять же не тратя компьютерное время.
Потом, когда вы будете перепечатывать код, вам не придется перематывать экран туда-сюда, "о, здесь же переменную забыл объявить! о, нужно функцию вначале дописать!", что увеличит концентрацию, а, следовательно, уменьшит количество ошибок. Кроме того, в процессе перепечатки, вы посмотрите на ваш код еще раз, как бы со стороны, что
еще уменьшит количество ошибок.
Еще раз - практика показывает, что в коде, переписанном с бумажки на порядок меньше ошибок.
Единственный минус этого подхода - нужно хорошо знать язык, который вы используете.
Идеальный контест
Предположим члену вашей команды нужно час, чтобы прочитать условие, придумать решение и написать его на бумажке, и полчаса чтобы его перепечатать с бумажки, отладить и отправить. Нетрудно заметить, что такая команда за контест сдаст 10 задач и займет в итоге первое место. Заманчиво?
Возьмем более реалистичный график. Два часа, чтобы прочитать условие, придумать решение и написать его на бумажке (согласитесь, целый вагон времени!), и час чтобы перепечатать с бумажки и отладить (учитывая размер стандартного решения, на перепечатку нужно 15 минут, т.е. 45 минут на отладку! ). Такая команда сдаст 5 задач, это то, к чему мы сейчас стремимся.
Смена караула
В каких случаях нужно сажать следующего по очереди за компьютер, а в каких нужно дать человеку отладить задачу?
Сажать другого человека нужно при соблюдении одного из следующих условий:
a) человек в процессе кодинга понял, что этот алгоритм не работает
b) человек отправлял задачу, чтобы проверить - уложится этот алгоритм в TL, оказалось, нет. ( хотя это нештатная ситуация, надо уметь без компа определять )
c) человек не знает где у него ошибка в коде. И у него нет теста на котором его задача не работает. И он уже проверил весь джентльменский набор тестов
В этом случае человек распечатывает свой код, и идет читать его, а также условие за стол. А за комп садится другой. В остальных случаях человек остается за компьютером добивать задачу. Надо верить сокомандникам!
Если, глядя на распечатку, человек понял где ошибка, и знает что нужно исправить пару строк - надо дать ему такую возможность, т.е. посадить обратно!
Стандартный набор тестов
- Тесты крайние снизу. Если (0<=N<=50), обязательно первым делом проверяется N=0. Дальше проверяется N=1,2,3,4 и пока не надоест. Если в тесте - строка, нужно проверить строку нулевой длиной, длиной 1, 2, 3 и т.д. Для строк длины 2 - когда они одинаковые в строке, когда разные. Если могут быть пробельные символы - обязательно проверить. Если граф – то проверить и полный, и пустой, а так же линейный, с нулем вершин, одной вершиной или двумя. Могут быть петли – проверить с ними. Мультиребра - то же самое. И т.д. Если есть возможность быстро проверить с десяток тестов - не пренебрегайте.
- Тесты крайние сверху. Если N<=10^9, обязательно проверить 10^9. Даже если вы не знаете ответ для таких значений. Знали бы вы, как часто на таких тестах программы выдают заведомо неправдоподобный ответ или вылетают.
В 90% случаях этого набора достаточно, но наблюдая за первой лигой, я вижу, что даже этот простой набор тестов не соблюдается.
Конец контеста
- одна в большинстве случаев
- две, если по одной уже что-то весомое написано
- три может быть, только если у вас две недобитых и третья почти написана.
С этого момента все работы над другими задачами прекращаются! Если цель - "одна задача", то это означает что все делают одну! Т.е. один пишет, другой контролирует за монитором, что он пишет, третий пишет тесты, и читает-перечитывает условие. Периодически спрашивая "а вы учитываете, что ...", "а вы рассматриваете такой вариант ...". Да это нудно, но это командная работа, и в момент контеста нужно работать КОМАНДОЙ на достижение максимального результата.
1. Мы не перепечатывали с листочка. На первый взгляд кажется глуповатым, но если на практике это показывает такие результаты, то я не буду отговаривать :о)
2. Надо отталкиваться от состава команды. Оперируя понятями "кодячер", "мозг", "суслик", или, проще говоря, человек, который вбивает хорошо, человек, который вбивает плохо, но хорошо думает (или хорошо решает специфический класс задач - геометрию или графы), и человек, который суслик, но другого просто нет, и он тупо сидит пять часов на контесте. Состав в три кодячера я считаю плохим, но я знаю много людей, не согласных с этим. На мой взгляд есть два хороших состава: два кодячера и мозг, или один таргет и два суслика. Второй вариант в природе почти не достижим, поэтому остановимя на первом :о)
3. Имхо оба участника должны обязательно знать оба языка, но основной язык должен быть одинаковым. Далее, несколько простых правил, от которых мы чаще всего отталкивались:
а) Если монитор еще не заморожен, никто не лезет в чужие дела - я кодячу свое, ты свое, я тебя не трогаю, ты меня не трогаешь.
б) Если монитор заморожен - в этот момент видимо какая-то задача добивается. Вот когда она добита и остается 40 минут, надо работать вместе. И тут мы benefit от того, что основной язык общий.
в) Паттерн - в начале контеста набивается паттерн для основного языка. Опять же benefit от общего основного языка.
4. Основная фишка нашей команды всегда была "две студии", постепенно целиком замененая на "два эклипса", потому что че-то на финале студии нет. Общая идея - открываем две студии, цепляем первую и тащим мышку к левому краю экрана. Ничего не произошло? Значит у вас не Windows 7, тогда руками размечаем студию так, чтобы она занимала ровно левую половину экрана. Для второй студии - размещаем ее на правой половине экрана. Два участника садятся так, чтобы им обоим было удобно печатать - проверено, это всегда достижимо. Теперь две студии всегда открыты - если кто-то набажил, а это происходит всегда, он не сидит за левым столом размечая ошибки карандашом на распечатке (кстати, не могу похвастаться тем, что на любых стартах распечатка работает идеально), а вдупляет в код прямо на экране. И когда есть баг, чтобы его исправить надо сказать "дай клаву", нажать Alt+Tab, исправить, запустить, увидеть тот же неверный ответ, и отдать клаву назад. Не надо меняться местами, или что-то менять стоя. Другой сценарий, когда это benefit - когда я набираю сложную задачу и мне надо много думать, я могу на время думанья передавать клавиатуру для набивания другой задачи, менее приоритетной. Это происходит редко, но на этом можно экономить несколько минут. К тому моменту, как я закончу свою задачу, по следующей уже будет что-то набрано - чаще всего таким образом вбивается считывание данных и какая-то инициализация, потому что что-то мудрое писать рывками по минуте через пять не очень реалистично.
Попытки наши привить эту технику другим командам не увенчались успехом :о) Но я отвечаю - это круто :о)
Проблемы:
а) В студии колесо крутит активное окно, а не то, над которым мышь. Это сакс - я не могу прокручивать свое решение, когда читаю код. Мы это решали фразой "дай мышь код прокручу" до финала. На финале этой проблемы нет - в эклипсе под линухой мышь крутит окно, над которым курсор, а не активное, можно читать сколько влезет. А если мышку зафиксировать над гор. полосой прокрутки, колесико будет крутить горизонтально, что вообще имба.
б) Окно с децл узкое получается, к этому надо привыкнуть :о)
5. Последний час это вообще сложная тема :о) Я за много лет так и не смог для себя понять, как же надо вести себя на последнем часе. Мы всегда действовали по обстоятельствам, и часто это было не верно. В сущности очевидно, что то, что открыто, надо добивать. Но если открыто две - надо добивать обе или сосредоточиться на одной? Если открыта одна, надо ли отлаживать фанатично ее забив на другие, даже если есть решение, или начинать вбивать еще одну?
Вообще практика показывает, что бывают очень разные ситуации. Бывает, когда задачу сдали все, а у тебя -15 и ноль идей где ошибка. И до конца контеста можно пронубить и не сдать. Правила для всего не придумаешь :о)
В нашей команде все 3 человека были и кодерами, и мозгами, и вроде бы это не мешало нам показывать неплохие результаты. При таком подходе независимые действия до последнего часа - тоже странное явление. У нас была такая стратегия - если написанная программа не работала (на семплах либо получала не AC при сабмите), решение немедленно печаталось и человек освобождал комп для написания задачи. При этом 3й как правило должен помогать искать багу в распечатке (если он в это время не помогает писать решение другой задачи). Это позволяет не тратить компьютерное время на дебаг, а также уменьшает вероятность зависания команды на одной задаче из-за того, что кто-то не замечает мелкую багу. Не ясно, зачем держать открытую вторую студию, это менее удобно, чем распечатки.
При придумывании чего-либо нетривиального это также должно обсуждаться с кем-либо прежде чем писаться. Это позволяет минимизировать потери времени из-за лажи.
Чтение задач у нас было устроено тоже немного не так: в начале тура рисовалась таблица с задачами, прочитавший пишет туда краткий комментарий, по которому он сможет пересказать содержание задачи. Перечитывание кем-нибудь другим происходит только в случае, если явно видно, что что-то понято не так.
В общем, всё же стоит пытаться максимизировать командную работу, соревнования всё же командные. Подозреваю, что большинству команд всё же больше подойдёт наша тактика, чем "кодячер - мозк - суслик".
Я не могу поспорить, что вариант, когда три человека кодят, да еще и покрывают разный класс задач, очень крут :о) У нас не было третьего и мы выбирали лучшую тактику для двоих, и мы вроде научились показывать неплохой перформанс вдвоем.
Наверное, лучшим советом будет попробовать по разному и посмотреть что работает лучше для конкретной команды. Вариант работать в две студии мы слизали с Warsaw HammerHeads на сборах в птз. Правда, они сами потом отказались от такой тактики к следующим сборам.
Как минус - меньше ресурсов остается на придумывание новых задач. Но у нас так получалось, что это не было проблемой.
А плюсов море:
1. К моменту начала написания задачи двое знакомы с условием и решением. Вероятность, что кто-то не понял условие или предложил паленое решение - минимальна.
2. Код пишется быстрее, всегда есть человек который подскажет когда ты тупишь.
3. Если начал писать что-то не то, то тебя сразу поправят.
4. Если посадил опечатку - большая вероятность, что опечатка будет сразу исправлена.
5. К моменту завершения кодирования у нас готовы тесты и пишуший человек не переключает внимание.
Как следствие, практически все задачи сдавались с первой попытки.
В целом, получалось здорово! С такой тактикой мы обычно чуть отставали от лидеров в начале соревнования, но наверстывали в середине на "средних" задачах. А что самое главное - была стабильность. "Шатало" нас намного меньше, чем другие команды.
1. Интенсивнее происходит обмен опытом между сильными и слабыми участниками.
2. Быстрее члены команды приводятся к общему стилю.
И еще один минус:
1. Все члены команды должны писать на одном языке, или хорошо знать оба.
Надо наверно, чтобы команда попробовала оба способа, и решила для себя какой лучше...