В перерыве от регулярно запланированного программирования с использованием проектной работы эта статья больше похожа на статью или личное руководство, основанное на опыте. В ходе разработки моих собственных проектов по науке о данных я обнаружил, что следующие советы поощряют лучшие практики и помогают другим читать и поддерживать вашу работу.
Список содержит элементы, относящиеся ко всем частям жизненного цикла проекта по науке о данных, и я буду включать ссылки на полезные ресурсы повсюду.
№1. Используйте хорошо структурированные каталоги проектов
Разница между хорошо структурированным и плохо структурированным каталогом проекта, как правило, отличается от проекта к проекту. Однако для большинства проектов простая установка с пакетом скриптов, файлом main.py и файлом данных является четкой и простой в интерпретации.
Используя проект, настроенный, как указано выше, основная программа может работать с использованием сценариев в папке сценариев, а файл main.py может оставаться чистым и легким. Вторым преимуществом вышеописанной структуры является то, что файл main.py можно заменить файлом main.ipynb, а чистый анализ можно построить с помощью более объемного кода и функций, включенных в пакет скриптов.
№ 2. Если вам не нужно жестко кодировать это JSON, это
При обучении моделей или запуске кода с большим количеством определяемых пользователем параметров/гиперпараметров полезно хранить их все в одном месте. Это позволяет вносить изменения в файл JSON вместо базы кода. В приведенном ниже примере показаны жестко заданные параметры, используемые в дереве решений, а не аргументы JSON.
При такой настройке параметры можно тестировать и сохранять в разных элементах, так что в коде должно измениться только имя элемента:
№3. Используйте подсказки типов
Это относится к программированию на Python в целом. Вместо использования длинных строк документации, которые не добавляют реальной ценности при объяснении подсказок типа кода, позвольте коллегам-программистам взглянуть на вашу предварительно написанную функцию и узнать, что вставить и чего ожидать на другом конце. Большинство IDE также поддерживают подсказки типов и дадут вам полезное предупреждение, если вы не подчиняетесь изложенной ранее логике.
В приведенной ниже функции показан пример использования подсказок типа для функции, которая принимает целое число и возвращает строку.
№ 4. Установите уровни ведения журнала и используйте ведение журнала
Я только недавно узнал об использовании ведения журнала, и это изменило мой взгляд на ошибки и отладку. Уровень ведения журнала определяется в начале файла, и вместо сотен операторов печати для подтверждения или отрицания того, что код делает то, что он должен регистрировать, сообщения могут делать это вместо этого. По этому поводу уже были опубликованы обширные ресурсы, отличный пример приведен ниже:
Я использую уровни ведения журнала, чтобы выяснить, что происходит за кулисами при построении и настройке гиперпараметров различных моделей, но они особенно полезны, когда вам нужно передать код другим разработчикам, которым нужно заглянуть за кулисы и понять, что может быть не так. на каждом шагу пути.
№ 5. Закрыть ресурсы
Несмотря на то, что могут показать мои более ранние проекты с постоянно открытыми соединениями и портами, важно закрывать соединения и ресурсы, когда вы закончите. Это немного вводящее в заблуждение утверждение, потому что на самом деле ресурсы должны быть закрыты, когда ваш код готов. Разница здесь в том, что вместо того, чтобы закрывать все ресурсы в последней строке вашего кода, если вы прекратите доступ к данным SQL в середине сценария, вы можете закрыть ресурс тут же.
Это не обязательно делает код более понятным, но делает его более удобным для использования и является абсолютно лучшей практикой при использовании данных, которые не хранятся локально.
№ 6. Используйте осмысленные имена переменных (включая временные имена!)
Каждый учебник по коду и вводный курс по Python расскажет вам о важности осмысленных имен переменных. В частности, специалисты по данным могут быть склонны к использованию быстрых и грязных решений проблем, особенно до того, как код будет запущен в производство. Примеры этого включают использование отдельных букв в списках или несовместимые имена для фреймов данных, таких как df, df_1 и df_new.
Проблема с использованием кода с именами переменных, которые понимает только первоначальный автор, заключается в том, что в конце концов весь код отправляется в производство. Поиск каждого следа этого единственного фрейма данных, который вы назвали в честь персонажа Игры престолов, прежде чем отправить его на GitHub, не стоит головной боли! Я знаю по опыту, пожалуйста, используйте осмысленное имя с самого начала.
№ 7. Настройте файл требований к пакету
Для этого существует замечательный модуль, поэтому я буду краток. Мы все в одном простом пипе от спасителя управления пакетами в виде pipreqs. Этот пакет перебирает все файлы вашего проекта и находит все импортированные пакеты и версии, которые вы в настоящее время установили. Затем создается файл requirements.txt, содержащий эти требования. Это избавляет от многих травм при запуске кода на новой машине или в качестве нового разработчика проекта.
№8. Настройте файл utils.py
Универсальный и почти шаблонный файл utils.py был для меня спасательным кругом при запуске бесчисленных проектов. Мои файлы utils содержат весь код, который я считаю универсальным и который можно повторно использовать в других проектах. Все, что не относится к домену для текущего проекта, перетасовывается в файл utils.py, отсюда я могу выбирать любые функции, которые могут мне понадобиться в будущем. Полезным примером является функция, которая использует регулярное выражение для поиска определенной подстроки, или функция для преобразования строк даты в объекты даты и времени, форматирования их и последующего преобразования обратно в строки.
№ 9. Используйте синтаксические анализаторы аргументов для доступа к аргументам среды выполнения.
Пакет argparse значительно экономит время при устранении ошибок пользовательского ввода. Особенно, когда речь идет об использовании аннотированных аргументов, а не позиционных аргументов. Документация для этого пакета приведена ниже, и она очень хорошо работает в сочетании с другими советами, такими как использование осмысленных имен для пользователей во время выполнения.
№10. Используйте обработку ошибок (с умом)
Нет ничего более неприятного, когда при отладке кода, написанного другими специалистами по данным или разработчиками, что-то пропускается без видимой причины. Альтернативная проблема — это код, который ломается, когда на самом деле не должен. Проблемы, которые я описал, являются следствием слишком большой (и плохо написанной) обработки ошибок и слишком малой обработки ошибок. Не каждый блок кода должен быть в операторе try/except, но те, которые есть, должны быть четко определены.
При написании оператора обработки ошибок всегда используйте именованные ошибки и переносите их на определенные блоки кода (например, при доступе к элементу с помощью ключей, которые могут не существовать, переносите эту строку в блок try KeyError), это предотвращает целые блоки кода. пропущено по неправильным причинам и вводящим в заблуждение печати стеков ошибок.
Это завершает список, и я действительно надеюсь, что из него можно сделать несколько полезных выводов. Я сам всегда ищу другие способы улучшить свое мышление в разработке проектов и моего собственного кода, поэтому, пожалуйста, добавляйте ссылки на полезные ресурсы/советы в разделе комментариев!
Если вам понравилась эта статья, ознакомьтесь с более подробными статьями и учебными пособиями по проектам на моей странице.
