Что случилось?

Многие заметили активные перемены, которые начались на канале. Появилось больше контента, который многие ждали. Появился вопрос "Откуда эти перемены?". Вероятно ответ вас удивит, но для меня все изменения закономерны и давно запланированы.

Некоторое время я потратил на анализ аргументов против карьерного пути развития. Мне кажется, я рассмотрел все более-менее конструктивные моменты. В ответ указал на явные пробелы аргументации: проблемы казуальной стратегии, проблемы статистики, отметил попытки исказить реальное положение дел - раз, два, три, показал избитые софизмы в аргументах и многое другое.

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

Моя работа не прошла даром, в итоге на soer.pro пришло почти 7000 человек (по последним данным 6927), это люди, которые хотят развиваться, хотят строить карьеру и ждут от меня конкретных материалов и советов. Поэтому я планово перешел на контент для развития. Моя миссия - помочь людям сэкономить самый важный ресурс - время.

Я уверен, что далее тратить время на попытки переубедить кого-либо бессмысленно. Во-первых, все факты были предоставлены, аргументы против карьерного роста опровергнуты, кто хочет может легко ознакомиться с моей точкой зрения. Во-вторых, дальнейшая трата ресурсов на полемику - это воровство времени у моих подписчиков, да и у меня тоже. Никто не запрещает моим оппонентам изменить мнение и заняться саморазвитием, но время на убеждение прошло. Дальше кто понял, тот понял.

Analyzing The Impact of UML, BPMN, and ArchiMate Integration from User Perspective (Рубрика #Architecture)

Забавный whitepaper про нотации моделирования, к которым я питаю особую любовь еще со времен своего обучения. Авторы решили объединить разные нотации моделирования во благо совместной работы внутри корпораций. Авторы исходят из предпосылок
1) В корпорациях есть много диаграмм разных уровней, созданных при помощи ArchiMate, BPMN и UML и эти диаграммы содеражат большой объем знаний
2) В корпорациях есть много людей, которые умеют использовать эти нотации для проектирования
- BPMN для описания бизнес-логики и бизнес процессов
- Archimate для описания нюансов корпоративной архитектуры
- UML для описания различных приложений и их взаимодействий
3) В корпорациях можно получить значительный буст от объединения этих нотаций между собой
Поэтому цель исследования оценить удовлетворение пользователей и удобство использования объединенной нотации.

Моя мысль, что большая часть предусловий, на которых строились идеи авторов не выполняются
1) В компаниях нет большого количества актуальных диаграмм с этими нотациями и из них нельзя сформировать общую картину
2) В большинстве компаний нет людей, что легко используют эти нотации (если не считать касты корпоративных архитекторов, которая существует в некоторых больших корпорациях в виде сотен представителей департамента корпоративной архитектуры)
3) Предполагаемый буст достигается за счет использования преимуществ каждой нотации, но вот знающих все три нотации обычно не очень много - я представляю тут диграмму Эйлера-Венна с пересечением кружков-множеств и центральной маленькой частью, которая пренебрежимо мала

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

В итоге, сама идея авторов статьи сомнительна, но ок ... пойдем к тому, а что и как они оценивали
1) Ребята взяли фреймворк FUEML (Framework for Usability Evaluation of Modeling Langueges) из книги "Usability evaluation of modeling languages: An empirical research study"
2) Из этого фреймворка они выбрали lernability, memorability, user satisfaction, по которым решили сравнивать отдельно диаграммы в Architmate и комбо-диаграммы с миксом из трех нотаций
- Learnability - это оценка того, насколько просто научиться пользоваться новой нотацией и насколько быстро получается выполнять задачи, какой уровень ошибок, etc
- Memorability - насколько устойчиво запоминается информация о нотации, синтаксисе и семантике
- User satisfaction - это отзывы пользователей о том, насколько они довольны использованием языка, его полнотой, качеством и удобством
3) Авторы изучали
- Насколько быстро респонденты разбирались с двумы диаграммами: базовой A и расширенной B (кстати, диаграмму с комбинацией нотаций у меня открыть не получилось - авторы, видимо, отменили права на шаринг)
- Насколько быстро авторы выполняют задачи с использованием моделей
- Насколько много ошибок в процессе обучения
- Фидбек пользователей

В итоге, авторы получили примерно следующее

Overall, respondents thought that the integration of BPMN, ArchiMate, and UML was ”easy”. Modeling complicated systems is another ”very useful” application of this combination.

Правда, их респонденты преимущественно знали все три нотации моделирования:)

#Software #Architecture #Engineering #UML #SystemDesign #Whitepaper

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

Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен state менеджер “. Дмитрий сделал действительно классный анализ существующих на данный момент стейт менеджеров (упустив, однако, effector и mobx), а также сравнил их с хранением состояния средствами react. Вставлю свои пять копеек.

Дмитрий подчеркивает такую проблему стейт менеджеров, как отсутствие экосистемы (на reatom нет библиотеки работы с формой и тд), объясняя это тем, что если мы заносим в проект стейт менеджер, то мы хотим писать на нем всю бизнес логику. Я всегда относилась к стейт менеджерам иначе - в первую очередь я использовала их для хранения данных, используемых глобально (как минимум в нескольких местах приложения), а не как место для написания бизнес логики. Мои требования к стейт менеджеру следующие:

- Стейт является структурой вида “ключ-значение”.
- Содержит геттер данных по ключу.
- Содержит сеттер данных, причем для каждого поля может быть только один сеттер. Этому требованию очень удобно удовлетворяет Redux: в нем принято писать один action creator, который возвращает action, и диспатчить этот action creator из разных мест приложения; но не удовлетворяет, например, effector, потому что он допускает установку данных как в push дизайне (вызов ивента), так и в pull дизайне (подписка стора на эффект). Почему это так важно, опишу позже.
- Удобные девтулзы.

Бизнес логику я распределяла и хранила в: 1. компонентах реакт (например, вызов запроса, если он вызывается только в одном месте), 2. в ts классах (отлично подходит для кода, не требующего механизмов реактивности), 3. в redux-thunk (в небольших приложениях) или 4. в эпиках rxjs (в больших приложениях). Таким образом, я изначально проектировала свой код так, чтобы стейт менеджеру отводилась роль хранилища, поэтому с проблемой, о которой говорит Дима, я за свой профессиональный опыт так и не столкнулась.

Для чего я вообще использую стейт менеджеры? Главная проблема, которую они для меня решают, возникает вовсе не в процессе написания кода, а в процессе поддержки и эксплуатации. Хранение глобальных данных во время написания кода - это вообще не проблема. Я могу легко написать код, который хранит данные где угодно - в реакт хуках, в контексте, да хоть в объекте window. Однако потом наше приложение постепенно обрастает пользователями и фичами, и рано или поздно мы неизбежно сталкиваемся с багом: в наших глобальных данных почему-то лежит не то, что мы ожидаем. Ждем foo, а лежит bar. И дальше наша - понять, почему так получилось, и устранить проблему. Для этого, во-первых, надо понять, какие данные записаны неверно. И вот тут-то пригождаются топовые девтулзы редакса: я просто открываю девтулзы и смотрю текущий слепок данных, в котором достаточно легко нахожу неверные данные. Дальше надо понять, откуда записались неверные данные. Для этого я ставлю в соответствующем action creator брейкпойнт дебаггера и в два счета нахожу в колстеке виновника.

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

Про меня написали на канале cloud.ru 👇👇👇