Comments 7
Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
На мой взгляд, вопрос уже поставлен некорректно.
Нет никакого абстрактного «правильного и качественного» решения. Все зависит от поставленной задачи.
Если нам нужно API, которое на запрос GET / должно выдавать «Hello World», то мы просто пишем echo «Hello World» и все. Если на том же самом проекте требуется уже разный ответ по разным url + работа с базой — нужно уже использовать фреймворк.
Но использовать фреймворк для первой задачи — избыточно. А для второй задачи писать свой роутинг, свою работу с базой — это уже велосипеды, которые скорее всего окажутся костылями.
Нет никакого абстрактного хорошего и качественного решения. Все зависит от поставленной задачи.
А «все плохо» на проекте становится тогда, когда у команды хронически нет времени рефакторить старый код под новые задачи. Когда новые требования решаются по-быстрому, костылем.
Дальше тоже одни вопросы по тексту:
попытаться предварительно изучить на практике «с паяльником и осциллографом» в руках эти внешние источники и сделать минимально простой интеграционный модуль.
применение инструментов data science является идеальным
А я думал, что внешние источники изучаются чтением документации по ним…
Подобная интеграционная схема организуется и поддерживается в продуктиве в разы быстрее и легче средствами data science, чем Java/C++/SQL/php
Можно реальный кейс?
Можно реальный кейс?
В этом блоке как раз описан вполне реальный кейс, только имя компании не указано. NDA. Реальнее не придумать и полагаю, что многие пользуются этой площадкой далеко не первый год.
А я думал, что внешние источники изучаются чтением документации по ним…
И это тоже. Только очень частно документация и реальность сильно расходятся. Не говоря о том, что есть логическая структура, а есть ее фактическое наполнение. Логическая еще хоть как-то может быть отражена в документах, а наполнение можно изучить только руками.
На мой взгляд, вопрос уже поставлен некорректно.
Это субъективно, у каждого свой опыт. На мой взгляд (десятки сданных проектов от 10м руб до $10М) он поставлен более чем корректно.
А «все плохо» на проекте становится тогда, когда у команды хронически нет времени рефакторить старый код под новые задачи. Когда новые требования решаются по-быстрому, костылем.
Почти это и сказано в Сценарии 4. Сохраняйте хорошую архитектуру в целости, не шатайте ее под новые непонятные срочные требования от непонятных участников. Осознавайте и потом грамотно встраивайте. Растягивайте хвост инфицирования.
Полюбопытствовал Ваши комментарии. Очень много по сути и по делу. Может и тут сформулируете в лоб, что хотели спросить. Я ответы написал, но похоже, что подоплека иная.
Кстати, я описывал в https://habr.com/ru/post/548414/ похожий подход, который Вы упоминали в комментарии https://habr.com/ru/post/563776/comments/#comment_23173452.
По заданным вопросам текущую публикацию лучше рассматривать в контексте предыдущих.
Интересная и даже мне кажется перспективная точка зрения, но сильно абстрактно, особенно кейс 4, в котором data science приходит и просто делает всем хорошо.
Если к вашим кейсам добавить хотя бы диаграммы C4, стало бы понятнее, как скрестить ужа с ежом.
Я бы ответил более конкретно, но не совсем понятно, что именно. Тут ведь более о типовых паттернах, когда симбиоз бывает успешен. Поэтому подача материала и построена как "пришел и сделал всем хорошо".
1. С4 подразумевает конкретную архитектуру конкретного ПО. В каждом случае она будет разная. Если речь о C4 для DS стека, то он будет зависеть от выбранных технологий. Есть предпочтения, но они слишком частные для паттерна и параллельны теме публикации.
2. Кейс 4. Схемы взаимодействия между основным ПО и DS будут определяться точками взаимодействия и интерфейсами в основном ПО. Смысл ведь в том, чтобы ничего не ломая исправить партнерские косяки или сделать "генеральский светофор" к разовому показу (утрирую). Демонстрация кейса этот тоже не абстрактен, а является выжимкой классических менеджерских хотелок, появляющихся на этапе ближе к ПСИ. Самая простая и самая понятная. В требованиях был месяц? Но мне надо квартал, а вдруг когда-нибудь потребуется. А где ползунок на год? Рядовые пользователи молчат, им это не надо. А менеджеру с этим однократным вопросом приходится что-то показывать. И плевать на сайзинг, реальные потребности реальных пользователей, сроки, число пикселей на экране и пр.
помимо трассировки приложения, метрик, есть еще такие вещи как А/Б тесты, randomized controlled trials, многорукие бандиты и другие численные методы, которые:
1. нужны как воздух для развития продукта
2. требуют знания дата саенса
3. требуют мощных дата пайплайнов
тогда не будет противоречия между архитекторами, разрабами, продуктов и дата саенсом.
Команда продукта, а именно их метрики вроде Дохода/прибыли/роста клиентов будут драйвить все действия всех команд: айти инфраструктура, девопсы, разрабы, безопасники, продукт менеджмент, разрабы, маркетинг, дата саенс.
я уже не говорю о том, что какие-то фичи продукта могут полностью переплетаться с дата саенсом. Например рекомендательная система для клиентов на основе коллаборативного фильтра — ее должны реализовывать бекендеры, которые только джейсон перекладывать могут, фронтендеры-формошлепы, дата инженеры, или дата саентисты? а кто будет делать A/B тест и смотреть на сколько рекомендации приносят доход? тут командная работа нужна, и продукт менеджеры в идеале должны драйвить процесс.
самое печальное, что в продукты набирают гуманитариев, кто не прошел ни в инженеры, ни в датасаентисты, которые не могут организовать всех вокруг продукта, и как часто в ынтырпрайзе случается — начинается политика по перетягиванию одеяла на себя у каждой мини-команды
Спасибо за детальный комментарий.
1. Я сознательно не затрагивал классические области, охватываемые DS, поскольку там потребители информации -- маркетологи, владельцы продукта, РП, бизнес. Для разработчиков только те темы, что близко к dev.
2. Полностью согласен. Поскольку все просят постоянно кейсы, то из последнего -- ровно в этой парадигме запущен продукт https://www.x5.ru/ru/Documents/ExpressScan/index.html. Каждый может пощупать сам, найти "пасхалки" и почитать подробнее в интернете.
Разработка (dev) и data science в enterprise — битва за ресурсы или эффективное сотрудничество?