Схема операций навигации в клиенте Moera. Обычно я не рисую схемы - структура должна быть достаточно простой, чтобы умещаться в голове (моей 😉). Если сложность растёт, растёт и хрупкость, и начинают постоянно вылезать ошибки - а значит, пора рефакторить. Вот это - тот самый случай. Но тут уже пришлось нарисовать схему, чтобы понять, с какого конца начинать рефакторинг, чтобы ничего не сломать.
Comments (10)
draw.io? 🙂
Я думал об этом, но, по прошлому опыту, больше времени тратится на борьбу с рисовалкой, чем на рисование 😉
Да, согласен. в каждом случае нужно думать про баланс.
"лучше день потерять, зато потом за час долететь"
Когда разрабатывают несколько человек, и надо позже поддерживать правки, или объяснять новеньким, ...
У нас в любом случае рисуют в цифровом виде, и сохраняем в конфлюенс или в гит.
Если бы у меня было несколько человек, я бы нашёл на это время 😉
В любом случае, конкретно эта схема уже очень скоро будет неактуальна.
Что здесь что? Вижу, что несколько типов узлов и ребер.
Ещё arrows.app - удобно графы рисовать и дизайнить схемы для графовых баз. Хотя финальные я делал с помощью plantuml.
И excalidraw - в стиле "на салфетке" 🙂 Опенсорцный, кстати, есть в т.ч. плагин к Obsidian.
Но, последнее время пользуюсь в основном Mermaid (это, как и PlantUML, инструмент для представления диаграмм кодом), генерируя его с помощью Claude Code либо любого из чатовых интерфейсов к LLM'кам. Визуализировать можно в Jetbrains'овых IDE'шках с помощью соответствующего плагина. И видоизменять, понятное дело, тоже промптингом.
Ещё Eraser.io бывает полезен для генерации диаграмм промптами, особенно для архитектур на AWS, но предыдущий вариант мне удобнее, особенно для того, что хочется "поразминать в руках". Потому что всё происходит на компе, можно попросить поизучать исходники, например, и начертить.
Тут отчасти вопрос курицы и яйца. Чем меньше порог входа, тем больше шансов, что образуются контрибьюторы 🙂
Тут уже получается, как в анекдоте: "Но сносить ради какой-то ... два этажа дачи я не буду" 😉
Большими буквами - это actions - действия, которые изменяют состояние. Строчными буквами - это обычные функции. В овале - это пользовательские действия.
Стрелки: r - reducer - изменения состояния; s - saga - побочные действия, привязанные к actions; t - trigger - когда один action при выполнении определённого условия эмитирует другой action. (Триггеров в Redux нет, это моё изобретение 😉)
О, спасибо за наводку.
Теперь придётся потрогать каждую 🙂
А то было засел на Плант и Драу и не смотрю по сторонам.