Аспект проектирования при основных типах методологий разработки программных систем:
Каскад (waterfall) - заказчик дает четкие требования, по ним строится архитектура системы, программисты делают по ней код.
Гибкая (agile, XP, итеративная) - заказчик дает общие требования, по ним строится прототип архитектуры системы, программисты делают по ней код, систему показывают заказчику, вносятся корректировки, выпускается следующая версия и.т.д по кругу.
DDD (domain-driven design, предметно-ориентированная проектирование) - заказчик и программисты постоянно тесно работают над выработкой четкой модели предметной области, которая затем практически один в один становится скелетом архитектуры программной системы.
Каскад применяется для более-менее типовых задач и когда есть четкие требования (SRS, техзадание).
DDD увеличивает вероятность успеха при решении сложных задач, с нечеткими и меняющимися требованиями и необходимостью исследования предметной области.
#architecture
Каскад (waterfall) - заказчик дает четкие требования, по ним строится архитектура системы, программисты делают по ней код.
Гибкая (agile, XP, итеративная) - заказчик дает общие требования, по ним строится прототип архитектуры системы, программисты делают по ней код, систему показывают заказчику, вносятся корректировки, выпускается следующая версия и.т.д по кругу.
DDD (domain-driven design, предметно-ориентированная проектирование) - заказчик и программисты постоянно тесно работают над выработкой четкой модели предметной области, которая затем практически один в один становится скелетом архитектуры программной системы.
Каскад применяется для более-менее типовых задач и когда есть четкие требования (SRS, техзадание).
DDD увеличивает вероятность успеха при решении сложных задач, с нечеткими и меняющимися требованиями и необходимостью исследования предметной области.
#architecture
May 21, 2024
Чистая архитектура (
Она даёт:
- Независимость от зависимостей. Архитектура вашей системы не зависит напрямую от существования какой-либо библиотеки. Это позволяет использовать фреймворки как инструменты, а не втискивать свою систему в их рамки.
- Тестируемость. Бизнес-правила можно тестировать без UI, базы данных, веб-сервера или любого другого внешнего элемента.
- Независимость от UI. Пользовательский интерфейс можно легко изменить. Например, веб-интерфейс может быть заменен на мобильный, без изменения бизнес-правил.
- Независимость от внешних сервисов. Вы можете заменить, например, MySQL на Mongo, поменять платедного провайдера или что-то еще. Ваши бизнес-правила просто ничего не знают о внешнем мире.
Именно по рекомендациями
#architecture #cleanarchitecture
Clean Architecture) — это способ разделения функционала по степени его близости к предметной области приложения.Она даёт:
- Независимость от зависимостей. Архитектура вашей системы не зависит напрямую от существования какой-либо библиотеки. Это позволяет использовать фреймворки как инструменты, а не втискивать свою систему в их рамки.
- Тестируемость. Бизнес-правила можно тестировать без UI, базы данных, веб-сервера или любого другого внешнего элемента.
- Независимость от UI. Пользовательский интерфейс можно легко изменить. Например, веб-интерфейс может быть заменен на мобильный, без изменения бизнес-правил.
- Независимость от внешних сервисов. Вы можете заменить, например, MySQL на Mongo, поменять платедного провайдера или что-то еще. Ваши бизнес-правила просто ничего не знают о внешнем мире.
Именно по рекомендациями
Clean architecture не следует обращаться к web API напрямую из стора. Подобные требования есть у многих методологий проектирования ПО#architecture #cleanarchitecture
June 13, 2024
Мир IT крутится вокруг данных. Если задуматься, 99.999% времени любой компьютер внутри себя просто перекладывает данные с одного места в другое.
В
#data #architecture
Data pipeline (конвейер данных) - это методика сбора, обработки и анализа данных, которые сперва собираются из разных источников в хранилища, структурируются и затем используются для разных целей.В
data lake складывают неструктурированные данные, data warehouse - уже структурированные, удобные для запросов.#data #architecture
June 20, 2024
Для любителей
В качестве выводов - констатация факта, что по
#fsd #architecture
FSD описание проекта на Vue на нем (тудушка)В качестве выводов - констатация факта, что по
FSD все сделать нельзя, даже такой маленький проект, и надо искать компромисс между FSD методами и не FSD методами в одном проекте.#fsd #architecture
Хабр
Разработка фронтенда на основе FSD
Приветствую! С вами Вадим, frontend разработчик компании «Перспективный мониторинг». Сегодня хочу поделиться нашей типовой структурой frontend приложения, рассказать об архитектурной методологии,...
July 2, 2024
Аргументация против
1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в
2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент
3. Если проект вырастает во что-то большее, чем маленький пет, то количество компонентов уже не даст нормально и лампово работать с автоимпортами, если их названия будут собираться на основе папочек, где они лежат, а в больших проектах это вообще самоубийство
4. Не нужно генерировать портянку
5. Ты уверен, что тришейкинг работает правильно и ты явно контролируешь загрузку каждого конкретного компонента в каком-либо месте, а не полагаешься на то, что за тебя это каким-то магическим образом сделает автоимпорт
6. Импорты может проставлять сама
#architecture #bestpractices #tip #nuxt
глобальных автоимпортов (типа тех, что в Nuxt) от Artyom Tuchkov1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в
*.d.ts ;)2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент
3. Если проект вырастает во что-то большее, чем маленький пет, то количество компонентов уже не даст нормально и лампово работать с автоимпортами, если их названия будут собираться на основе папочек, где они лежат, а в больших проектах это вообще самоубийство
4. Не нужно генерировать портянку
*.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода5. Ты уверен, что тришейкинг работает правильно и ты явно контролируешь загрузку каждого конкретного компонента в каком-либо месте, а не полагаешься на то, что за тебя это каким-то магическим образом сделает автоимпорт
6. Импорты может проставлять сама
IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают#architecture #bestpractices #tip #nuxt
July 10, 2024
Чтобы выделить из компонента отдельно некий функционал с реактивным состоянием, были созданы
Чтобы использовать функционал с реактивным состоянием между несколькими компонентами, можно задействовать js модули либо
Иногда нужно нечто среднее - подобную сущность с реактивным стейтом и функционалом на нем, но используемую в нескольких связанных компонентах (например, в
В этом случае данный реактивный объект будет жить в своем ограниченном контексте и не будет конфликтовать с оставшейся частью проекта.
#reactivity #bestpractices #architecture
composable функции (называемые "функциями", хотя по сути это объект созданный через js замыкание - closure).Чтобы использовать функционал с реактивным состоянием между несколькими компонентами, можно задействовать js модули либо
Pinia/Vuex сторы.Иногда нужно нечто среднее - подобную сущность с реактивным стейтом и функционалом на нем, но используемую в нескольких связанных компонентах (например, в
Tabs или каких-то виджетах), - то есть, в некотором локальном контексте. Для этого можно в общем родительском компоненте создать composable, который передать потомкам - либо через provide/inject (лучше), либо через props (не надо).В этом случае данный реактивный объект будет жить в своем ограниченном контексте и не будет конфликтовать с оставшейся частью проекта.
#reactivity #bestpractices #architecture
Telegram
Vue-FAQ
Во Vue 3 есть важная и нередко используемая конструкция, у которой нет имени. Это то, что обычно называют "композабл с глобальными рефами".
Но:
1. Это не композабл по определению
2. Там не обязательно рефы
3. Они не "глобальны"
В общем случае структура…
Но:
1. Это не композабл по определению
2. Там не обязательно рефы
3. Они не "глобальны"
В общем случае структура…
July 17, 2024
Выражение "городить свои велосипеды" в IT заиграло новыми красками
Иногда оно используется по делу, но чаще имеет уничижительную форму, показывающую, что человек вместо популярного, раскрученного решения использует что-то свое или малоизвестное.
Если тебе нужен индексируемый поисковиками сайт, надо писать на
О VueUse уже много говорилось. Как и об #ssr. Как и о Tailwind.
Проблема "решений", пришедших и навязываемых из других фреймворков - это действительно проблема. Человек, перешедший с бэкэнда и даже с другого языка программирования возможно будет писать более качественный
"Проверенные" решения зачастую ничего более, чем просто хайпожорские решения. Которые привнесут на проект кучу зависимости, сложности и необходимости решать те проблемы, которых у тебя не было.
Поэтому советчиков, агитирующих не изобретать свои велосипеды, можно частично послушать и принять к сведению, а частично послать куда подальше как людей, не желающих или не умеющих думать своей головой. Особенно на фронтенде.
Ну и не будем забывать, что
#esse #architecture
Иногда оно используется по делу, но чаще имеет уничижительную форму, показывающую, что человек вместо популярного, раскрученного решения использует что-то свое или малоизвестное.
Если тебе нужен индексируемый поисковиками сайт, надо писать на
Nuxt, а не городить отдельную или динамическую отрисовку. Нужно использовать VueUse, потому что это швейцарский нож в любых ситуациях. Для соединения с бэком надо всегда подключать Tanstack vue-query, потому что у него десятки тысяч звезд на GitHub, все его используют, и он легко решает кучу твоих проблем, о которых ты раньше даже не догадывался, но теперь они у тебя есть. Ну и, конечно, Tailwind!О VueUse уже много говорилось. Как и об #ssr. Как и о Tailwind.
vue-query образовался из react-query, который действительно решал проблемы Реакта. Но во Vue нет этих проблем. Vue предоставляет все инструменты для эффективной и элегантной работы с бэкендом.Проблема "решений", пришедших и навязываемых из других фреймворков - это действительно проблема. Человек, перешедший с бэкэнда и даже с другого языка программирования возможно будет писать более качественный
Vue код, чем переучившийся с Реакта."Проверенные" решения зачастую ничего более, чем просто хайпожорские решения. Которые привнесут на проект кучу зависимости, сложности и необходимости решать те проблемы, которых у тебя не было.
Поэтому советчиков, агитирующих не изобретать свои велосипеды, можно частично послушать и принять к сведению, а частично послать куда подальше как людей, не желающих или не умеющих думать своей головой. Особенно на фронтенде.
Ну и не будем забывать, что
Vue - это тоже велосипед, написанный в эпоху диктатуры Angular, React, JQuery и других солидных, проверенных и общепризнанных решений.#esse #architecture
Telegram
Vue-FAQ
При написании своей реализации useLocalStorage для Arty-Crafty родились небольшие размышления о библиотеке VueUse
#vueuse #artycrafty
#vueuse #artycrafty
July 18, 2024
November 21, 2024
Сегодня этому каналу 1 год.
Время вспомнить первый пост
По сей день это лучший учебник для изучения
#vuefaq #learning #architecture #book
Время вспомнить первый пост
По сей день это лучший учебник для изучения
Vue.js на русском языке.#vuefaq #learning #architecture #book
Telegram
Vue-FAQ
📖
Закончен перевод книги "Vue.js 3 Design Patterns and Best Practices"
Лучший материал для самостоятельного изучения Vue.js
https://vue-faq.org/ru/book/
#learning #architecture #book
Закончен перевод книги "Vue.js 3 Design Patterns and Best Practices"
Лучший материал для самостоятельного изучения Vue.js
https://vue-faq.org/ru/book/
#learning #architecture #book
November 23, 2024
Кто занимается микрофронтендами - познавательная статья Micro Frontends на сайте Мартина Фаулера
#microfrontends #architecture #bestpractices
#microfrontends #architecture #bestpractices
martinfowler.com
Micro Frontends
How to split up your large, complex, frontend codebases into simple, composable, independently deliverable apps.
December 19, 2024
Примеры файловых структур Vue проекта для плоской, атомарной, модульной и FSD архитектур
Предпочитаю всегда модульную с небольшими вариациями
#architecture #fsd
Предпочитаю всегда модульную с небольшими вариациями
#architecture #fsd
December 20, 2024
Комментарии к прошлому посту ярко показывают, стоит ли тащить в свой проект чудо природы под названием
Модульная архитектура даёт понятную четкую декомпозицию проекта, хорошо разделяя
Общие элементы типа
Между модулем и однофайловым компонентом есть промежуточные структуры - виджеты типа
Довольно сложный вопрос, где держать и как наименовать файлы с бизнес-логикой - как реактивной, так и обычной. Однозначного совета пока нет. Скорей тут надо использовать программерские подходы из обычного ООП.
#architecture
FSD.Модульная архитектура даёт понятную четкую декомпозицию проекта, хорошо разделяя
ShoppingCart от UserAccount, например. Позволяя видеть в файловой панели только относящиеся к нужному модулю ресурсы, и работать над модулями независимо.Общие элементы типа
BaseButton можно держать в App, а можно выделить под них отдельный проект (вроде своей дизайн системы) и подключать папкой ui через git submodules. Так же, как и объекты типа api.Между модулем и однофайловым компонентом есть промежуточные структуры - виджеты типа
FileUploader, например, в которых есть чисто их композаблы, утилиты, компоненты, типы. Их удобно держать в своих папках без разделения по поддиректориям.Довольно сложный вопрос, где держать и как наименовать файлы с бизнес-логикой - как реактивной, так и обычной. Однозначного совета пока нет. Скорей тут надо использовать программерские подходы из обычного ООП.
#architecture
December 20, 2024
Основные принципы локально-ориентированной (Local-First) разработки
Локально-ориентированная разработка имеет сходства с подходами offline-first, но идет дальше, уделяя больше внимания контролю пользователя и владению данными. Вот ключевые принципы, определяющие настоящую локально-ориентированную веб-приложение:
- Мгновенный доступ: Пользователи могут немедленно получить доступ к своей работе без ожидания загрузки или синхронизации данных (отсутствие спиннеров).
- Независимость от устройства: Данные доступны на разных устройствах без проблем.
- Независимость от сети: Основные задачи могут выполняться без подключения к интернету.
- Легкость совместной работы: Приложение поддерживает легкое совместную работу, даже в автономных сценариях.
- Долговечные (Future-Proof) данные: Данные пользователей остаются доступными и пригодными для использования с течением времени, независимо от изменений в программном обеспечении.
- Встроенная безопасность: Безопасность и конфиденциальность являются фундаментальными аспектами дизайна.
- Пользовательский контроль: Пользователи полностью владеют и контролируют свои данные.
#bestpractices #architecture
Локально-ориентированная разработка имеет сходства с подходами offline-first, но идет дальше, уделяя больше внимания контролю пользователя и владению данными. Вот ключевые принципы, определяющие настоящую локально-ориентированную веб-приложение:
- Мгновенный доступ: Пользователи могут немедленно получить доступ к своей работе без ожидания загрузки или синхронизации данных (отсутствие спиннеров).
- Независимость от устройства: Данные доступны на разных устройствах без проблем.
- Независимость от сети: Основные задачи могут выполняться без подключения к интернету.
- Легкость совместной работы: Приложение поддерживает легкое совместную работу, даже в автономных сценариях.
- Долговечные (Future-Proof) данные: Данные пользователей остаются доступными и пригодными для использования с течением времени, независимо от изменений в программном обеспечении.
- Встроенная безопасность: Безопасность и конфиденциальность являются фундаментальными аспектами дизайна.
- Пользовательский контроль: Пользователи полностью владеют и контролируют свои данные.
#bestpractices #architecture
December 27, 2024
Options API - это FSDComposition API с composables - модульная архитектура.(аналогия)
FSD в основу иерархичного разбиения ставит программный функционал. Модульная - доменные сущностиМожно провести аналогию c физиологией человека
Можно изучать человека разбивая его на руки, ноги, тело, голову и внутри уже по органам, тканям и т.д.
FSD же на верхнем уровне разбивает сперва по органам и тканям - кровеносная система, ЖКТ, мышечные ткани, и внутри уже разбивает по доменам - рот и кишечник внутри ЖКТТак же и с переходом от
Options API к Composition API. Было разбиение по фичам (options), стало - по бизнес / доменным сущностям (композициям). Так лучше.
#fsd #architecture
January 15
Иллюстрации к принципам ООП из выдающейся книжки
Очень полезна фронтендерам в том числе
#oop #architecture #gradybooch
Graddy Booch Object-Oriented Analysis and Design with ApplicationsОчень полезна фронтендерам в том числе
#oop #architecture #gradybooch
January 29
При использовании сторов иногда получаются проблемы из-за перекрестных ссылок, которые дают
При использовании модульных рефов может возникнуть аналогичная ситуация - например, когда переменная
#store #reactivity #architecture
ReferenceErorПри использовании модульных рефов может возникнуть аналогичная ситуация - например, когда переменная
refA определяется в модуле А, который использует модуль B, а B вешает watch на refA. Причем это применимо только к системе реактивности Vue, потому что с обычными объектами такой проблемы нет.#store #reactivity #architecture
March 25
Решения для проблемы выше
1. Переделать. Перекрестное использование сущностей - архитектурно плохая практика. Каждая должна содержать в себе только свое состояние и логику работы с собой. Если
К созданию сторов / модульных рефов надо подходить так же ответственно, как к проектированию схемы реляционной базы данных. Это координатный базис, и в нем не может быть перекрестных зависимостей.
Если есть логика, которая работает и с
2.
3. Шина событий (
4. Если
5. Не надо пихать реактивность туда, где можно обойтись без нее. Если переменная
Так же приоритетно, как и пункт 1.
#store #reactivity #architecture
1. Переделать. Перекрестное использование сущностей - архитектурно плохая практика. Каждая должна содержать в себе только свое состояние и логику работы с собой. Если
А использует B, значит B - утилитарен по отношению к А (например, А - какой-то бизнесовый стор, B - отвечает за открытие диалогов). Но тогда коду из А нечего делать в B.К созданию сторов / модульных рефов надо подходить так же ответственно, как к проектированию схемы реляционной базы данных. Это координатный базис, и в нем не может быть перекрестных зависимостей.
Если есть логика, которая работает и с
А, и с B, то, скорей всего, она прикладная для этих сторов, и должна лежать в отдельной сущности (компоненте, композабле, простом или реактивном модуле, сторе).2.
setTimeout / nextTick, как на картинке. Работает и с модульными рефами, но выглядит уродливым костылём3. Шина событий (
eventBus) для сообщений между сторами. Как самостоятельное решение возможно, но в данном случае опять же костыль.4. Если
refA в примере вынести в отдельный модуль, то ошибка пропадет. То же самое, скорей всего, справедливо и для сторов, но будет выглядеть неуклюже. Выносить надо не голый стейт, а разделять стор грамотно, по ответственности.5. Не надо пихать реактивность туда, где можно обойтись без нее. Если переменная
B зависит от А, и источников изменения А всего один-два, то необязательно ставить watch над А в B, можно обновлять B императивно напрямую. Это уберет прямую зависимость от А в B (если код в А уже как-то использует B), а также повысит читаемость и производительность. В первую очередь касается кода, который работает с бэкенд API. Так же приоритетно, как и пункт 1.
#store #reactivity #architecture
March 25
Атрибуты хорошего кода
Хороший код (ПО) обладает рядом атрибутов, которые делают его удобным для чтения, поддержки и развития. Вот ключевые характеристики:
1. Читаемость
Понятные имена переменных, функций, классов (например, calculateTotalPrice() вместо calc()).
Единый стиль (консистентность в именовании, отступах, структуре).
Комментарии там, где логика неочевидна (но без избыточности).
2. Модульность и структурированность
Разделение на функции/классы/компоненты (принцип Single Responsibility).
Низкая связанность (low coupling) – компоненты минимально зависят друг от друга.
Высокая связность (high cohesion) – код внутри модуля решает одну задачу.
3. Тестируемость
Покрытие тестами (код легко проверить на корректность).
Изолированность (зависимости можно подменить mock-объектами).
4. Эффективность и производительность
Оптимальные алгоритмы (O-нотация учитывается, но без преждевременной оптимизации).
Минимизация ресурсов (память, процессор, сетевые запросы).
5. Гибкость и расширяемость
Открытость/закрытость (Open/Closed Principle) – код можно расширять без изменения существующей логики.
Использование паттернов проектирования (например, Factory, Strategy, Observer).
6. Надежность и отказоустойчивость
Обработка ошибок (корректные исключения, logging).
Обработка edge-cases (крайние случаи, невалидные входные данные).
7. Поддерживаемость
Документация (хотя бы минимальная: README, docstrings).
Рефакторинг – код можно улучшать без страха что-то сломать.
8. Безопасность
Защита от уязвимостей (SQL-инъекции, XSS, CSRF и др.).
Валидация входных данных.
9. Совместимость и переносимость
Кросс-платформенность (если требуется).
Четкие зависимости (использование package managers: pip, pnpm, maven).
10. Соответствие стандартам и best practices
Следование языковым идиомам (Pythonic way, Java Code Conventions, Vue code style и т. д.).
Интеграция с CI/CD (автоматические тесты, деплой)
#architecture #code
Хороший код (ПО) обладает рядом атрибутов, которые делают его удобным для чтения, поддержки и развития. Вот ключевые характеристики:
1. Читаемость
Понятные имена переменных, функций, классов (например, calculateTotalPrice() вместо calc()).
Единый стиль (консистентность в именовании, отступах, структуре).
Комментарии там, где логика неочевидна (но без избыточности).
2. Модульность и структурированность
Разделение на функции/классы/компоненты (принцип Single Responsibility).
Низкая связанность (low coupling) – компоненты минимально зависят друг от друга.
Высокая связность (high cohesion) – код внутри модуля решает одну задачу.
3. Тестируемость
Покрытие тестами (код легко проверить на корректность).
Изолированность (зависимости можно подменить mock-объектами).
4. Эффективность и производительность
Оптимальные алгоритмы (O-нотация учитывается, но без преждевременной оптимизации).
Минимизация ресурсов (память, процессор, сетевые запросы).
5. Гибкость и расширяемость
Открытость/закрытость (Open/Closed Principle) – код можно расширять без изменения существующей логики.
Использование паттернов проектирования (например, Factory, Strategy, Observer).
6. Надежность и отказоустойчивость
Обработка ошибок (корректные исключения, logging).
Обработка edge-cases (крайние случаи, невалидные входные данные).
7. Поддерживаемость
Документация (хотя бы минимальная: README, docstrings).
Рефакторинг – код можно улучшать без страха что-то сломать.
8. Безопасность
Защита от уязвимостей (SQL-инъекции, XSS, CSRF и др.).
Валидация входных данных.
9. Совместимость и переносимость
Кросс-платформенность (если требуется).
Четкие зависимости (использование package managers: pip, pnpm, maven).
10. Соответствие стандартам и best practices
Следование языковым идиомам (Pythonic way, Java Code Conventions, Vue code style и т. д.).
Интеграция с CI/CD (автоматические тесты, деплой)
#architecture #code
May 15