Краткое сравнение того, что я видел/ощущал, когда работал инженером-программистом и специалистом по данным, и решения проблем, с которыми я сталкивался

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

В следующих частях поста SW и DS означают Software и Data Science соответственно.

Управление проектом

Как вы могли догадаться, фазы Бизнес-цель или Спрос, Планирование, Технология Дизайн, Реализация и Обслуживание/Мониторинг были одинаковыми или похожими для обоих типов проектов, насколько мне доводилось работать. Менеджеры проектов или владельцы продуктов, в зависимости от размера компании или аспекта, завершают бизнес-цель после множества встреч, определяются функциональные и технические требования и проводится оценка как с продуктовой, так и с технической командами, затем разрабатывается приложение. Наконец, выпущенное приложение отслеживается, и позже разрабатываются необходимые изменения/функции.

Анализ данных

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

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

Технический дизайн

Использование четкого дизайна программного обеспечения, такого как гексагональная архитектура, позволяет добавлять новые функции или изменять технологический стек как для проектов SW, так и для проектов DS. Источники данных, фреймворки и даже языки программирования могут меняться до начала разработки. Например, если мы хотим реализовать приложение с очень коротким временем отклика для платежных процессов, можно реализовать кеш для хранения этой важной информации, и мы можем снизить нагрузку на БД.

Для проектов DS поток приложений аналогичен проектам SW, за исключением этапов обучения модели, выбора модели и прогнозирования. Таким образом, в техническом дизайне можно определить сложность MLOps. Первоначально, начиная с простейшего способа, которым обучение модели, выбор модели и развертывание модели можно выполнить вручную, затем эти шаги можно автоматизированный. Помимо MLOps, тип алгоритма и сложность модели являются еще одним важным фактором для технического проектирования.

Планирование

Если все проверки выполнены и требования утверждены, мы можем приступить к разделу планирования. Поскольку команда начинает лучше понимать динамику и среду разработки, эта фаза становится лучше, как я заметил. Задачи могут быть созданы как можно более детализированными, каждый член команды может дать лучшие и одинаковые баллы за спринт, а общая оценка и планирование могут быть завершены.

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

Со стороны данных детали со стороны программного обеспечения в целом аналогичны. Кроме того, планирование этапов Разработка функций, Обучение модели и Выбор модели может быть переоценено, и это также нормально, поскольку эти процессы связаны с данными. Улучшенный анализ данных и простой подход могут помочь в планировании. Помимо них, для моделей можно назначить более простые пороги, чтобы превзойти их на этих шагах. Например, если оценка F1 классификатора выше значения X, мы можем остановиться на этом и сохранить волнение для дальнейшего обучения модели.

Разработка

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

В приложениях SW реализация тестов для обычного приложения немного проще, чем в приложениях DS. Тестирование результатов модели ИИ — не лучший подход, если мы используем сложную модель. Однако для этих моделей могут быть реализованы макеты, как это может быть реализовано для внешних служб в приложениях.

Разработка функций, обучение модели и выбор модели являются отличительными этапами помимо проектов ПО. Как упоминалось в предыдущем сеансе, могут быть некоторые пороги с 2 измерениями. Одним параметром является критерий успеха для остановки, а другим параметром – критерий времени. Поскольку эти шаги являются одними из самых популярных и широко разрекламированных разработок в настоящее время, эти разработки и исследования должны быть ограничены для повышения производительности. Если это новое приложение принесет некоторый успех и потребует большей точности, эти три этапа могут быть продолжены для дальнейшего развития.

Мониторинг

Наконец, пришло время пожинать плоды для обеих сторон. Использование инструментов мониторинга, таких как Splunk и Datadog (я работал только с ними), которые извлекают информацию из журналов приложений, играет важную роль. После выпуска новой версии это будет первое место, где можно будет убедиться, что новая версия работает без сбоев. Метрики программного обеспечения, такие как количество запросов и время ответа, а также типы ошибок, можно извлечь, написав хорошие журналы. Также полезно выполнять проверки данных в классе контроллера, где запросы принимаются и перенаправляются в нужные службы, прежде чем начинать операции как для SW, так и для DS-проектов, если только сторона пользовательского интерфейса не выполняет какую-либо проверку. Проверки регулярных выражений и проверки типов данных могут буквально спасти приложения как с точки зрения производительности, так и с точки зрения безопасности. Простая инъекция SQL может быть предотвращена простой проверкой и даже может спасти будущее компании.

Что касается DS, помимо метрик программного обеспечения должен осуществляться дополнительный мониторинг. Распределение функций модели и прогнозы модели имеют жизненно важное значение.Если распределение какого-либо столбца данных изменится, может произойти сдвиг данных, и может потребоваться новое обучение модели. Если результаты прогнозирования можно проверить за короткое время, эти результаты необходимо отслеживать и предупреждать разработчиков, если точность ниже или выше заданного порога.

Общие практики

Перед заключением я хотел бы упомянуть некоторые общие практики, которые помогают мне в обоих типах проектов.

  • Хорошее знание предметной области. Это необходимо для обеих сторон. Чтобы приобрести эти знания, мы должны понимать требования клиента. Эти знания могут обеспечить такие преимущества, как реализация важных пограничных случаев в проектах SW и извлечение замечательных функций в проектах DS. Это также помогает писать более качественные тесты и подготавливать лучшую среду для приложения.
  • Использование OKR для результатов проекта. Чтобы придать приложениям большую ценность для бизнеса, лучше говорить на деловом языке. Мы должны трансформировать цели с «сократить время отклика на x» на «ускорить процесс адаптации на y» или «снизить уровень мошенничества на x» на «увеличить коэффициент конверсии платежей на y». Эти преобразования помогут командам в разных отделах улучшить общение и сократить количество технических терминов в общении между техническими и нетехническими командами.
  • Применение методов разработки: чистое кодирование, проектирование отличной сервисной архитектуры, парное программирование и обзоры — самые распространенные, насколько я помню. Для технического обслуживания качество кода неизбежно. Даже для одного файла Jupyter-Notebook другой человек должен максимально понимать сценарий, чтобы понимать и реализовывать новые функции. Парное программирование и обзоры также важны для повышения производительности и уменьшения числа упущенных ошибок.
  • Отличная документация. Во время планирования и проектирования также важно иметь качественную документацию, которую можно считать юридическим документом перед началом реализации. Его можно использовать в качестве источника для разработки и содержать краткие пояснения и блок-схемы для других технических и нетехнических сотрудников компании.

Заключение

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

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

Прежде чем попрощаться, я хотел бы сказать спасибо первому читателю этого поста Мустафе Кираку!

Чтобы сказать мне «привет» или спросить меня о чем-нибудь:

linkedin: https://www.linkedin.com/in/ktoprakucar/

гитхаб: https://github.com/ktoprakucar

электронная почта: [email protected]

Рекомендации