Я думаю, что часто, склонность чувствовать, что вы спустились в кроличью нору с предварительным анализом, происходит из-за того, что вы упускаете из виду существенный вопрос, который вы задаете. Иногда я делаю это сам, а потом должен напоминать себе, каковы мои цели. Например, пытаюсь ли я построить конкретную модель или оценить адекватность существующей? Я ищу доказательства проблем с данными (например, криминалистический анализ данных)? Или это на ранних этапах анализа, когда я неофициально изучаю конкретные вопросы (например, существует ли связь между двумя переменными?), Прежде чем перейти к разработке формальной модели? В общем, если вы ловите себя на том, что проверяете графики и таблицы, но не можете четко указать, какова ваша непосредственная цель или почему этот график / таблица имеет значение, то вы знаете, что «
Я стараюсь подойти к исследовательскому анализу данных, как пишу, будь то написание программы или написание статьи. В любом случае, я бы не стал сначала делать наброски. Конечно, эта схема может измениться (и часто меняется), но начинать писать без таковой неэффективно и часто приводит к плохому конечному продукту.
В организации WRT каждый аналитик должен найти рабочий процесс, который работает для него или ее - делать это для ИМО важнее, чем пытаться строго следовать чужому рабочему процессу (хотя всегда полезно получать идеи от того, что делают другие). Если вы работаете программно (то есть пишете код, который можно запустить для генерации / восстановления набора результатов) и проверяете свою работу в git, то вы уже намного опережаете многих в этом отношении. Я подозреваю, что вам, возможно, просто нужно потратить некоторое время на организацию своего кода, и для этого я бы предложил следовать вашему плану. Например, файлы анализа должны быть относительно короткими и целенаправленными, чтобы каждый отвечал на один конкретный вопрос (например, диагностические графики для конкретной модели регрессии). Организуйте их в подкаталоги на одном или двух уровнях, в зависимости от размера и сложности проекта. Таким образом, проект становится самодокументированным; представление списка каталогов, подкаталогов и файлов (вместе с комментарием вверху каждого файла) теоретически должно воспроизводить ваш контур.
Конечно, в большом проекте у вас также может быть код, который выполняет очистку и управление данными, код, который вы написали для оценки модели определенного типа, или другие написанные вами утилиты, и они не будут вписываться в основную часть. Схема для анализа данных, поэтому они должны быть организованы в другой части папки вашего проекта.
Обновление: после публикации я понял, что не обращался напрямую к вашему вопросу о «тупиках». Если вы действительно решили, что весь набор анализов не имеет смысла, то, если вы работаете в git, вы всегда можете удалить соответствующий файл (-ы) с сообщением о коммите, например: «Отказались от этой строки анализа, потому что она не была продуктивный «. В отличие от того, чтобы сложить то, что вы написали, и выбросить это в мусорное ведро, вы всегда можете вернуться к тому, что вы сделали позже, если хотите.
Тем не менее, я думаю, вы обнаружите, что если вы начнете с набросков, к которым вы подумали, у вас будет меньше так называемых тупиков. Вместо этого, если вы тратите время на исследование стоящего и уместного вопроса - даже если это приводит к нулевому результату или не получается так, как вы ожидали, - вы, вероятно, все еще хотите вести учет того, что вы сделали, и результата (в минимум, чтобы вы не ошиблись, повторив это позже). Просто переместите их в конец своего наброска, в виде «Приложения».