Здарова бандиты! 😏
Я Пико (Данила), разработчик из Москвы. В IT тусуюсь уже седьмой год, накипело-наболело, хочу (и буду) изливать сюда свою душу и мысли.
Специализируюсь на .NET (C#/F#), прогаю всё, от мобайлов и десктопов до сайтов и игрушек, руковожу командами, обучаю.
Активно вливаюсь в кибербезопасность, осваиваю функциональщину и пипл-менеджмент
Ну а там как пойдет, встречайте!💪
Я Пико (Данила), разработчик из Москвы. В IT тусуюсь уже седьмой год, накипело-наболело, хочу (и буду) изливать сюда свою душу и мысли.
Специализируюсь на .NET (C#/F#), прогаю всё, от мобайлов и десктопов до сайтов и игрушек, руковожу командами, обучаю.
Активно вливаюсь в кибербезопасность, осваиваю функциональщину и пипл-менеджмент
Ну а там как пойдет, встречайте!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1🔥1💩1💯1
Недавно удалось потрогать прекраснейший инструмент для хранения в кодовой базе визуализации графовых структур - ascii диаграммы
Без шуток, если у вас в проекте есть графы и вы испытываете необходимость в документировании различных сценариев/представлений графов - этот подход максимально удобен.
Обычно документация к сложной логике, построенной на графах, располагается где-то вне кодовой базы, а в самом коде ссылок на эту документацию, как правило, не найти, вот и сидишь, ковыряешь, пытаешься разобраться.
Использование инструментария для рисования ASII диаграмм - это полноценный Docs-as-Code, который прост в генерации и лёгок в поддержке, а самое главное - читабелен для других коллег-разработчиков. Его можно использовать, например, для UML-диаграмм сложной ветвистой логики, или изображения диаграмм взаимодействия различных компонентов.
Я использовал этот подход для документирования unit-тестов, где рисовал то, как устроен граф, над каждым тестовым сценарием. Получилась годно.
Полезные ссылки: ASCIIFlow
#tools
👾 PICO
Без шуток, если у вас в проекте есть графы и вы испытываете необходимость в документировании различных сценариев/представлений графов - этот подход максимально удобен.
Обычно документация к сложной логике, построенной на графах, располагается где-то вне кодовой базы, а в самом коде ссылок на эту документацию, как правило, не найти, вот и сидишь, ковыряешь, пытаешься разобраться.
Использование инструментария для рисования ASII диаграмм - это полноценный Docs-as-Code, который прост в генерации и лёгок в поддержке, а самое главное - читабелен для других коллег-разработчиков. Его можно использовать, например, для UML-диаграмм сложной ветвистой логики, или изображения диаграмм взаимодействия различных компонентов.
Я использовал этот подход для документирования unit-тестов, где рисовал то, как устроен граф, над каждым тестовым сценарием. Получилась годно.
Полезные ссылки: ASCIIFlow
#tools
👾 PICO
👍1💩1
Я стартую уже второй проект с использованием этого подхода и не могу нарадоваться, как легко становится вносить в код изменения и не бояться за фатальные баги.
Сам подход состоит из нескольких шагов:
1. Описываем логику приложения на русском языке (с использованием нотации gherkin), наполняя пользовательские сценарии. Это происходит в отдельных .feature-файлах в директориях для тестов.
2. На каждый шаг сценария делаем его репрезентацию в коде. То есть говорим приложению, как транслировать русский текст сценария в конкретный набор исполняемого кода
3. Запускаем тест. Profit
Конечно, есть свои нюансы, но код, получающийся при проектировании по ATDD получается гораздо качественней, а "встроенная" документация по пользовательским сценариям напрямую из тестов позволит гораздо проще осознать логику приложения новым людям на проекте.
Ну и плюс ко всему - основные пользовательские сценарии автоматически становятся покрыты тестами, что обеспечивает приложению стабильность в рефакторинге и дальнейшим изменениям.
Не пренебрегайте TDD подходами, они реально рулят, когда речь заходит о создании качественного долгоживущего ПО.
Полезные ссылки: SpecFlow для .NET
👾 PICO
Please open Telegram to view this post
VIEW IN TELEGRAM
💩1
👊 Битва пет-проектов
Мы вместе с Хабр.Карьерой запускаем уникальное мероприятие - онлайн-битву IT-команд!
💎 Команда Sapphire - полнофункциональная команда с составом 14 человек.
Представители энтерпрайза, полноценного пайплайна разработки с аналитиками и тестировщиками, современным стеком технологий и разделением репозиториев на фронт/бек.
♨️ Команда Garnet - лимитированная с составом 8 человек.
Представители стартапа со специально подобранным стеком для ускоренной разработки, одним репозиторием на фронт и бек, полагающаяся исключительно на автоматизированные тесты
Перед обеими командами стоит одна задача: разработать продукт для командного взаимодействия и ведения проектов.
То как каждая команда подойдёт к этому заданию и что в итоге получится - узнаем совсем скоро!
Нас ждут также:
- Воркшопы по разработке и командные прямые эфиры
- Q&A сессии
- Стендапы и демо
И главная фишка: Все публично! Можно будет в онлайн-режиме следить за внутрикомандным взаимодействием в чатах самих команд и за ходом проектов в командных репозиториях.
От себя надеюсь, что мероприятие окажется в первую очередь полезным, ну, а там поглядим, может быть мы реально годные продукты забацаем :)
Старт уже на следующей неделе!
Ссылки: Лендинг битвы пет-проектов
👾 PICO
Мы вместе с Хабр.Карьерой запускаем уникальное мероприятие - онлайн-битву IT-команд!
💎 Команда Sapphire - полнофункциональная команда с составом 14 человек.
Представители энтерпрайза, полноценного пайплайна разработки с аналитиками и тестировщиками, современным стеком технологий и разделением репозиториев на фронт/бек.
♨️ Команда Garnet - лимитированная с составом 8 человек.
Представители стартапа со специально подобранным стеком для ускоренной разработки, одним репозиторием на фронт и бек, полагающаяся исключительно на автоматизированные тесты
Перед обеими командами стоит одна задача: разработать продукт для командного взаимодействия и ведения проектов.
То как каждая команда подойдёт к этому заданию и что в итоге получится - узнаем совсем скоро!
Нас ждут также:
- Воркшопы по разработке и командные прямые эфиры
- Q&A сессии
- Стендапы и демо
И главная фишка: Все публично! Можно будет в онлайн-режиме следить за внутрикомандным взаимодействием в чатах самих команд и за ходом проектов в командных репозиториях.
От себя надеюсь, что мероприятие окажется в первую очередь полезным, ну, а там поглядим, может быть мы реально годные продукты забацаем :)
Старт уже на следующей неделе!
Ссылки: Лендинг битвы пет-проектов
👾 PICO
🔥2💯1
📦 Kamal Deploy
Как же я долго ждал этого инструмента... и как жаль, что он существует уже несколько месяцев, а я узнал о нем только сейчас.
Перед стартом битвы пет-проектов стояла задача настроить быстрое и безболезненное развертывание веб-приложения на различные окружения. Ну я чето мурыжился, кубер настраивать очень не хочется (да и есть ограничения для него на инфраструктуре), ну, думаю, докер наше все, пошел уже настраивать docker-compose и тут...
Выходит пост у Феди Борщева про Kamal (бывш. mrsk). Ну я прочитал, думаю, прикольная тема, надо попробовать. И какой же это кайфовый инструмент!
Все что нужно на конечной машине - это поднятый docker. А на своей тачке (или внутри какого-нибудь пайплайна сборки) нужно просто поставить докер и утилиту kamal. Все, никаких зависимостей и громоздких инструментов.
Публикация проекта на окружения происходит с помощью трёх команд в первый раз и в одну во все последующие разы:
- kamal init для регистрации проекта и создания конфигов
- kamal setup для первоначального развертывания
- kamal deploy для всех последующих
Kamal просто подключается к нужной тачке, прописанной в конфиге, через ssh и сам собирает (с помощью Dockerfile) и деплоит ваше приложение, в добавок ко всему поднимает над ним reverse-proxy и делает базовый health-check. Он поддерживает откат релизов а также взаимодействует с различными registry для сохранения версий релизов.
Тупа огонь для скоростной настройки деплоя 🔥
Ссылки:
- Официальный сайт инструмента Kamal
- Настройка деплоя сервиса с помощью Kamal
#tools
👾 PICO
Как же я долго ждал этого инструмента... и как жаль, что он существует уже несколько месяцев, а я узнал о нем только сейчас.
Перед стартом битвы пет-проектов стояла задача настроить быстрое и безболезненное развертывание веб-приложения на различные окружения. Ну я чето мурыжился, кубер настраивать очень не хочется (да и есть ограничения для него на инфраструктуре), ну, думаю, докер наше все, пошел уже настраивать docker-compose и тут...
Выходит пост у Феди Борщева про Kamal (бывш. mrsk). Ну я прочитал, думаю, прикольная тема, надо попробовать. И какой же это кайфовый инструмент!
Все что нужно на конечной машине - это поднятый docker. А на своей тачке (или внутри какого-нибудь пайплайна сборки) нужно просто поставить докер и утилиту kamal. Все, никаких зависимостей и громоздких инструментов.
Публикация проекта на окружения происходит с помощью трёх команд в первый раз и в одну во все последующие разы:
- kamal init для регистрации проекта и создания конфигов
- kamal setup для первоначального развертывания
- kamal deploy для всех последующих
Kamal просто подключается к нужной тачке, прописанной в конфиге, через ssh и сам собирает (с помощью Dockerfile) и деплоит ваше приложение, в добавок ко всему поднимает над ним reverse-proxy и делает базовый health-check. Он поддерживает откат релизов а также взаимодействует с различными registry для сохранения версий релизов.
Тупа огонь для скоростной настройки деплоя 🔥
Ссылки:
- Официальный сайт инструмента Kamal
- Настройка деплоя сервиса с помощью Kamal
#tools
👾 PICO
👍5💩1
Не нравится? Перепиши!
За последние 2 месяца, так получилось, я начал два проекта с нуля. Один с командой, второй соло. Ну и ещё в третий проект вписался, в существующую команду и с имеющимся кодом.
Как же всё-таки важна программная архитектура. Новые проекты всегда хороши тем, что перед тобой чистый лист. Естественно ты практически сразу измажешь его говном, без вариантов, но до этого момента есть время насладиться реально красивым кодом.
Что делать чтобы этот лист испачкался как можно позже? Естественно, выстраивать ограничения для самого себя. Ставь заборы там, куда идти не стоит, клади асфальт туда, куда будешь ехать. И самое главное - модульность, модульность, модульность!
Понял, что капитально накосячил на старте? Ну и выкинь модуль, перепиши нормально, под переосознанные требования, завтра скажешь себе большущее спасибо, и не только ты, но и люди, которые с тобой работают.
После реализации очередного модуля стараюсь всегда спрашивать себя: а нравится ли мне то, что получилось?
Казалось бы такой банальный вопрос, но именно он иногда заставляет взять и подойти к решению по-новой. Сделать элегантнее и лучше.
👾 PICO
За последние 2 месяца, так получилось, я начал два проекта с нуля. Один с командой, второй соло. Ну и ещё в третий проект вписался, в существующую команду и с имеющимся кодом.
Как же всё-таки важна программная архитектура. Новые проекты всегда хороши тем, что перед тобой чистый лист. Естественно ты практически сразу измажешь его говном, без вариантов, но до этого момента есть время насладиться реально красивым кодом.
Что делать чтобы этот лист испачкался как можно позже? Естественно, выстраивать ограничения для самого себя. Ставь заборы там, куда идти не стоит, клади асфальт туда, куда будешь ехать. И самое главное - модульность, модульность, модульность!
Понял, что капитально накосячил на старте? Ну и выкинь модуль, перепиши нормально, под переосознанные требования, завтра скажешь себе большущее спасибо, и не только ты, но и люди, которые с тобой работают.
После реализации очередного модуля стараюсь всегда спрашивать себя: а нравится ли мне то, что получилось?
Казалось бы такой банальный вопрос, но именно он иногда заставляет взять и подойти к решению по-новой. Сделать элегантнее и лучше.
👾 PICO
❤4💩1
Автотесты - первый помощник тимлида
Для битвы пет проектов я решил попробовать относительно новый для себя подход - ATDD, о котором я уже рассказывал. И, к удивлению для себя самого, я ни разу об этом не пожалел.
Начну, внезапно, с минусов. Это время. Да, на реализацию фичи через автотесты уходит время. Где-то в каком-то исследовании даже видел конкретную цифру, фича занимает в среднем на 16% больше времени, если разработка идет через тестирование или если на фичу тесты пишутся после реализации. По прошествии полутора недель активной работы, это действительно ощущается так. Возможно, мы тратим на это даже больше.
Но самое интересное, что... больше минусов нет.
Вот серьезно, после реализации фичи вы получаете гарантированно работающий пользовательский сценарий (а то и несколько), который точно несет полезность для конечного потребителя продукта. Нужно больше уверенности? Просто добавляйте больше сценариев, покрывайте узкие, нестандартные кейсы и ошибки в рамках фичи.
Наш процесс приемки задач состоит из одного шага - код-ревью. Код решает задачу наших пользователей потому что мы начинаем разработку с пользовательского сценария. А в том что он точно работает я убеждаюсь благодаря автотестам.
Вы только посмотрите на наш Code Coverage (скрин в шапке). Помимо очевидного покрытия кода тестами эти цифры также показывают нам, что мы не делаем лишних вещей. Все о чем говорится в сценарии должно быть покрыто тестами. И оно покрыто.
Благодаря такому подходу я, как лид команды, в рамках ревью фокусируюсь на качестве кода, на его архитектуре, на взаимодействиях между модулями, и совершенно не беру на себя ответственность контролировать качество работы написанного кода, его соответствие требуемой бизнес-логике, так как эти вещи в нашем подходе автоматизированы благодаря ATDD.
Да, мы тратим больше времени на разработку, но мы получаем невероятную экономию буквально всех ресурсов команды на тестировании и контроле качества.
Пушка-бомба, лидам настоятельно рекомендую, особенно на новых проектах🦀
👾 PICO
Для битвы пет проектов я решил попробовать относительно новый для себя подход - ATDD, о котором я уже рассказывал. И, к удивлению для себя самого, я ни разу об этом не пожалел.
Начну, внезапно, с минусов. Это время. Да, на реализацию фичи через автотесты уходит время. Где-то в каком-то исследовании даже видел конкретную цифру, фича занимает в среднем на 16% больше времени, если разработка идет через тестирование или если на фичу тесты пишутся после реализации. По прошествии полутора недель активной работы, это действительно ощущается так. Возможно, мы тратим на это даже больше.
Но самое интересное, что... больше минусов нет.
Вот серьезно, после реализации фичи вы получаете гарантированно работающий пользовательский сценарий (а то и несколько), который точно несет полезность для конечного потребителя продукта. Нужно больше уверенности? Просто добавляйте больше сценариев, покрывайте узкие, нестандартные кейсы и ошибки в рамках фичи.
Наш процесс приемки задач состоит из одного шага - код-ревью. Код решает задачу наших пользователей потому что мы начинаем разработку с пользовательского сценария. А в том что он точно работает я убеждаюсь благодаря автотестам.
Вы только посмотрите на наш Code Coverage (скрин в шапке). Помимо очевидного покрытия кода тестами эти цифры также показывают нам, что мы не делаем лишних вещей. Все о чем говорится в сценарии должно быть покрыто тестами. И оно покрыто.
Благодаря такому подходу я, как лид команды, в рамках ревью фокусируюсь на качестве кода, на его архитектуре, на взаимодействиях между модулями, и совершенно не беру на себя ответственность контролировать качество работы написанного кода, его соответствие требуемой бизнес-логике, так как эти вещи в нашем подходе автоматизированы благодаря ATDD.
Да, мы тратим больше времени на разработку, но мы получаем невероятную экономию буквально всех ресурсов команды на тестировании и контроле качества.
Пушка-бомба, лидам настоятельно рекомендую, особенно на новых проектах
👾 PICO
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🤡1
Monolith over Microservices
Да-да, я снова про битву пет-проектов. На этот раз поговорим об архитектуре.
В кругу разработчиков часто популярен холивар в отношении программных архитектур для web-сервисов, мол, что выбрать, монолит или микросервисы, а для каких задач что подходит лучше и т.д. Есть строгие приверженцы одного из подходов, есть балансирующие между, но суть споров чаще всего одна - плюсы и минусы которые тот или иной подход в себе несет. Как-то я написал развернутый ответ на SO об отличиях монолитов и микросервисов и как плавно переходить от одного к другому.
Перед стартом битвы пет-проектов я тоже столкнулся с этой дилемой. С одной стороны есть монолит - простое и верное решение с минимальными затратами, но высокими рисками "завязывания" кода. С другой - микросервисы, хайповый и популярный путь с минимумом зависимостей, но сложностью развертывания и взаимодействия между сервисами.
А что если мы постараемся взять плюсы обоих подходов?
Допустим, у нас есть веб-сервис, единый (монолитный) исполняемый файл, под которым прячутся 2-4 микросервиса.
Какие плюсы:
- Простота развертывания. Один докерфайл и больше ничего. В отличие от классических микросервисов.
- Слабая связанность. Микросервисы внутри строго отделены друг от друга. От монолита требуется только запустить их всех вместе.
- Очень быстрый переход на микросервисные рельсы, в случаях, когда это необходимо. Мы просто выносим микросервис из монолита и разворачиваем отдельно по щелчку пальца.
Минусы:
- Нужно очень хорошо продумать архитектуру решения. Так чтобы можно было и быстро микросервис отделить и обеспечивалась достаточная обобщенность настройки.
- Не все внешние библиотеки можно настроить для исполнения под такой архитектурой. Я бы даже сказал, что их достаточно мало.
Можно сказать, что это переизобретенный SOA, но ключевое отличие тут в том, что микросервис - это не модуль ПО, а полноценное приложение со своими точками входа для пользователей.
Пример подобной архитектуры можно посмотреть в нашем репозитории для битвы
👾 PICO
Да-да, я снова про битву пет-проектов. На этот раз поговорим об архитектуре.
В кругу разработчиков часто популярен холивар в отношении программных архитектур для web-сервисов, мол, что выбрать, монолит или микросервисы, а для каких задач что подходит лучше и т.д. Есть строгие приверженцы одного из подходов, есть балансирующие между, но суть споров чаще всего одна - плюсы и минусы которые тот или иной подход в себе несет. Как-то я написал развернутый ответ на SO об отличиях монолитов и микросервисов и как плавно переходить от одного к другому.
Перед стартом битвы пет-проектов я тоже столкнулся с этой дилемой. С одной стороны есть монолит - простое и верное решение с минимальными затратами, но высокими рисками "завязывания" кода. С другой - микросервисы, хайповый и популярный путь с минимумом зависимостей, но сложностью развертывания и взаимодействия между сервисами.
А что если мы постараемся взять плюсы обоих подходов?
Допустим, у нас есть веб-сервис, единый (монолитный) исполняемый файл, под которым прячутся 2-4 микросервиса.
Какие плюсы:
- Простота развертывания. Один докерфайл и больше ничего. В отличие от классических микросервисов.
- Слабая связанность. Микросервисы внутри строго отделены друг от друга. От монолита требуется только запустить их всех вместе.
- Очень быстрый переход на микросервисные рельсы, в случаях, когда это необходимо. Мы просто выносим микросервис из монолита и разворачиваем отдельно по щелчку пальца.
Минусы:
- Нужно очень хорошо продумать архитектуру решения. Так чтобы можно было и быстро микросервис отделить и обеспечивалась достаточная обобщенность настройки.
- Не все внешние библиотеки можно настроить для исполнения под такой архитектурой. Я бы даже сказал, что их достаточно мало.
Можно сказать, что это переизобретенный SOA, но ключевое отличие тут в том, что микросервис - это не модуль ПО, а полноценное приложение со своими точками входа для пользователей.
Пример подобной архитектуры можно посмотреть в нашем репозитории для битвы
👾 PICO
Developer Experience
Недавно состоялся вебинар в моей любимой школе сильных программистов на тему так называемого developer experience. Не сказать, что он прошел прям увлекательно, но и не бесполезно🏃♀️
Если кратко, то DevEx - это про удобство разработчика. А суть развития DevEx - это привнесение в свою профессиональную деятельность больше удовольствия (читай: эффективности) и, соответственно, меньше ерунды.
В разработке обычно как, вот есть у тебя кодовая база, сиди работай. Горит дедлайн? Нужно успеть в срок. Огромный техдолг? Терпи, братиш, мы - бизнес, мы рубим деньги. Мы работаем на пределе возможностей, но нужен результат лучше? Просто наймем новых программистов! Или ничего не будем делать, если денег нет :C
Крайне мало кто задумывается о том, а насколько программистам в удовольствие работать в компании? Сравнивать максимализируя лучше всего.
Вот есть программист Паша, работает с легаси кодовой базой, огромным техдолгом и 1-2 встречами в день по часу каждая. Будет ли он доволен? Будет ли эффективен? Да конечно нет, ему захочется скорее закрыть IDE с этим ужасом и пойти домой пилить свои пет-проекты. Повседневная деятельность Паши в тягость
А есть разработчик Юля, работает в репозитории с чистой архитектурой, с автотестами и автодеплоем. Будет ли она довольна? Будет ли эффективна? Ну конечно да! Ведь на выполнение задач уходит в разы меньше времени, а количество багов измеряется единицами. Повседневная деятельность Юли в радость
В DevEx легко разглядеть реально полезный для всех сторон (win-win) мотиватор. Делай своим разработчикам хорошо и получай эффективный результат. В слепой погоне за целями часто можно упустить простейшие инструменты повышения эффективности, этот, на мой взгляд, один из таких. Что-то из серии "нормально делай - нормально будет".
Ну а если вы не управляете людьми - вы можете инвестировать в свой собственный DevEx. Просто спросите себя: А что я могу сделать, чтобы получать больше удовольствия от повседневной разработки?
Возможно, ответ вас удивит🐸 🐸 🐸
👾 PICO
Недавно состоялся вебинар в моей любимой школе сильных программистов на тему так называемого developer experience. Не сказать, что он прошел прям увлекательно, но и не бесполезно
Если кратко, то DevEx - это про удобство разработчика. А суть развития DevEx - это привнесение в свою профессиональную деятельность больше удовольствия (читай: эффективности) и, соответственно, меньше ерунды.
В разработке обычно как, вот есть у тебя кодовая база, сиди работай. Горит дедлайн? Нужно успеть в срок. Огромный техдолг? Терпи, братиш, мы - бизнес, мы рубим деньги. Мы работаем на пределе возможностей, но нужен результат лучше? Просто наймем новых программистов! Или ничего не будем делать, если денег нет :C
Крайне мало кто задумывается о том, а насколько программистам в удовольствие работать в компании? Сравнивать максимализируя лучше всего.
Вот есть программист Паша, работает с легаси кодовой базой, огромным техдолгом и 1-2 встречами в день по часу каждая. Будет ли он доволен? Будет ли эффективен? Да конечно нет, ему захочется скорее закрыть IDE с этим ужасом и пойти домой пилить свои пет-проекты. Повседневная деятельность Паши в тягость
А есть разработчик Юля, работает в репозитории с чистой архитектурой, с автотестами и автодеплоем. Будет ли она довольна? Будет ли эффективна? Ну конечно да! Ведь на выполнение задач уходит в разы меньше времени, а количество багов измеряется единицами. Повседневная деятельность Юли в радость
В DevEx легко разглядеть реально полезный для всех сторон (win-win) мотиватор. Делай своим разработчикам хорошо и получай эффективный результат. В слепой погоне за целями часто можно упустить простейшие инструменты повышения эффективности, этот, на мой взгляд, один из таких. Что-то из серии "нормально делай - нормально будет".
Ну а если вы не управляете людьми - вы можете инвестировать в свой собственный DevEx. Просто спросите себя: А что я могу сделать, чтобы получать больше удовольствия от повседневной разработки?
Возможно, ответ вас удивит
👾 PICO
Please open Telegram to view this post
VIEW IN TELEGRAM
💩2
Каша в репозитории
В недавнем прямом эфире на хабр.карьере я рассказывал про SpecFlow и вскользь упомянул о "каше", которая появляется, если разработчики перестают следить за структурой и жёсткими рамками архитектуры проекта.
Казалось бы, проблема не нова, но до сих пор встречаю репозитории с этой проблемой, где просто нет внятных решений, которые бы направляли и подсказывали мне "а как тут принято".
Отсутствие подобных решений приводит к тому, что новый код, который напишется в рамках работы над репозиторием, будет лишён "направления". И получается, что каждый программист привносит в структуру репозитория свое собственное видение, которое ничем не ограничено, что и влечет за собой появление "каши". Достаточно неприятный фактор, контроль которого ложится на плечи роли, отвечающей за архитектуру решения. Но чаще всего на проблему просто забивают.
Методик избавления от этой каши много, но их все объединяет один принцип - это выстраивание архитектурных ограничений.
В последнее время я применяю для этого несколько подходов:
- Гексагональная архитектура. Стандартный способ разделения приложения на слои. Глубину ее применения можно очень удобно регулировать, например, объединив слои Application и Domain, если доменная область достаточно проста. Это позволяет контролировать гибкость внедряемых архитектурой ограничений.
- Feature Sliced Design (FSD). Суть его в том, что сначала кодовая база разделяется на слои, затем на фичи (слайсы), и лишь только в конце на компоненты (репозитории, команды, хелперы и тд.). Не смотря на то, что подход считается основой для фронтендеров - ничего не мешает применять схожий подход и на бекенде. Его внедрение в конечном итоге очень сильно помогает быстрее искать место необходимости внесения изменений и кратно снижает когнитивную нагрузку.
- SpecFlow и ATDD. Написание нового функционала через автотесты автоматически добавляет ограничение "тестируемости", что хорошо сказывается как на архитектуре, так и на качестве итогового продукта, его готовности к последующим изменениям.
👾 PICO
В недавнем прямом эфире на хабр.карьере я рассказывал про SpecFlow и вскользь упомянул о "каше", которая появляется, если разработчики перестают следить за структурой и жёсткими рамками архитектуры проекта.
Казалось бы, проблема не нова, но до сих пор встречаю репозитории с этой проблемой, где просто нет внятных решений, которые бы направляли и подсказывали мне "а как тут принято".
Отсутствие подобных решений приводит к тому, что новый код, который напишется в рамках работы над репозиторием, будет лишён "направления". И получается, что каждый программист привносит в структуру репозитория свое собственное видение, которое ничем не ограничено, что и влечет за собой появление "каши". Достаточно неприятный фактор, контроль которого ложится на плечи роли, отвечающей за архитектуру решения. Но чаще всего на проблему просто забивают.
Методик избавления от этой каши много, но их все объединяет один принцип - это выстраивание архитектурных ограничений.
В последнее время я применяю для этого несколько подходов:
- Гексагональная архитектура. Стандартный способ разделения приложения на слои. Глубину ее применения можно очень удобно регулировать, например, объединив слои Application и Domain, если доменная область достаточно проста. Это позволяет контролировать гибкость внедряемых архитектурой ограничений.
- Feature Sliced Design (FSD). Суть его в том, что сначала кодовая база разделяется на слои, затем на фичи (слайсы), и лишь только в конце на компоненты (репозитории, команды, хелперы и тд.). Не смотря на то, что подход считается основой для фронтендеров - ничего не мешает применять схожий подход и на бекенде. Его внедрение в конечном итоге очень сильно помогает быстрее искать место необходимости внесения изменений и кратно снижает когнитивную нагрузку.
- SpecFlow и ATDD. Написание нового функционала через автотесты автоматически добавляет ограничение "тестируемости", что хорошо сказывается как на архитектуре, так и на качестве итогового продукта, его готовности к последующим изменениям.
👾 PICO
❤3
GraphQL + CQRS
Решил наконец ознакомиться с графом и был приятно удивлен его возможностями.
Представим, что нам необходимо сделать функционал отображения двух списков. Первый - подробный, с названием, картинками, длинным описанием и комментариями. Второй - упрощенный, отображающий только название входящих в него элементов
В REST мы бы подготовили два эндпоинта. Один для получения полного списка, второй для упрощённого. При этом на бекенде необходимо будет для каждого эндпоинта реализовать свой маппинг.
А в графе все очень просто. Мы описываем максимально полную модель подробного списка. А уже на фронтенде определяем где нам нужно выгрузить подробную информацию по списку, а где нужна минимальная, просто передавая на бекенд поля, которые ожидаем получить.
Плюс ко всему, в рамках одного запроса к одному эндпоинту графа мы можем получить сразу несколько сущностей, обращаясь как будто бы к разным эндпоинтам REST'а.
Это даёт огромную гибкость, атомарность в разработке фронтенда и упрощает архитектуру бекенда.
Правда точки зрения скорости не все гладко, на каждый запрос нам приходится так и так доставать из базы максимально полную модель требуемых данных, а затем резать их перед отдачей на фронт. Ну, или придумывать довольно непростые хаки, чтобы оптимизировать чтение.
На GraphQL очень хорошо ложится CQRS паттерн. Поскольку на фронте мы получаем атомарность, можно экстраполировать ее и на наш бекенд. В рамках запроса могут выполниться, например, одновременно несколько queries или commands, отрабатывая по очереди на уровне бекенда.
Таким образом мы получаем четкое разделение ответственности на бекенде, избавляемся от каши в репозитории и соблюдаем единообразие кодовой базы.
Я определенно точно познал не весь дзен использования графа. Продолжаю наблюдение👀
- GraphQL для C#: HotChocolate
👾 PICO
Решил наконец ознакомиться с графом и был приятно удивлен его возможностями.
Кто не в теме, очень кратко:
GraphQL - это прямая противоположность REST. Единая точка входа. Принимает набор команд, отдает результат их исполнения. При этом в самом запросе определяются возвращаемые данные.
Представим, что нам необходимо сделать функционал отображения двух списков. Первый - подробный, с названием, картинками, длинным описанием и комментариями. Второй - упрощенный, отображающий только название входящих в него элементов
В REST мы бы подготовили два эндпоинта. Один для получения полного списка, второй для упрощённого. При этом на бекенде необходимо будет для каждого эндпоинта реализовать свой маппинг.
А в графе все очень просто. Мы описываем максимально полную модель подробного списка. А уже на фронтенде определяем где нам нужно выгрузить подробную информацию по списку, а где нужна минимальная, просто передавая на бекенд поля, которые ожидаем получить.
Плюс ко всему, в рамках одного запроса к одному эндпоинту графа мы можем получить сразу несколько сущностей, обращаясь как будто бы к разным эндпоинтам REST'а.
Это даёт огромную гибкость, атомарность в разработке фронтенда и упрощает архитектуру бекенда.
Правда точки зрения скорости не все гладко, на каждый запрос нам приходится так и так доставать из базы максимально полную модель требуемых данных, а затем резать их перед отдачей на фронт. Ну, или придумывать довольно непростые хаки, чтобы оптимизировать чтение.
На GraphQL очень хорошо ложится CQRS паттерн. Поскольку на фронте мы получаем атомарность, можно экстраполировать ее и на наш бекенд. В рамках запроса могут выполниться, например, одновременно несколько queries или commands, отрабатывая по очереди на уровне бекенда.
Таким образом мы получаем четкое разделение ответственности на бекенде, избавляемся от каши в репозитории и соблюдаем единообразие кодовой базы.
Я определенно точно познал не весь дзен использования графа. Продолжаю наблюдение
- GraphQL для C#: HotChocolate
👾 PICO
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3