TS не защитит вас в рантайме. Если придет что-то другое, то вы это TS не излечите и он вам об этом ничего не скажет.
Интеграционные тесты API должны гарантировать, что эта штука все ещё работает. Тесты API на контракт тоже должны быть здесь. e2e тесты клиента должны проверять полную интеграцию для минимального user happy path.
Недавно мы начали разрабатывать проукты через TDD, в довольно строгом смысле. Это требует наличия инфраструктуры, которая поддержвает все уровни тестов, включая линтинг от TS.
Как мы решаем тот случай, о котором вы говорите:
API предоставляет контракт в виде npm пакета с автосгенерированным TS кодом (в нашем случае поверх gRPC и protobuff). Следуем SemVer: патч, фича или мажорный апдейт контракта сервиса.
BFF на NestJS использует пакет с типами от API везде в коде. Не создаем дополнительные слои DTO.
В контроллерах в обязательном порядке маппим данные перед отправкой на клиент, чтобы в рантайме не ушло больше чем мы хотим.
Если меняется, используемый API, то обновляем его npm-пакет и смотрим отвалилось ли что по TS линтингу и тестам всех остальных уровней: юнит тесты BFF, интеграционные тесты BFF, e2e тесты клиента.
При этом во фронте у нас проект без TS.
В целом мне в BFF очень нравится такой флоу работы. В фронтенде при работе со своим BFF мы стараемся идти в сторону только обратно совместимых изменений API, чтобы не афектить старый UI и новый UI. И только после того, как старого не остается ни у кого, тогда клинапим BFF обратнонесовместимым обновлением. Следуем подходу двухфазного деплоя.
Не соглашусь с вами. Не буду размышлять на тему что такое react way и есть ли он вообще. Или на тему того, что хуки это может быть очень спорное решение и некоторые простые вещи приходится писать через одно место.
Нельзя ориентироваться на useState и считать это истинным react way. Это просто одна из многих функций и вот она так реализована и это имеет смысл. Это не значит, что все надо делать так на автомате.
А вот у нас коллегам было не так очевидно, что объект лучше, чем массив. Было мнение что массив, как у useState, это react way.
Мы долго обсуждали оставить ли исключение для случая с 1 параметром, особенно, если это какая-то id. Также и про 2 параметра. Сошлись на том, что всем проще всегда оборачивать в объект, чем принимать такие решения. С ростом числа аргументов вовремя решаться на рефакторинг не всегда удается даже опытным разрабочикам. А ещё не ясно как проводить ревью.
Работаем с зарубежными «большими пацанами». 3 года назад TS был в опале, сейчас ситуация поменялась, он используется по умолчанию. Есть большая проблема того, что те, кто не писал бекенд и начал сразу с фронтенда и работает давненько просто используют TS ужасно и становится хуже чем без него. Хотя опять же это скорее не проблема TS как такового, а проблема Engineering Excellence для этой конкретной команды.
Мы бы сказали, что если команда не может выстроить нормальную архитектуру решения без TS, то с ним станет все только хуже. Такая же история с применением DDD, когда в команде и без него никто не может сделать простое понятное решение.
Штука с generics в том, что они абсолютная пушка, например, в C#. Но в JS они были всегда, вся эта утиная типизация, все итак уже generic. Это одна из самых сложных тем, которой надо учить коллег фронтендеров, знакомящихся с TS. Дается тяжело, хотя они всегда так и работали, просто не явно и это им ничего не стоило.
Презентовали эту идею опытным иностранным коллегам, все задумались, было очень интересно это отметить. Всем показалось, что есть смысл, но ведь так никто не делает. Ещё было интересное опасение, что при таком подходе, когда очень просто расширять код без изменения клиентов, куда проще писать говнокод.
Мы решили делать так для начала только в своей команде. У нас там нет TS, поэтому выглядит очень изящно и джунам проще сориентироваться, пока книга «Чистый код» ещё не осилена. Пробуем в другом проекте, где есть TS, выглядит куда более громоздко.
TS сам по себе не панацея. Из нашего опыта большие проблемы проекта лежат не в плоскости наличия или отсутствия проверки типов. Скорее в области архитектуры проекта, тестируемости решения, loose coupling и документирования переиспользуемых паттернов.
У тех команд, кто решили попробовать этот подход получит распространение. Также как и TS у тех, кто решил на него переехать и тд и тп.
Мы бы советовали прочитать книгу Пять пороков команды. То что вы упомянули это один из пороков: Необязательность. Из него вытекает саботаж. Это необходимо однозначно пресекать.
Если у вас здоровая функционирующая эффективная команда, то и новый член этой команды либо адаптируется под общие цели команды, либо уйдет из неё, несумев предпочесть цели команды своим личным. Ну или команда развалится, такое тоже возможно.
Не соглашусь, что отсутствие TypeScript делает проект хуже без вариантов. В статье осознанно не затронуто, но для данного подхода намного элегантнее получается как раз без TypeScript.
Вот такой типовой пример с TS, когда инлайним тип:
Можно оценить тонкий привкус синтаксиса с опциональными пропертями, которые нужны, чтобы подружить значения по умолчанию с TS. Это ещё не докручено значение по умолчанию самого объекта :)
По последней ремарке насчет 2-3 параметров. После интенсивного обсуждения мы, как команда, решили применять даже для 1 аргумента. Это делает принятие решения не opinionated. Ревью тоже очевидно. Главным аргументом было то, что нужен опыт, чтобы принимать решение о том, что в этом конкретном случае пора менять на объект и рефакторить. Этому сложно научить начинающих специалистов. Опытные все решают по-разному. Наше решение полная единообразность в этом случае.
Хотим написать отдельную статью про это! Увидели несколько запросов, кажется, актуальная тема. А пока мы пишем, можем посоветовать почитать книгу Владимира Савельева «Статистика и котики»: забавная, легкая в чтении, дает базу статистических знаний и имеет много рисунков котов. В общем, все как мы любим :)
Кажется, что большая часть математических курсов все же рассчитана на более начинающих, чем на продвинутый уровень. Тут скорее профильная литература требуется. Посоветовать ее можно только зная, что уже было пройдено и какие есть слепые зоны. Математическое образование все же вещь довольно обширная: не до конца понятно, где начинается и где заканчивается. Подумаем еще над вашим вопросом, спасибо! Очень хочется собрать статью с курсами, литературой, видео по математике, анализу данных, MLOps и прочему необходимому с разделением на уровни имеющихся знаний.
Набираться знаний и опыта, конечно! Подсматривать best practices на докладах от умных дяденек и тетенек из DS, читать книги по области, применять все полученные знания в своих pet-проектах, искать образовательные ресурсы, в которых рассказывают о навыках, требующихся на должность junior DS. Главное здесь — составить roadmap и двигаться по нему, непрерывно проходя собеседования, чтобы найти свои слабые места и подтянуть знания в этих областях. А там глядишь рано или поздно и заветный оффер придет, а на новом месте работы можно будет поискать ментора.
Согласны, такие навыки приобретаются в процессе работы. Эту статью писали, чтобы показать юным датасаентистам с курсов, с какими ужасами им придется столкнуться, снять с них розовые очки и донести, что обещанные горы в алмазах придут далеко не сразу, и для этого надо будет очень много учиться, работать и развиваться.
Определенно, research позиции подразумевают более серьезное знание математики, но даже практическое применение уже существующих методов требует понимания внутренних процессов. Например, на этапах EDA, предобработки данных и feature extraction требуются статистические знания. Может быть, это не до конца вписывается в понятие "сложные математические навыки", но определенная доля знаний в плоскости математики нужна и здесь :)
Почему вы так думаете? Кажется, что изучение новых инструментов занимает определенное количество времени, особенно, если до этого использовались более высокоуровневые API для построения и обучения моделей, а в процессе возникла необходимость в самостоятельном описании процесса обучения.
Не согласимся с вами в полной мере. Безусловно, общение - важная часть работы не только для DS, но и для любого специалиста в IT. Но только общаться - недостаточно, важно решать задачу. Для хорошего DS важно не вслепую тыкаться и постоянно перебирать всевозможные параметры и алгоритмы почти рандомно, а собирать решение, опираясь на теоретические знания и предыдущий опыт разработки (те самые хард скиллс).
Да, так и есть! Но я здесь рассказал про одно из более простых решений, где от вас не требуется разбираться в работе браузерных расширений в Playwright и писать классы для работы с ними. Суть в том, что есть готовое решение для тех, кто не хочет тратить время на то, что уже есть. Если вам нужно протестировать Phantom, то да, без собственных наработок здесь уже не обойтись, т.к. под него, увы, еще нет готовых решений
Да, так и есть :) Иногда не создаем типы, чтобы использовать их 1 раз. Хотелось честно показать, как не очень это может выглядеть вместе с TS.
TS не защитит вас в рантайме. Если придет что-то другое, то вы это TS не излечите и он вам об этом ничего не скажет.
Интеграционные тесты API должны гарантировать, что эта штука все ещё работает. Тесты API на контракт тоже должны быть здесь. e2e тесты клиента должны проверять полную интеграцию для минимального user happy path.
Недавно мы начали разрабатывать проукты через TDD, в довольно строгом смысле. Это требует наличия инфраструктуры, которая поддержвает все уровни тестов, включая линтинг от TS.
Как мы решаем тот случай, о котором вы говорите:
API предоставляет контракт в виде npm пакета с автосгенерированным TS кодом (в нашем случае поверх gRPC и protobuff). Следуем SemVer: патч, фича или мажорный апдейт контракта сервиса.
BFF на NestJS использует пакет с типами от API везде в коде. Не создаем дополнительные слои DTO.
В контроллерах в обязательном порядке маппим данные перед отправкой на клиент, чтобы в рантайме не ушло больше чем мы хотим.
Если меняется, используемый API, то обновляем его npm-пакет и смотрим отвалилось ли что по TS линтингу и тестам всех остальных уровней: юнит тесты BFF, интеграционные тесты BFF, e2e тесты клиента.
При этом во фронте у нас проект без TS.
В целом мне в BFF очень нравится такой флоу работы. В фронтенде при работе со своим BFF мы стараемся идти в сторону только обратно совместимых изменений API, чтобы не афектить старый UI и новый UI. И только после того, как старого не остается ни у кого, тогда клинапим BFF обратнонесовместимым обновлением. Следуем подходу двухфазного деплоя.
Не соглашусь с вами. Не буду размышлять на тему что такое react way и есть ли он вообще. Или на тему того, что хуки это может быть очень спорное решение и некоторые простые вещи приходится писать через одно место.
Нельзя ориентироваться на useState и считать это истинным react way. Это просто одна из многих функций и вот она так реализована и это имеет смысл. Это не значит, что все надо делать так на автомате.
А вот у нас коллегам было не так очевидно, что объект лучше, чем массив. Было мнение что массив, как у useState, это react way.
Мы долго обсуждали оставить ли исключение для случая с 1 параметром, особенно, если это какая-то id. Также и про 2 параметра. Сошлись на том, что всем проще всегда оборачивать в объект, чем принимать такие решения. С ростом числа аргументов вовремя решаться на рефакторинг не всегда удается даже опытным разрабочикам. А ещё не ясно как проводить ревью.
Решили проблему не решать :)
Работаем с зарубежными «большими пацанами». 3 года назад TS был в опале, сейчас ситуация поменялась, он используется по умолчанию. Есть большая проблема того, что те, кто не писал бекенд и начал сразу с фронтенда и работает давненько просто используют TS ужасно и становится хуже чем без него. Хотя опять же это скорее не проблема TS как такового, а проблема Engineering Excellence для этой конкретной команды.
Мы бы сказали, что если команда не может выстроить нормальную архитектуру решения без TS, то с ним станет все только хуже. Такая же история с применением DDD, когда в команде и без него никто не может сделать простое понятное решение.
Штука с generics в том, что они абсолютная пушка, например, в C#. Но в JS они были всегда, вся эта утиная типизация, все итак уже generic. Это одна из самых сложных тем, которой надо учить коллег фронтендеров, знакомящихся с TS. Дается тяжело, хотя они всегда так и работали, просто не явно и это им ничего не стоило.
Презентовали эту идею опытным иностранным коллегам, все задумались, было очень интересно это отметить. Всем показалось, что есть смысл, но ведь так никто не делает. Ещё было интересное опасение, что при таком подходе, когда очень просто расширять код без изменения клиентов, куда проще писать говнокод.
Мы решили делать так для начала только в своей команде. У нас там нет TS, поэтому выглядит очень изящно и джунам проще сориентироваться, пока книга «Чистый код» ещё не осилена. Пробуем в другом проекте, где есть TS, выглядит куда более громоздко.
Посмотрим labeled tuples, спасибо :)
TS сам по себе не панацея. Из нашего опыта большие проблемы проекта лежат не в плоскости наличия или отсутствия проверки типов. Скорее в области архитектуры проекта, тестируемости решения, loose coupling и документирования переиспользуемых паттернов.
У тех команд, кто решили попробовать этот подход получит распространение. Также как и TS у тех, кто решил на него переехать и тд и тп.
Мы бы советовали прочитать книгу Пять пороков команды. То что вы упомянули это один из пороков: Необязательность. Из него вытекает саботаж. Это необходимо однозначно пресекать.
Если у вас здоровая функционирующая эффективная команда, то и новый член этой команды либо адаптируется под общие цели команды, либо уйдет из неё, несумев предпочесть цели команды своим личным. Ну или команда развалится, такое тоже возможно.
Не соглашусь, что отсутствие TypeScript делает проект хуже без вариантов. В статье осознанно не затронуто, но для данного подхода намного элегантнее получается как раз без TypeScript.
Вот такой типовой пример с TS, когда инлайним тип:
Можно оценить тонкий привкус синтаксиса с опциональными пропертями, которые нужны, чтобы подружить значения по умолчанию с TS. Это ещё не докручено значение по умолчанию самого объекта :)
По последней ремарке насчет 2-3 параметров. После интенсивного обсуждения мы, как команда, решили применять даже для 1 аргумента. Это делает принятие решения не opinionated. Ревью тоже очевидно. Главным аргументом было то, что нужен опыт, чтобы принимать решение о том, что в этом конкретном случае пора менять на объект и рефакторить. Этому сложно научить начинающих специалистов. Опытные все решают по-разному. Наше решение полная единообразность в этом случае.
Кажется, что это решается значением по умолчанию так:
Хотим написать отдельную статью про это! Увидели несколько запросов, кажется, актуальная тема. А пока мы пишем, можем посоветовать почитать книгу Владимира Савельева «Статистика и котики»: забавная, легкая в чтении, дает базу статистических знаний и имеет много рисунков котов. В общем, все как мы любим :)
Кажется, что большая часть математических курсов все же рассчитана на более начинающих, чем на продвинутый уровень. Тут скорее профильная литература требуется. Посоветовать ее можно только зная, что уже было пройдено и какие есть слепые зоны. Математическое образование все же вещь довольно обширная: не до конца понятно, где начинается и где заканчивается. Подумаем еще над вашим вопросом, спасибо! Очень хочется собрать статью с курсами, литературой, видео по математике, анализу данных, MLOps и прочему необходимому с разделением на уровни имеющихся знаний.
Набираться знаний и опыта, конечно! Подсматривать best practices на докладах от умных дяденек и тетенек из DS, читать книги по области, применять все полученные знания в своих pet-проектах, искать образовательные ресурсы, в которых рассказывают о навыках, требующихся на должность junior DS. Главное здесь — составить roadmap и двигаться по нему, непрерывно проходя собеседования, чтобы найти свои слабые места и подтянуть знания в этих областях. А там глядишь рано или поздно и заветный оффер придет, а на новом месте работы можно будет поискать ментора.
Согласны, такие навыки приобретаются в процессе работы. Эту статью писали, чтобы показать юным датасаентистам с курсов, с какими ужасами им придется столкнуться, снять с них розовые очки и донести, что обещанные горы в алмазах придут далеко не сразу, и для этого надо будет очень много учиться, работать и развиваться.
Определенно, research позиции подразумевают более серьезное знание математики, но даже практическое применение уже существующих методов требует понимания внутренних процессов. Например, на этапах EDA, предобработки данных и feature extraction требуются статистические знания. Может быть, это не до конца вписывается в понятие "сложные математические навыки", но определенная доля знаний в плоскости математики нужна и здесь :)
Почему вы так думаете? Кажется, что изучение новых инструментов занимает определенное количество времени, особенно, если до этого использовались более высокоуровневые API для построения и обучения моделей, а в процессе возникла необходимость в самостоятельном описании процесса обучения.
Хотели бы скорее написать об этом отдельную статью, в которой собрать всё, что изучали сами, но сходу можем назвать следующее:
1) хороший курс по основам машинного обучения от ВШЭ: https://openedu.ru/course/hse/INTRML/;
2) лекции ШАД, по ссылке, например, по глубокому обучению, но на самом деле их лекций гораздо больше в open source: https://academy.yandex.ru/journal/kurs-lektsiy-shad-po-glubinnomu-obucheniyu;
3) курс от ods.ai по основам ml: https://mlcourse.ai/book/index.html, также у ребят скоро начинается mlops курс, тоже можем посоветовать записаться: https://ods.ai/tracks/ml-in-production-spring-23
Очень много ресурсов по этой теме сейчас и, к тому же, достаточно хороших.
Не согласимся с вами в полной мере. Безусловно, общение - важная часть работы не только для DS, но и для любого специалиста в IT. Но только общаться - недостаточно, важно решать задачу.
Для хорошего DS важно не вслепую тыкаться и постоянно перебирать всевозможные параметры и алгоритмы почти рандомно, а собирать решение, опираясь на теоретические знания и предыдущий опыт разработки (те самые хард скиллс).
Да, так и есть! Но я здесь рассказал про одно из более простых решений, где от вас не требуется разбираться в работе браузерных расширений в Playwright и писать классы для работы с ними. Суть в том, что есть готовое решение для тех, кто не хочет тратить время на то, что уже есть.
Если вам нужно протестировать Phantom, то да, без собственных наработок здесь уже не обойтись, т.к. под него, увы, еще нет готовых решений