Хотя наука о данных не является областью, которая напрямую связана с информатикой, рост машинного обучения и искусственного интеллекта сделал кодирование неотъемлемой частью науки о данных.

Хотя проекты Data Science носят более экспериментальный характер и не так четко определены, как проекты программного обеспечения, соблюдение некоторых хороших принципов кодирования помогает повысить эффективность и масштабировать проекты Data Science.

Вот несколько хороших практик программирования, которым я стараюсь следовать:

  • Организация кода

Я гарантирую, что весь мой код не помещен в один файл, а разделен на несколько файлов. Обычно я разделяю свой код на следующие 4 основные части.

а. Файлы спецификаций

В большинстве моих проектов я обычно использую файл спецификации в виде YAML или JSON, где я могу указать различные параметры, которые нужно установить для запуска кода. Наличие этих спецификаций позволяет мне использовать код по-разному без изменений кода. Например, допустим, я построил модель для одной страны. Вместо жесткого кодирования переменной страны в моем коде, если я укажу переменную страны в файле спецификации, я могу использовать этот код в другой стране, просто изменив спецификацию.

б. Утилиты

Если есть части моего кода, которые достаточно универсальны для использования в нескольких проектах, я помещаю их в отдельные файлы, называемые «утилитами», чтобы я мог использовать их в нескольких проектах и ​​минимизировать повторную работу.

c. Основные функции

Когда дело доходит до кода основной логики, я снова стараюсь не помещать их все в один файл, а вместо этого распределять их по нескольким файлам. Например, в каждом проекте Data Science будет часть извлечения данных, часть исследования данных, часть моделирования и так далее. Я гарантирую, что эти части разделены на несколько файлов.

d. Главный исполняемый файл

Наконец, у меня есть отдельный файл (обычно называемый main.py), который должен выполнять весь код. Я стараюсь, чтобы в этом файле была минимальная логика. Цель этого файла - понять взаимозависимости различных частей кода и потока кода, а не подробную логику кода.

  • Документация

Во всех своих проектах я стараюсь поддерживать страницу Readme, которая регулярно обновляется при изменении моего кода . На странице Readme указывается цель кода, инструкции по установке и использованию это, а также архитектура кода и файловая структура высокого уровня.

Хотя Readme - это документация, ориентированная на код, я веду отдельную документацию, объясняющую статистику и логику машинного обучения. Цель этого - помочь другим специалистам по данным понять мою логику и алгоритм.

Хотя документация кажется обыденной задачей, она помогает мне лучше понять мой код, чем помогать другим.

  • Комментирование

Обычно я добавляю высокоуровневые комментарии к коду вверху каждого файла. Это не только дает читателю обзор файла, но и помогает мне лучше организовать файлы.

Для каждого метода, который у меня есть, я пишу комментарии о цели метода, аргументах, которые он принимает, и о том, что он возвращает. Это снова помогает мне разбить код на соответствующие методы.

В дополнение к этим высокоуровневым комментариям, если у меня есть сложная логика в моем коде, я стараюсь написать об этом несколько высокоуровневых комментариев.

  • Соглашение об именах

Большая часть кода Data Science, который я видел, имеет переменные и функции с именами x, y, z и т.д. Эти соглашения об именах делают код очень непонятным для любого, кто пытается его понять.

Когда я пишу свой код, мне нужно время, чтобы подумать о наиболее интуитивно понятных именах, которые можно дать моим методам, классам, переменным и т. Д. Я также гарантирую, что есть согласованность в части речи и регистре букв, которые я использую для этих элементов кода. . Например, я стараюсь использовать глаголы в нижнем регистре для методов, существительные в верблюжьем регистре для классов и т. Д.

Фактически, хорошие соглашения об именах уменьшают потребность в комментариях и документации.

  • Контроль версий

Один из лучших приемов хорошего кодирования - поддерживать контроль версий. Есть масса преимуществ от поддержки системы контроля версий. Вы можете легко сотрудничать между несколькими людьми, вернуться к более старой версии кода, добавить новые изменения / функции в код, не затрагивая старую версию и т. Д. Если вы раньше не использовали Git, создайте учетную запись Github и Начните с загрузки туда своих проектов. Это бесплатно и даст вам хорошее представление о системах контроля версий.

Учитывая тот факт, что проекты Data Science включают постоянные эксперименты и редактирование, контроль версий становится все более важным. Допустим, вы разработали модель, а затем добавили в нее новую функцию. Если вы сохраните их как две версии кода, это легко позволит вам сравнить производительность этих двух моделей.

  • Автоматическое тестирование

Хотя Data Science может не требовать исчерпывающих автоматизированных тестовых примеров для проверки работоспособности кода, как мир программного обеспечения, наличие тестовых примеров для проверки нюансов данных является очень хорошей практикой.

В своих проектах я использую пакет unittest для создания автоматизированных тестовых примеров для проверки функциональности различных частей кода и, что более важно, для проверки обработки потенциальных аномалий данных, таких как нулевые значения, пропущенные значения, выбросы и т. Д.

Хотя хорошие методы кодирования обеспечивают надежность модуля, написание хорошего кода требует много времени и усилий. Не все проекты это оправдывают. Если вы делаете анализ, который будет доставлен в течение недели, у вас нет роскоши, чтобы украсить свой код.

По этой причине я склонен разделять каждый проект на 3 фазы: POC, MVP и Production, как описано ниже:

  • POC - это то место, где я хочу получить решение, подтверждающее возможность моделирования.
  • MVP - это то место, где решение достаточно надежно для использования (дополнительные функции и настройка модели) и
  • Производство - это место, где решение полностью автоматизировано и развернуто.

Если я нахожусь в фазе POC, я не склонен тратить слишком много времени на очистку своего кода, но как только я перехожу на стадию MVP, я убеждаюсь, что мой код соответствует хорошим методам кодирования.

Если вы чувствуете, что есть какие-то другие практики, которым вы следуете в своей практике науки о данных, не стесняйтесь комментировать ниже! Ваше здоровье.