Всем привет.
Есть у меня такая проблема, что начинаю писать код на задачу слишком рано, когда только придумал идею и минимальную реализацию.
Иногда это даёт свои плоды и я оказываюсь где-то в топе (последний хороший результат получился на 540 раунде Codeforces Round 540 (Div. 3)).
Только вот чаще я трачу очень много времени на задачу, когда можно было посидеть, немного подумать и понять, как сократить или упростить решение. В частности, сегодняшняя задача 1131D - Gourmet choice, которую после контеста переписал и она без каких-либо проблем зашла, а написанный на контесте код валился либо на 6, либо на 9 тесте.
Найти баланс между временем на обдумывание и временем на написание бывает достаточно сложно, поэтому хочется спросить у вас, а как с такой проблемой справлялись вы?
Сидеть и полчаса думать, как написать простую задачу — фиговая идея, в то же время если сразу после прочтения сесть и что-то писать, на решение могут уйти те же полчаса.
Желательно советы, направленные именно на решение этой проблемы, а не любимое многими "решай больше задач".
Можешь попробовать писать код на бумажке(не во время контеста, конечно, а при дорешке). Это заставит сразу чуть аккуратнее и детальнее продумывать структуру программы.
Всё, как мне кажется, идёт из очень важного подхода к решениям задач: умение разбивать решение задачи на большое число очень маленьких блоков (из разряда "применить такой алгоритм" или "посчитать такую функцию" или "применить такую декомпозицию данных"). То есть не просто брать общую идею решения задачи и начинать писать код, а потом находить все нюансы по ходу написания кода, а делать это сразу при решении задачи. При этом при написании кода тоже очень сильно помогает использование такого подхода — а именно разбивать код на большое количество небольших функций, вместо того, чтобы писать всё в main (я, правда, чаще просто разбиваю код на абзацы, так как опыт уже есть), так и дебажить гораздо проще.
Прикол в том, что когда у тебя решение задачи состоит из набора маленьких блоков, про каждый из блоков тебе будет очевидны и асимптотика, и сложность написания кода, и корректность решения, и оптимизировать решение будет проще. Да и изначально задачу в таком виде решать гораздо проще, типо, подумал, "ага, если смогу решить такую подзадачу, то далее можно будет применить такой алгоритм и задача решится", и далее пытаешься решить подзадачу с таким же подходом, пока она нестанет слишком простой.
Как этому научиться? Ну... Практика... Пытайся это всегда делать при решении задач, пытайся писать код, который хорошо идеологически разбит на маленькие блоки. У меня с опытом это уже на автомате делается, не знаю, то есть я когда сажусь писать код, уже легко предсказываю, сколько строк там будет, насколько их сложно будет написать и корректно ли моё решение (в основном), потому что решение уже разбито на блоки, так что я с твоей проблемой не сталкивался уже много лет, поэтому и считаю, что именно такой подход помогает.
UPD: Забыл написать, причём здесь твоя проблема
Когда задача разбита на маленькие блоки, очень легко понять, как упростить решение, соптимизировать или написать лаконичнее. Т.е. если получается блоков >10 штук, то наверняка это overkill и есть более простое решение, а если блок выходит на >10-15 строк (оценивая до написания кода), то либо блок плохо разбит, либо его можно написать красивее, либо надо придумать другой подход к решению блока, либо решение задачи изначально overkill.
Всегда сначала обдумать, потом писать.
Исключения:
1. На командном контесте комп будет простаивать минут 10 (а-ля сокомандник сказал, что ему нужно продумать на бумажке, как писать конкретное место), а в твоей задаче есть какая-то часть, которая не требует обдумывания = стандартный алгоритм (класс точки, ДО, суф.структуры, кароч все, что не требует включения мозга). Причем даже в этом случае может оказаться, что в написанный код придется вносить изменения из-за идейной части, но обычно это не очень страшно.
2. В конце контеста понимаешь, что если не начать писать в ближайшие 5 минут, то точно не успеешь дописать до конца.