Часть работы уже переведена в централизованные системы учёта, но не вся. Это обусловлено большим количеством заказчиков с совершенно разными требованиями к учёту проведённых работ. Поэтому есть такая система как СУП – чтобы работы учитывались внутри IBS. Далеко не все проекты ограничиваются банальным использованием таск-трекеров.
Факт не является фейком, потому что часы списываются сотрудниками самостоятельно в меньшей части проектов. Обычно этим занимается руководитель проекта, а значит подгона часов нет.
Остальные пункты также не являются возможными в реализации в связи с разноплановыми видами работ на проектах. Если бы управление проектом сводилось к правильной настройке таск-трекера, то это можно было бы реализовать.
Закрывающие документы к проектам и прочая отчётность тоже сильно зависит от заказчика и реализовываемого проекта и часто меняются. Поэтому настройка генерации всех форматов документов в общей системе не является целесообразной.
Спасибо за ваши комментарии. Действительно, в начале статьи следовало определиться с определениями.
Итак, стейт-менеджер - это глобальное хранилище данных внутри приложения или сайта. Он помогает управлять данными внутри объекта состояния (state) и упрощает работу с кодом.
Чем он точно должен обладать?
- набор переменных,
- набор функций для изменения этих переменных,
- наблюдатель, который позволяет вам подписаться на изменения этих самых переменных.
Все остальные возможности, которые даруют нам перечисленные технологии - это разновидности имплементации стейт-менеджеров.
При подготовке статьи я пользовалась материалами, в которых были перечислены популярные пакеты для решения вопроса управлением состояния. Плюс посмотрела те, которые были у самой на слуху. Честно говоря, про react-query немного запамятовала.
Tanstack Query - 4 747 907 раз скачали наши коллеги за неделю. А это значит, что технология должна была занять в моем рейтинге почетное третье место. Думаю, это отличный повод задуматься о второй части статьи с перечислениями "второго эшелона":
Tanstack Query,
Jotai (1 339 512 скачиваний в неделю),
Recoil (559 315 скачиваний в неделю),
Effector (43 011 скачиваний в неделю),
Reatom (ему конечно еще следует подтянуть свои позиции😊 - 3 143 (скачиваний в неделю)),
При определении претендентов, которые должны были войти в пятерку мы брали именно популярность технологии, то есть количество скачиваний за неделю. Так, например, пакет redux-saga на 28.02.2025 года скачали 1 138 513 раз. В связи с этим он не попал в нашу выборку.
По поводу плюсов саг, которые вы перечислили, - это безусловное преимущество данной технологии. Но в этом и соль выбора) Каждый подбирает решение, которое будет удовлетворять текущим потребностям проекта.
Спасибо за замечание! Формулировки действительно могли показаться противоречивыми. В случае «состояния гонки» (race condition) речь идёт не о буквальном одновременном выполнении задач, а о возможных конфликтах при доступе к одним и тем же данным, когда завершение задач зависит от их порядка. Это важно учитывать в асинхронных системах. Что касается «параллельно в очереди задач», то речь идёт о том, что задачи могут быть инициированы одновременно, но их выполнение в движке JavaScript происходит строго последовательно в рамках одного потока. Условная параллельность здесь описывает именно одновременное нахождение задач в очереди, а не их реальное параллельное выполнение.
Спасибо за вопрос! В статье в целом параллельность идёт условная. Первая функция выполняется, создаёт таймер через API браузера и выходит из стека вызовов, освобождая место для следующей задачи. Тем временем таймер попадает в очередь задач. Когда основной поток освобождается, задачи из этой очереди начинают выполняться. В результате создаётся впечатление одновременного выполнения, хотя на самом деле задачи запускаются последовательно, но их завершение может пересекаться. Это связано с особенностями работы цикла событий.
Спасибо за обстоятельный комментарий. Скажи, а что в работе тимлида, по-твоему, стоит поподробнее осветить в следующих статьях? О чём бы ты хотел почитать?
детализации как найти качественного тестировщика(разработчика) и удержать его , сноска с заголовка, не нашел
Спасибо за подробный комментарий. Уточню, что эту статью написали с фокусом именно на общем процессе поиска, а не подробностях отбора.
Правильно ли тебя понял, что стоит опубликовать продолжение — уже с подробностями и нюансами того, как найти действительно классного тестировщика или разработчика из всей массы резюме, что прилетают в ответ на вакансию? Напиши плз, о чём бы ты хотел узнать?
Ситуации бывают разные, и порой уже по резюме кандидата: компаниям, в которых он работал, проектам, в которых он участвовал, понятен его уровень. Но, в общем, согласны, тех.собеседование — важный этап. Мы, кстати, не так уж и часто его пропускаем.
Про пункт 5. Да, бывает. Чтобы избежать взаимных недомолвок и недопониманий крайне рекомендуем все вопросы поднимать, обсуждать на собеседовании, чтобы понимать подходит ли вам компания/проект/руководитель согласно вашим ценностям и карьерному развитию.
В большей степени мы оцениваем хард скиллы, отдельно компетенции по софтам не включены, т.к. для их оценки применяется как правило другая методика. Но мы используем в каждой компетенции кейсовые вопросы, где для принятия верного решения оцениваемому нужно проявить в том числе софтовые скиллы, чтоб верно оценить ситуацию.
Хорошо, что это не про нас) Ачивки за Гонку разработчиков начислят после завершения конкурса и подведения итогов.
Хитро!
А вот это интересно было бы почитать дальше)
Часть работы уже переведена в централизованные системы учёта, но не вся. Это обусловлено большим количеством заказчиков с совершенно разными требованиями к учёту проведённых работ. Поэтому есть такая система как СУП – чтобы работы учитывались внутри IBS. Далеко не все проекты ограничиваются банальным использованием таск-трекеров.
Факт не является фейком, потому что часы списываются сотрудниками самостоятельно в меньшей части проектов. Обычно этим занимается руководитель проекта, а значит подгона часов нет.
Остальные пункты также не являются возможными в реализации в связи с разноплановыми видами работ на проектах. Если бы управление проектом сводилось к правильной настройке таск-трекера, то это можно было бы реализовать.
Закрывающие документы к проектам и прочая отчётность тоже сильно зависит от заказчика и реализовываемого проекта и часто меняются. Поэтому настройка генерации всех форматов документов в общей системе не является целесообразной.
Спасибо за ваши комментарии. Действительно, в начале статьи следовало определиться с определениями.
Итак, стейт-менеджер - это глобальное хранилище данных внутри приложения или сайта. Он помогает управлять данными внутри объекта состояния (state) и упрощает работу с кодом.
Чем он точно должен обладать?
- набор переменных,
- набор функций для изменения этих переменных,
- наблюдатель, который позволяет вам подписаться на изменения этих самых переменных.
Все остальные возможности, которые даруют нам перечисленные технологии - это разновидности имплементации стейт-менеджеров.
При подготовке статьи я пользовалась материалами, в которых были перечислены популярные пакеты для решения вопроса управлением состояния. Плюс посмотрела те, которые были у самой на слуху. Честно говоря, про react-query немного запамятовала.
Tanstack Query - 4 747 907 раз скачали наши коллеги за неделю. А это значит, что технология должна была занять в моем рейтинге почетное третье место. Думаю, это отличный повод задуматься о второй части статьи с перечислениями "второго эшелона":
Tanstack Query,
Jotai (1 339 512 скачиваний в неделю),
Recoil (559 315 скачиваний в неделю),
Effector (43 011 скачиваний в неделю),
Reatom (ему конечно еще следует подтянуть свои позиции😊 - 3 143 (скачиваний в неделю)),
и т.д.
При определении претендентов, которые должны были войти в пятерку мы брали именно популярность технологии, то есть количество скачиваний за неделю. Так, например, пакет redux-saga на 28.02.2025 года скачали 1 138 513 раз. В связи с этим он не попал в нашу выборку.
По поводу плюсов саг, которые вы перечислили, - это безусловное преимущество данной технологии. Но в этом и соль выбора) Каждый подбирает решение, которое будет удовлетворять текущим потребностям проекта.
Спасибо за замечание! Формулировки действительно могли показаться противоречивыми. В случае «состояния гонки» (race condition) речь идёт не о буквальном одновременном выполнении задач, а о возможных конфликтах при доступе к одним и тем же данным, когда завершение задач зависит от их порядка. Это важно учитывать в асинхронных системах. Что касается «параллельно в очереди задач», то речь идёт о том, что задачи могут быть инициированы одновременно, но их выполнение в движке JavaScript происходит строго последовательно в рамках одного потока. Условная параллельность здесь описывает именно одновременное нахождение задач в очереди, а не их реальное параллельное выполнение.
Спасибо за вопрос! В статье в целом параллельность идёт условная. Первая функция выполняется, создаёт таймер через API браузера и выходит из стека вызовов, освобождая место для следующей задачи. Тем временем таймер попадает в очередь задач. Когда основной поток освобождается, задачи из этой очереди начинают выполняться. В результате создаётся впечатление одновременного выполнения, хотя на самом деле задачи запускаются последовательно, но их завершение может пересекаться. Это связано с особенностями работы цикла событий.
Понял. Про Agile и Scrum интересное мнение.
В любом случае спасибо, что нашли время для столь обстоятельного комментария с конструктивной критикой.
Разобрались с коллегами из рекрутинга, говорят, уже связались с тобой. Извини за просадку в коммуникациях. Ещё раз спасибо, что написал о проблеме. 👍
Спасибо за комментарий. Поделись плз, чего о работе тимлида не хватает на Хабре?
Про «зачем это» понятно, примем к сведению. А как насчёт «почему этого ещё нет на Хабре?»?
Какие именно?
Спасибо за обстоятельный комментарий. Скажи, а что в работе тимлида, по-твоему, стоит поподробнее осветить в следующих статьях? О чём бы ты хотел почитать?
Да, хорошие темы. Спасибо за наводку!
Спасибо за подробный комментарий. Уточню, что эту статью написали с фокусом именно на общем процессе поиска, а не подробностях отбора.
Правильно ли тебя понял, что стоит опубликовать продолжение — уже с подробностями и нюансами того, как найти действительно классного тестировщика или разработчика из всей массы резюме, что прилетают в ответ на вакансию? Напиши плз, о чём бы ты хотел узнать?
Спасибо, что написал. Ответил тебе в личку, чтобы разобраться с ситуацией и сделать так, чтобы такого больше не повторялось.
Мы выдаём список, а не литературу)
Ситуации бывают разные, и порой уже по резюме кандидата: компаниям, в которых он работал, проектам, в которых он участвовал, понятен его уровень. Но, в общем, согласны, тех.собеседование — важный этап. Мы, кстати, не так уж и часто его пропускаем.
Рады, что вы оценили наш туториал.
Про пункт 5. Да, бывает. Чтобы избежать взаимных недомолвок и недопониманий крайне рекомендуем все вопросы поднимать, обсуждать на собеседовании, чтобы понимать подходит ли вам компания/проект/руководитель согласно вашим ценностям и карьерному развитию.
В большей степени мы оцениваем хард скиллы, отдельно компетенции по софтам не включены, т.к. для их оценки применяется как правило другая методика. Но мы используем в каждой компетенции кейсовые вопросы, где для принятия верного решения оцениваемому нужно проявить в том числе софтовые скиллы, чтоб верно оценить ситуацию.