На шаге 5 «Исключить назначенную задачу из графа» получается будут теряться зависимости между задачами, разве нет? Типа Задача Б зависит от Задачи А. Задачу А отдали Васе и, получается, можно Оле сразу отдать задачу Б, а ведь надо дождаться окончания А сначала.
Критическая цепь Голдратта из поста очень похоже на советский СПУ. Там и там предлагаются инструмент борьбы с неопределенностью. Мне советский вариант показался более понятным и последовательным.
Интересно, система Голдратта наша реализацию в каком-нибудь ПО?
Да, точно, в MS Project тоже такое умеет! Забыл упомянуть, т.к. на маке уже не первый десяток лет работаю, а там MS Project нет.
Разрыв задачи — интересная штука. На практике, правда, редко когда так делаем, т.к. уходит дополнительное время на переключения, да и сами задачи стараемся короче формулировать. Поэтому сильно про такую штуку не думал.
В вашем алгоритме надо еще как-то отслеживать занятость исполнителя и временные сроки. Кажется, это довольно все усложнит.
О, шикарная теория, спасибо! Умели же делать и понятно объяснять.
Действительно, для полноты решения также надо выводить критический путь и добавить инструменты выставления неточных сроков. Последнее, кстати, в каком-то виде есть в Omniplan, там сроки вех вычисляются с помощью симуляции Монте-Карло.
Интересная тема про поздние сроки (запас времени для окончания работ по задаче) и в целом понятие резерва, такого я нигде еще не видел.
Вообще меня это вдохновило попробовать сделать не Ганта для работы с проектом, а сетевые графики из системы в ролике.
Не форкали, но пару патчей накладывали, сопровождая их, конечно, соотв. PR в React Native. Там, кстати, весьма все дружелюбно и, как правило, в след. минорной версии были уже наши правки и убирали патчи.
Потому что в типовых приложениях, для которых используется RN, я не видел и не могу представить CPU intensive задачи. То есть 99% исходят из опыта и из понимания сферы «пригодности» фреймворков.
Если все же есть такая потребность, но у RN неплохая документация, как написать подключить к RN произвольный нативный модуль. Этим тоже мы нередко занимались, подключая внутренние нативные модули нашей компании.
Если ли же в вашем приложении процентное соотношение другое, то, конечно, стоит присмотреться к другим вариантам.
Первое. В статье приведены тесты производительности, там прогоняются CPU-intensive задачи. Я думаю, это невалидный аргумент в споре RN vs Flutter, т.к. на практике 99% всех задач, которые будут ставится перед RN или Flutter, не включают в себя сложных CPU задач.
Перейти на новый экран, сделать сетевой запрос, обработать JSON ответа на пару сотню Кб, перерендерить пару десятков вложенных View — вот типичные задачи для ниши приложений, для которых используются эти фреймворки.
Если вы их используете для создания игр, real time machine learning, 3d графики и пр., то вы просто используете неподходящий инструмент.
Второе. У меня за плечами разработка большого приложения (порядка 30 экранов) с команде из 3 разработчиков, которое работает на базе RN и при этом занимало и занимает топовые позиции в каталоге App Store. Мне кажется, это подтверждает аргумент, что можно делать крутые приложения на RN, которые нравятся пользователям.
Это конечно крайность, но действительно встречаются люди считающие тех кто пишет без смайликов, эмодзи и с точками — токсичными и грубыми.
А у меня такая же нога, но не болит.) Я, честно, за 6 лет работы в одной из крупнейших ИТ-корпораций РФ не встречал именно такого требования к общению с чей-либо стороны.
Пожалуй, если где-то есть культура со смещение в сторону абсурдной вежливости, то общее правило я для себя оставил таким же — не сошлись культурами, найди другую компанию. ИТ рынок сейчас очень большой.
В социальных системах никогда не получится переложить общение на категории чистого разума. Разработка продукта — это совершенно обычная социальная система и правила вежливости такие же.
Не вижу ничего плохого, чтобы показать коллеге, что я воспринимаю его как человека, а не как винтик в системе по доставке обновлений продукта. Очень важно показать, что ты «видишь» человека.
Антон, в своей статье, ты кидаешься из одной крайности в другую, приводя в качестве примера несуществующие абсурдные требования к вежливости, а потом сокрушаешься, что эти правила контр-продуктивны. Конкретно эти правила — да, конечно, но базовые правила вежливости гораздо проще.
Возможно, некоторые люди просто не видят этой черты, но есть же обратная связь. Ты вроде её получил сполна, чтобы скорректировать свое поведение. Если не хочешь принимать культуру компании, то почему бы всем не упростить жизнь и найти ту компанию, которая тебе больше подходит по культуре?
Откуда вы взяли свое представление о работе объектов в JS? Starche в ответе практически прав, базово так оно и не только в JS работает. Пруф от разработчиков V8 — v8.dev/blog/fast-properties
Честно говоря, ругать авторов open-source — это плохой тон. Они ничем никому не обязаны. Всё, что они делают — помогают другим (и себе в каком-то смысле). Можно ли ругать частные благотворительные организации, что есть еще нищие и голодные люди на планете?
Спасибо за статью. Возможно, я упустил, но неясно как вообще при такой архитектуре может быть быстрое чтение состояния того же пользователя? Каждый раз итерироваться по всем соотв. событиям?
Интересно, система Голдратта наша реализацию в каком-нибудь ПО?
Разрыв задачи — интересная штука. На практике, правда, редко когда так делаем, т.к. уходит дополнительное время на переключения, да и сами задачи стараемся короче формулировать. Поэтому сильно про такую штуку не думал.
В вашем алгоритме надо еще как-то отслеживать занятость исполнителя и временные сроки. Кажется, это довольно все усложнит.
Действительно, для полноты решения также надо выводить критический путь и добавить инструменты выставления неточных сроков. Последнее, кстати, в каком-то виде есть в Omniplan, там сроки вех вычисляются с помощью симуляции Монте-Карло.
Интересная тема про поздние сроки (запас времени для окончания работ по задаче) и в целом понятие резерва, такого я нигде еще не видел.
Вообще меня это вдохновило попробовать сделать не Ганта для работы с проектом, а сетевые графики из системы в ролике.
Сергей, спасибо за доклад! Ты в своем рассказе, кажется, больше про цели для отделов. А как формируются цели для конкретных разработчиков?
Видео гляну, спасибо.
Если все же есть такая потребность, но у RN неплохая документация, как написать подключить к RN произвольный нативный модуль. Этим тоже мы нередко занимались, подключая внутренние нативные модули нашей компании.
Если ли же в вашем приложении процентное соотношение другое, то, конечно, стоит присмотреться к другим вариантам.
Перейти на новый экран, сделать сетевой запрос, обработать JSON ответа на пару сотню Кб, перерендерить пару десятков вложенных View — вот типичные задачи для ниши приложений, для которых используются эти фреймворки.
Если вы их используете для создания игр, real time machine learning, 3d графики и пр., то вы просто используете неподходящий инструмент.
Второе. У меня за плечами разработка большого приложения (порядка 30 экранов) с команде из 3 разработчиков, которое работает на базе RN и при этом занимало и занимает топовые позиции в каталоге App Store. Мне кажется, это подтверждает аргумент, что можно делать крутые приложения на RN, которые нравятся пользователям.
А у меня такая же нога, но не болит.) Я, честно, за 6 лет работы в одной из крупнейших ИТ-корпораций РФ не встречал именно такого требования к общению с чей-либо стороны.
Пожалуй, если где-то есть культура со смещение в сторону абсурдной вежливости, то общее правило я для себя оставил таким же — не сошлись культурами, найди другую компанию. ИТ рынок сейчас очень большой.
Не вижу ничего плохого, чтобы показать коллеге, что я воспринимаю его как человека, а не как винтик в системе по доставке обновлений продукта. Очень важно показать, что ты «видишь» человека.
Антон, в своей статье, ты кидаешься из одной крайности в другую, приводя в качестве примера несуществующие абсурдные требования к вежливости, а потом сокрушаешься, что эти правила контр-продуктивны. Конкретно эти правила — да, конечно, но базовые правила вежливости гораздо проще.
Возможно, некоторые люди просто не видят этой черты, но есть же обратная связь. Ты вроде её получил сполна, чтобы скорректировать свое поведение. Если не хочешь принимать культуру компании, то почему бы всем не упростить жизнь и найти ту компанию, которая тебе больше подходит по культуре?
Спасибо за статью! А известны конкретные цифры: средний размер бандла, потребление памяти и время на обновление DOM?
Не надо так, в общем. Лучше делать PR или форки.
Хорошо же, когда сложная тема просто объясняется?)
Спасибо за статью. Возможно, я упустил, но неясно как вообще при такой архитектуре может быть быстрое чтение состояния того же пользователя? Каждый раз итерироваться по всем соотв. событиям?