Myślę, że często tendencja do odczuwania, że wpadłeś do króliczej nory z analizami eksploracyjnymi, jest spowodowana utratą z oczu merytorycznego pytania, które zadajesz. Od czasu do czasu robię to sam, a potem muszę sobie przypomnieć, jakie są moje cele. Na przykład, czy próbuję zbudować konkretny model lub ocenić adekwatność istniejącego? Czy szukam dowodów problemów z danymi (tj. Analizy danych kryminalistycznych)? Czy też jest to na wczesnych etapach analizy, gdzie badam nieformalnie określone pytania (np. Czy istnieje związek między dwiema zmiennymi?) Przed przejściem do opracowania modelu formalnego? Podsumowując, jeśli przyłapiesz się na wyrabianiu fabuł i tabel, ale nie możesz jasno określić, jaki jest twój bezpośredni cel lub dlaczego ta fabuła / tabela jest istotna, to wiesz, że „
Staram się podchodzić do eksploracyjnej analizy danych tak, jak piszę, czy to pisząc program, czy pisząc artykuł. W obu przypadkach nie zacząłbym od zrobienia najpierw szkicu. Zarys ten może się oczywiście zmienić (i często się zmienia), ale rozpoczęcie pisania bez niego jest nieefektywne i często daje kiepski produkt końcowy.
Organizacja WRT, każdy analityk musi znaleźć przepływ pracy, który będzie dla niego odpowiedni - to IMO jest ważniejsze niż próba sztywnego śledzenia przepływu pracy innej osoby (chociaż zawsze pomocne jest uzyskanie pomysłów na podstawie tego, co robią inni). Jeśli pracujesz programowo (tj. Piszesz kod, który można uruchomić, aby wygenerować / zregenerować zestaw wyników) i sprawdzasz swoją pracę w git, oznacza to, że masz wiele mil w tym zakresie. Podejrzewam, że być może będziesz musiał poświęcić trochę czasu na uporządkowanie kodu, i do tego sugerowałbym podążanie za swoim szkicem. Na przykład pliki analizy powinny być stosunkowo krótkie i ukierunkowane, aby każdy z nich odpowiadał na jedno pytanie (np. Wykresy diagnostyczne dla konkretnego modelu regresji). Zorganizuj je w podkatalogach na jednym lub dwóch poziomach, w zależności od wielkości i złożoności projektu. W ten sposób projekt sam się dokumentuje; widok listy katalogów, podkatalogów i plików (wraz z komentarzem u góry każdego pliku) powinien teoretycznie odtworzyć zarys.
Oczywiście w dużym projekcie możesz mieć również kod, który zajmuje się czyszczeniem i zarządzaniem danymi, kod napisany w celu oszacowania określonego typu modelu lub inne napisane narzędzia, które nie mieszczą się w zakresie merytorycznym zarys analizy danych, więc powinny być zorganizowane w innej części folderu projektu.
Aktualizacja: po opublikowaniu tego zdałem sobie sprawę, że nie odniosłem się bezpośrednio do twojego pytania dotyczącego „ślepych zaułków”. Jeśli naprawdę zdecydujesz, że cały zestaw analiz nie ma żadnej wartości, to jeśli pracujesz w git, zawsze możesz usunąć odpowiednie pliki z komunikatem zatwierdzenia, np. „Porzuciłem ten wiersz analizy, ponieważ nie był produktywny." W przeciwieństwie do pogniatania tego, co napisałeś i wyrzucania go do kosza, zawsze możesz w razie potrzeby wrócić do tego, co zrobiłeś później.
Myślę jednak, że przekonasz się, że jeśli przejdziesz do konturu, nad którym zastanowiłeś się, będziesz mieć mniej tzw. Ślepych uliczek. Zamiast tego, jeśli spędzasz czas na badaniu wartościowego i istotnego pytania - nawet jeśli prowadzi to do zerowego znalezienia lub nie okaże się, jak się spodziewałeś - prawdopodobnie nadal chcesz prowadzić rejestr tego, co zrobiłeś i wyniku (na minimum, aby nie popełnić błędu, powtarzając to później). Po prostu przenieś je na sam dół swojego konturu, w formie „dodatku”.