Эргономичный код

Привет! Играюсь со сборкой сервиса в нативное приложение, чёт мемасик вспомнился. Как закончу - напишу микропост о своих приключениях

Привет! У меня за топиками декомпозиции ретро Проекта Э не получается раскрыть тему тестирования. И вот какой-то добрый человек сделал это за меня. С реализацией я не во всём согласен (в частности на Gherkin я со скепсисом смотрю), но концептуально - фокус на компонентных тестах и тестирование сценариев - полностью согласен.

Привет! У меня для вас снова поучительная история про тесты. У нас есть эндопинт выдачи списка лекарств за разработкой которого я не много не доглядел и там разработчик не сделал сортировку. Этот список год не менялся и изначально данные в него внесли в правильном порядке, поэтому никто не замечал проблему. А тут поменяли и ой. И я пошёл добавлять сортировку своими мозолистыми руками. Добавил, думаю надо тестом покрыть, покрыть, думаю надо увидеть как он превращается из красного в зелёный, сломал продовый код, а тест прошёл. Смотрю - прошёл по той же причине, что и в проде год проблемы не было. Ну думаю и ладно, чему там не работать, закоммитал, запушил, вмёржил вмастер. Подтягиваю, мастер в ветку где это надо - а она не собирается О_О Тест не проходит. Потому что данные поменялись. А я продовый код не вернул перед коммитом 🤦‍♂️ Мораль этой басни - очень важно видеть как тест превращается из красного в зелёный. Самый рациональный и надёжный способ это делать - писать сначала тесты. Если вы пишите сначала продовый код - надо хотя бы ломать его после тестов, и убеждаться что они красные, а потом становятся зелёными. Ну а если вы написали продовый код, написали тесты, они сразу прошли и вы на этом остановились - ну чтож, удачи в проде:)

Привет! Сегодня у меня будет три топика. Фидбэк по опросу На той неделе сначала заболел ребёнок и в сад не ходил, потом я от него заразился и тоже в сад не ходил, поэтому припозднился с фидбэком по опросу. Итак, фидбек. Во-первых, спасибо всем проголосовавшим. Во-вторых, вижу, что тема актуальная, поэтому посту быть. В-третьих, я учту результаты опроса и чуть подробнее распишу оценку, продажу, планирование, модель ветвтеления и техсложности, а деплой наборот опишу вкратце. В-четвёртых, есть два голоса за "другое", но без комментариев - у вас всё ещё есть возможность написать, о чём вам было бы интересно узнать, так как у меня новых идей не появилось. Новый микропрост На выходных я пропрокрастинировал пост с ретро Проекта Э микропостом (опять же по степени полировки, а не объёму) с описанием решения потенциального "сложного случая" при декомпозиции диаграммы эффектов новой интеграции в Проекте Э. Ну или аннотация привлекательная для более широкой аудитории - написал микропост с алгоритмом принятия решения о том, в какой класс или микросервис поместить операцию, которая в равной степени зависит от двух классов/микросервисов. Пост с ретро Проекта Э Попробую проверить расхожее мнение о том, что публичное обещание помогает в решении задач, которые никак не получается решить. Итак - торжественно клянусь, что с завтрашнего дня я буду заниматься постом с ретро минимум 15 минут в день и каждый день в комментариях к этому посту буду писать о своём прогрессе (ну или о непреодолимых обстоятельствах, которые сложились так, что не было никакой возможности уделить этой работе хотя бы 15 минут). Текущее состояние поста следующее: 1. В посте есть 3500 слов примерно на 20-25 минут чтения 2. Осталось расписать - техсложности, факапы в проде, деплой, итоговые цифры 3. После чего будет скорее всего долгий и мучительный процесс полировки, который среди прочего будет включать: 3.1 Более глубокое раскрытие "популярных" тем 3.2 Добавление в каждый раздел подраздела "Полезняшки" - что вы себе сможете утащить из моего опыта.

Привет! Вернулся из отпуска и собираюсь таки добить большой пост с ретро реинжинринга Проекта Э. Но у меня появились сомнения и в том, что тема в целом актуальная и в актуальности отдельных топиков, поэтому решил провести опрос чтобы понять надо ли об этом писать и о чём именно писать. Опубликую опрос следующим постом

Хотите анекдот? Делал я тут недавно заказ всякой мелочёвки в отпуск (кстати, я уезжаю в отпуск, так что в канале будет пара недель тишины). Набрал 3-4 итема суммарно на 1500 рублей. Оплачиваю через СБП - они снимают 500, и говорят, что заказ не оплачен. Ну я не будь дурак, повторяю фокус ровно с тем же результатом. Вспоминаю Эйнштейна, оплачиваю картой - всё ок. Тут же пишу в поддержку, как мне вернуть деньги. Они через какое-то время отвечают, но нотификацию не присылают и благополучно об этой истории забываю. Пришло время забрать заказ - смотрю, а у меня их три 🤦‍♂️, один полностью оплачен, два частично. Забирать лишнее я не буду, так что у меня ещё рублей 600 за отказ поди отожмут. Разбираться щяс некогда, буду пытаться выцыганить свои 1600 назад после отпуска и сильно сомневаюсь в успехе этого мероприятия. Уверен, что у пацанов там микросервисы, саги, согласованность в конечном итоге и вот это вот всё. За что лично я заплачу своих кровно заработанных полторы тыщи. Так и живём. Если после отпуска не забуду про эту песню - расскажу чем дело кончилось.

Привет! На денёк задержался, но это потому что у меня были очень интересные приседнания с тестами в эргономичном стиле - может после отпуска расскажу:) И так, та-да-да, микропост с результатами анализа Jira Проекта Э. Пост оказался микро только с точки зрения полировки, а по объёму - вполне себе приличный пост, поэтому сразу ТЛДР: 1) Мы действительно стали работать в два раза быстрее и допускать в два раза меньше багов 2) Я получил дополнительное подтверждение вцелом очевидным вещам: 2.1) Первый год разработки на микросервисах дороже разработки на монолите. Минимум на 30%; 2.2) Автоматизация тестирования снижает количество багов и трудозатрат на их устранение. Минимум в два раза; 2.3) Мотивация команды имеет огромное влияние на трудозатарты. От 30% дополнительных трудозатрат в случае низкой мотивации.

Привет! Микроретро со статистикой по реинжинирингу уже почти готово - завтра-послезавтра опубликую. Спойлер - могу с уверенностью заявить, что цели "сократить трудозатраты и количество багов вдвое" нам удалось достичь:) И сейчас я пишу спекулятивную часть - "А чтобы было, если бы реинжиниринг выполнялся по мейнстримному подходу - с тестами на моках, Hibernate и пакетированием по техническим аспектам?" Написав это, я засомневался - а правда ли это всё ещё мейнстрим? А то вон на конференциях всё чаще мелькает Spring Data Jdbc, всевозможные вариации на предмет вертикальной декомпозиции и ДДД. Решил проверить так - взять первую попавшуюся на Packtpub-е свежую книгу по спрингу и посмотреть что там. И знаете что там? Ровно всё то, что я перечислил:) На всякий случай глянул вторую книгу - там пакетирования вообще никакого нет, зато хибер и моки - на месте:) Обе книги - декабрь 22-ого года.

Привет! С подачи Романа Русакова запоем прочитал The API. Очень крутая книга, рекомендую. Роман - спасибо:) Так же вы, возможно, задаётесь вопросом что это я затих. Вряд ли, конечно, но я всё равно отвечу - лопачу джиру Проект Э:) Чтобы понять стоило ли оно того. Джира, у нас, к сожалению, не в лучшем состоянии и я не большой специалист по её анализу, поэтому идёт тяжко и в зависимости от методики результат получается от хрен на хрен, до 10х улучшения. Но что радует - нигде нет просадки ни по одной метрике. Сейчас я вроде собрал методику, которая должна дать более-менее вменяемые цифры, которые, я надеюсь сойдутся к 1.5х снижению трудозатрат и 2х снижению кол-ва багов. Осталось доразмечать 517 задач:)

Привет! У нас тут на проекте случилась поучительная история про REST, плюс посмотрел REST next level: Crafting domain-driven web APIs by Julien Topçu @ Spring I/O 2023 - по мотивам всего этого накатал очередной микропост - что-то я разошёлся в этом месяце:)

Привет! У нас тут на проекте случилась поучительная история про REST, плюс посмотрел REST next level: Crafting domain-driven web APIs by Julien Topçu @ Spring I/O 2023 - по мотивам всего этого накатал очередной микропост - что-то я разошёлся в этом месяце:)

Привет! Я недавно был на тренинге по ораторскому мастерству. И там тренер сказал, что выступать боятся все. Но опытные спикеры боятся реакции аудитории "Спасибо, Кэп". Другая большая проблема опытных спикеров - сохранять огонь в глазах. И у меня была ровно такая реакция на последний доклад Кевлина Хенни, который я смотрел. Поэтому когда я собирался смотреть Refactoring Is Not Just Clickbait - Kevlin Henney - NDC London 2023, я подумал, что если и там будет "спасибо, кэп" - я перестану следить за творчеством Кевлина. И там был повтор. Но один:) А в целом - прикольный философский доклад. Больше всего меня там зацепило, что он попинал OCP: > OCP - is'a a failure of good practice.It's failure of architecture, if you doing that Но он (как и анкл Боб, впрочем) лукавит. Думаю намеренно. Потому что ответ на вопрос "Хорош ли OCP", как всегда - It Depends. Если вы делаете прикладное приложение и боитесь его менять - это действительно проблема архитектуры. А вот если вы делаете фреймворк, или платформу со сторонними плагинами - без OCP ничего не получится. Вопрос в том, много ли из нас делает фреймворки и платформы:) Запилю-ка опрос:) И ещё полезняшка - если работаете под звуки дождя и затупили - включите прогрессивный металл. Если работаете под прогрессивный металл и затупили - включите звуки дождя:)

А ещё подъехали новые видосы со Spring.io 23, в том числе The Aggregate is dead. Long live the Aggregate!. Там авторы полдоклада пинают концепцию агрегата (в целом за дело, имхо), а в конце предлагают некоторый аналог compare-and-swap/optimistic locking для эвент сорсинга. И с учётом того, что я бы предпочёл держаться от эвент сориснга подальше настолько, насколько это возможно, то на мой взгляд доклад представляет скорее общеобразовательный, чем практический интерес.

Привет! У меня появились некоторые подвижки в решении проблем из этого поста. О чём я написал отдельный микропост:)

Привет! Посмотрел Don’t Build a Distributed Monolith - там мужик в бонусной проблеме как и я говорит, что микросервисы разрабатываемые одним человеком - мощная заявка на распределённый монолит. В целом в докладе не то чтобы есть какие откровения, но посмотреть можно. А потом посмотрел Top 5 techniques for building the worst microservice system ever. Вот тут в конце уже было некоторое откровение. Для реализации агрегации данных из разных сервисов, чувак предлагает сбор этих данных делать в репозе сервисов-владельцев, но деплоить этот код в сервисе-агрегаторе. Я не то чтобы побежал это делать, но идея кажется любопытной. Вы, возможно удивляетесь, что это я, МСо-хейтер, заинтересовался ими. Отвечаю - код Проекта Э, начинает подходить к пределам по размеру эргономичной кодовой базы, начинают появляться операционные драйверы разделения кодовой базы и прорисовываются границы, по которым код можно эргономично нарезать. Поэтому я потихоньку задумываюсь о том, как проект перенарезать на хорошие МСы и не облажаться при этом.

Привет! Как и обещал, пишу о впечатлениях от переезда на Spring Boot 3.1. Их нет. Накрутил версию гредлового плагина до 3.1.0, заменил зависимость тестконтейнеров на testImplementation("org.springframework.boot:spring-boot-testcontainers") и всё. Приложение собралось и запустилось, все тесты прошли. Я это в мастер в следующий цикл вмёржу - может на стендах что-то вылезет. Чуть поинтереснее история с интеграцией с композом. 1. Добавил в грэдл developmentOnly("org.springframework.boot:spring-boot-docker-compose") Добавил конфиг application-local-dev.yml:

spring:
  docker:
    compose:
      file: ./env/docker-compose-infra.yml
      enabled: true
      lifecycle-management: start_only

И почти всё. Была одна проблема - в какой-то обвязке кролика vhost захардкожен в "/", а нам в наследство достался нестандартный. Это под правил - и всё взлетело. Потом ещё небольшая мелочушка была - через спринг нельзя прописать имя композ-проекта - добавил его в композ файл. И вот это совсем всё. Теперь у нас сетап выглядит так: 1. Поставить Джаву, Идею, Докер, Гит 2. Качнуть репоз 3. Запустить приложение в Идеи 4. Готово Я хоть и не люблю спринг за его монструозность и автомагичность, но вот такие плюшки прям подкупают. Плюс у нас есть ещё скриптик (правда только под Linux), который качает дампы из дев кластера и если его запустить между шагами 2 и 3 - будет ещё и сетап на живых данных. И бонусом ещё немного нашей внутренней кухни - рядом с композом инфраструктуры у нас есть композ, который умеет запускать несколько экземпляров приложения с роутингом через traefik - соответственно потестить работу в многонодовом режиме тоже можно в одну кнопку.

Привет! Накатал микропост о том как мы руками делали потоковый джон двух БД для админки в Проекте Э. Если кто-то на будущее научит меня как это можно было сделать быстрее и проще - буду благодарен:)