Comments 15
Подход впечатляет.
Как удалось договориться с бизнесом о необходимости перехода?
Сильно ли повлияло это мероприятие на регулярность доставки фич?
По моему опыту получить ресурсы на подобное мероприятие очень непросто, ибо «а кто будет фичи пилить, у нас вон сколько всего на подходе». В итоге получается жонглирование вприсядку. Похожую вещь тоже делали, но очень размазанно по времени (когда было окно в потоке фич) и без такого четкого плана.
Как удалось договориться с бизнесом о необходимости перехода?
Сильно ли повлияло это мероприятие на регулярность доставки фич?
По моему опыту получить ресурсы на подобное мероприятие очень непросто, ибо «а кто будет фичи пилить, у нас вон сколько всего на подходе». В итоге получается жонглирование вприсядку. Похожую вещь тоже делали, но очень размазанно по времени (когда было окно в потоке фич) и без такого четкого плана.
Спасибо!
В нашем случае это помогло обеспечить стабильность кодовой базы, безопасное переиспользование компонентов, что позволило нам ускорить работу над проектами.
Что касается доставки фичей — за счет распределения задач мы не замедляли темпы: пока часть команды занималась продуктовыми задачами м сразу писали код на typescript, а другая часть команды — переводила код на TypeScript. Грамотный баланс в данном случае достигался за счет планирования нагрузки и еженедельной оценки прогресса. C технической точки зрения в любой момент любого участник проекта мог переключить на другие задачи, остановить процесс перевода и возобновить работу, когда появлялось время.
Также мы изначально выделили время на техническое планирование, чтобы сразу определить, насколько можно разделить проекты на этапы и впоследствии изолировано выполнять их.
В нашем случае это помогло обеспечить стабильность кодовой базы, безопасное переиспользование компонентов, что позволило нам ускорить работу над проектами.
Что касается доставки фичей — за счет распределения задач мы не замедляли темпы: пока часть команды занималась продуктовыми задачами м сразу писали код на typescript, а другая часть команды — переводила код на TypeScript. Грамотный баланс в данном случае достигался за счет планирования нагрузки и еженедельной оценки прогресса. C технической точки зрения в любой момент любого участник проекта мог переключить на другие задачи, остановить процесс перевода и возобновить работу, когда появлялось время.
Также мы изначально выделили время на техническое планирование, чтобы сразу определить, насколько можно разделить проекты на этапы и впоследствии изолировано выполнять их.
что позволило нам ускорить работу над проектами.
поржал…
Нахуя вы это все делали? Зачем нужен TS в ui компонентах и в принципе на фронте? (кто будет минусить — просьба обосновать в комментах)
Если делаешь что-то сложнее туду-листа, то у TS сплошные преимущества
Так разве не для этого все разбивается на небольшие компоненты, чтобы из них можно было собрать хоть туду-лист, хоть космодром? Поддерживаю ответившего выше, про «ускорить разработку» заявление сомнительное. Prop-types обычно хватает за глаза.
Попробую рассказать подробнее про ускорение разработки на TypeScript и про Prop-types в React UI компонентах :)
Сразу скажу, что примеры будут из личного опыта, полученного на проектах разного масштаба и в различных командах.
Prop-types — это проверка в run-time. То есть, чтобы проверить, что интерфейс компонента актуален при внесении изменений в ветку у нас есть, как минимум, 2 стратегии:
1) открыть браузер и проверить в консоли каждую страницу. Если мы поменяли интерфейс базового компонента и он используется в 100 страницах? Или для показа компонента надо будет выполнить определенные условия (кликнуть на третьем экране вниз, загрузить фото, ввести пароль). Это будет очень затратно по времени. Это становится явной проблемой, когда необходимо поддерживать и обновлять UI-библиотеки на средних и больших проектах.
2) Запустить песочницу/библиотеку компонентов с документацией. Допустим, что у нас все компоненты и их интерфейсы видны и описаны и их можно проверить либо руками, либо через visual regression tests сравнить изменения. Это может быть быстрее первого способа, но все равно займет какое-то время и не гарантирует однозначного результата.
Если интерфейс компонента на TypeScript, то проверка на типы будет при сборке проекта и также по запросу введением одной команды в консоли. Мы сразу получаем все возможные конфликты и проблемы в отчете проверки при автоматическом проходе по всем компонентам. Это самый быстрый способ. Это ощущается и в масштабе, когда один разработчик работает над проектом и когда в команде 10+ разработчиков, которые параллельно доставляют различные фичи.
Априори мы исходим из того, что проверка типов при разработке — это минимальная и быстрая проверка на явные баги. А так как эта проверка в TypeScript работает сразу из коробки — мы снижаем нагрузку на разработчиков и у нас появляется больше времени на разработку нового функционала, так как цикл разработки ускоряется без риска потери качества.
Более детальный пример — это проверка типов при конфликтах веток. Решение конфликтов занимает меньше времени за счет автоматической проверки и всплывающих подсказок в редакторах. В обоих примерах смена типов также может быть автоматизирована.
И главный момент — Prop-types не гарантирует строго соблюдения правил.
Тем самым TypeScript позволяет ускорить разработку и поддержку приложений в части UI, даже если мы говорим об очень простых компонентах.
Конечно, внедрение TypeScript потребует определенного времени для команды, но это уже другой аспект, который я уже описал в статье)
Сразу скажу, что примеры будут из личного опыта, полученного на проектах разного масштаба и в различных командах.
Prop-types — это проверка в run-time. То есть, чтобы проверить, что интерфейс компонента актуален при внесении изменений в ветку у нас есть, как минимум, 2 стратегии:
1) открыть браузер и проверить в консоли каждую страницу. Если мы поменяли интерфейс базового компонента и он используется в 100 страницах? Или для показа компонента надо будет выполнить определенные условия (кликнуть на третьем экране вниз, загрузить фото, ввести пароль). Это будет очень затратно по времени. Это становится явной проблемой, когда необходимо поддерживать и обновлять UI-библиотеки на средних и больших проектах.
2) Запустить песочницу/библиотеку компонентов с документацией. Допустим, что у нас все компоненты и их интерфейсы видны и описаны и их можно проверить либо руками, либо через visual regression tests сравнить изменения. Это может быть быстрее первого способа, но все равно займет какое-то время и не гарантирует однозначного результата.
Оффтоп про конлфикты типов в UI компонентах
Тут можно подробнее углубиться в конфликты типов при отображении UI компонентов, если будет интересно, то отдельно приведу примеры.
Если интерфейс компонента на TypeScript, то проверка на типы будет при сборке проекта и также по запросу введением одной команды в консоли. Мы сразу получаем все возможные конфликты и проблемы в отчете проверки при автоматическом проходе по всем компонентам. Это самый быстрый способ. Это ощущается и в масштабе, когда один разработчик работает над проектом и когда в команде 10+ разработчиков, которые параллельно доставляют различные фичи.
Априори мы исходим из того, что проверка типов при разработке — это минимальная и быстрая проверка на явные баги. А так как эта проверка в TypeScript работает сразу из коробки — мы снижаем нагрузку на разработчиков и у нас появляется больше времени на разработку нового функционала, так как цикл разработки ускоряется без риска потери качества.
Более детальный пример — это проверка типов при конфликтах веток. Решение конфликтов занимает меньше времени за счет автоматической проверки и всплывающих подсказок в редакторах. В обоих примерах смена типов также может быть автоматизирована.
И главный момент — Prop-types не гарантирует строго соблюдения правил.
Явный пример
Казалось бы — в текущем примере мы ничего не испортили. Потому как внутри UI компонента простой render. Однако если в компоненте были какие-то изменения текста — убирания пробелов, строка с большой буквы), то в этом случае мы потратим значительное время на проверку типов или рискуем пропустить код с ошибкой на Production. А в случае с TypeScript — мы в момент сборки знаем о проблеме
Казалось бы — в текущем примере мы ничего не испортили. Потому как внутри UI компонента простой render. Однако если в компоненте были какие-то изменения текста — убирания пробелов, строка с большой буквы), то в этом случае мы потратим значительное время на проверку типов или рискуем пропустить код с ошибкой на Production. А в случае с TypeScript — мы в момент сборки знаем о проблеме
Тем самым TypeScript позволяет ускорить разработку и поддержку приложений в части UI, даже если мы говорим об очень простых компонентах.
Конечно, внедрение TypeScript потребует определенного времени для команды, но это уже другой аспект, который я уже описал в статье)
Спасибо «кэп»! По делу есть что сказать?
Зачем нужен TS в ui компонентах и в принципе на фронте?Типизированные payload в Redux и сигнатуры DispatchProps в компонентах, например. Гораздо удобнее посмотреть всё в подсказках IDE, чем идти и читать, что и в каком формате где-то отдаётся.
Возможно я в начале резко выразился, кто-то меня понял, кто-то увы… Я не против TS и не бомблю против/за него, как некоторые… Сам его использую. Отсюда у меня и возник вопрос. Кого не спроси — ну это же типизация(это круто, модно)… и на этом все, никаких аргументов нормальных…
Поздравляю, Вы не зашоренный, как многие ). Многие выбирают TS лишь по причине модности, а потом начинают выдумывать причины, чтобы его заюзать в проекте. Несколько лет назад, до широкого распространения ES6 он действительно был приятней в использовании ES5. На данный момент преимуществ у практически TS и не осталось. Но есть одна причина, иногда весьма существенная — за счет статической типизации он позволяет прилично сократить количество ошибок у слабых разработчиков. Если проект большой, тим лид также не силен(или нет времени), а подобных персонажей много — то выгода очевидна.
за счет статической типизации он позволяет прилично сократить количество ошибок у слабых разработчиковКогда-то я слышал то же самое про языки с отсутствием прямой работы с памятью, мол, настоящие профессионалы ошибки с двойным разыменовыванием указателей и выходом за пределы массивов не допускают. Что, конечно, полная чушь. Чем больше язык даёт пространства для допуска ошибок, тем больше этих ошибок будет, уровень квалификации тут роли не играет.
Динамическая типизация всегда будет выигрывать в скорости разработки против статической.А вы пользуетесь IDE?
Sign up to leave a comment.
Как перенести на TypeScript большую кодовую базу React UI-компонентов