Во многих компаниях, занимающихся заказной разработкой ПО, исторически сложилось правило вести тайм-трекинг.

И эта привычка настолько укоренилась, что работодателям сложно представить, «как ещё узнать, что люди, действительно, работают?!»

Но в продуктовых компаниях время трекают редко. Как им это удаётся?! В этой статье хочу попробовать вообразить, какие шестерёнки позволяют работать параллельному миру разработки без тайм-трекинга.

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

Для начала давайте разберёмся, что именно мы собираемся сочетать — дадим определения. Может быть, уже одно это хорошо прояснит некоторые вопросы.

Недавно один мой знакомый, который работает в большой европейской технологической компании архитектором, стал больше заниматься управлением проектами. И попросил меня помочь с планированием. Я предложил ему использовать Reliable Scrum. Тема обширная, и я не ставлю целью всю её здесь раскрыть. Но в этой статье хочу рассказать про некоторые условия, при которых можно попробовать этот интересный инструмент.

Иногда в своё React-приложение нужно встроить сторонний компонент, который не работает с React и часто оказывается императивным.

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

Верным признаком того, что компонент нужно обернуть в декларативный компонент является обилие useEffect-ов, где проверяются разные сочетания параметров компонента. И в зависимости от этих сочетаний вызываются соответствующие методы компонента.

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

Итак, настал тот moment, когда вам нужно работать с датами в разных часовых поясах (Новый год же!), а ваш архитектор/начальник не разрешает использовать Moment Timezone или Luxon, потому что они увеличат размер вашей сборки, а для вашего проекта важно, чтобы UI грузился быстро. Или потому что вы делаете небольшую задачу, и непонятно пока, будет ли расширение работы с часовыми поясами.

Поэтому и основной сценарий будет тоже UI: когда с бэкенда приходит таймстэмп, (см. определение ниже) и нужно работать с ним в разных часовых поясах. Обратное преобразование, когда по местному времени и часовому поясу, наоборот, нужно получить таймстэмп, я рассмотрю очень коротко.

По аналогии с принципом LSP из ООП, при работе с функциями в Typescript стоит придерживаться следующего принципа:

Принимая колбэк с меньшим числом аргументов, оборачивайте его, прежде, чем передавать его далее в качестве колбэка с большим числом аргументов.