Привет!
Вчера задеплоили в прод результаты первых трёх спринтов -первый кусочек (~20%) нового бэка Проекта Э, в проде нашли один баг нового бэка, и старый баг в старом бэке:) Я считаю неплохо.
От графика отстаём, но первые спринты были тяжёлые из-за не отлаженного "техпроцесса", плюс часть сил уходила, на новые фичи и поддержку старых. Но сейчас уже более-менее вышли на штатный режим работы и кажется ещё есть шанс уложиться в первоначальный график.
Касательно Эргономичного подхода у меня на подходе (pun intended) лендинг для него - планирую зарелизать на следующей недели
А до конца года я собираюсь выложить версию 0.1.0 диаграммы эффектов, с более согласованной концептуальной моделью и остальной частью отредактированной профессиональным техписателем.
После этого я наконец вернусь к большим постам. Сейчас у меня есть идеи четырёх потенциальный поста:
1) Наконец написать пост по декомпозиции проекта TSP на базе диаграммы эффектов
2) Пост о шаблоне раскладки кода по пакетам в Эргономичном подходе
3) Пост о том, почему я считаю, что ФП стиль даёт лучшие результаты, с точки зрения суммарной стоимости разработки
4) Собственный пост о функциональной архитектуре с заходом через трансформационно-центричную морфологию из структурного дизайна.
Так же практика прошлых лет показывает, что у меня первая половина года намного богаче на посты, чем вторая, так что стей тюнед, будет интересно:)
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Вчера задеплоили в прод результаты первых трёх спринтов -первый кусочек (~20%) нового бэка Проекта Э, в проде нашли один баг нового бэка, и старый баг в старом бэке:) Я считаю неплохо.
От графика отстаём, но первые спринты были тяжёлые из-за не отлаженного "техпроцесса", плюс часть сил уходила, на новые фичи и поддержку старых. Но сейчас уже более-менее вышли на штатный режим работы и кажется ещё есть шанс уложиться в первоначальный график.
Касательно Эргономичного подхода у меня на подходе (pun intended) лендинг для него - планирую зарелизать на следующей недели
А до конца года я собираюсь выложить версию 0.1.0 диаграммы эффектов, с более согласованной концептуальной моделью и остальной частью отредактированной профессиональным техписателем.
После этого я наконец вернусь к большим постам. Сейчас у меня есть идеи четырёх потенциальный поста:
1) Наконец написать пост по декомпозиции проекта TSP на базе диаграммы эффектов
2) Пост о шаблоне раскладки кода по пакетам в Эргономичном подходе
3) Пост о том, почему я считаю, что ФП стиль даёт лучшие результаты, с точки зрения суммарной стоимости разработки
4) Собственный пост о функциональной архитектуре с заходом через трансформационно-центричную морфологию из структурного дизайна.
Так же практика прошлых лет показывает, что у меня первая половина года намного богаче на посты, чем вторая, так что стей тюнед, будет интересно:)
#project_e@ergonomic_code #ergo_approach@ergonomic_code
👍5
Привет!
Чемзадро люди, нашедшие работу по душе занимаются на праздничных днях? Правильно - переводят проекты на Spring Boot 3.
И я, будучи таким человеком, перевёл Проект Э на Spring Boot 3.
За пару месяцев работы в 3.5 лица мы нагенеряли довольно дофига кода - 300 *.kt-файлов и тем не менее переезд мне дался довольно легко. Сделал я его часа за 2, изменения внёс следующие:
1) очевидным образом, обновил версии
2) заменой по проекту поправил javax.* -> jakarta.*
3) Поменял com.github.tomakehurst:wiremock-jre8:2.35.0 -> com.github.tomakehurst:wiremock-jre8-standalone:2.35.0. Без этого были проблемы со спекой сервлетов, что ли
4) В конфиге Spring Security заменой по файлу поправил antMatchers -> requestMatchers
5) Руками поудалял ConstructorBinding
6) Больше всего времени ушло на то, чтобы реанимировать вытягивание доков к эндпоинтам в сваггере из котлин доков. Для этого пришлось руками добавить зависимость runtimeOnly("com.github.therapi:therapi-runtime-javadoc:0.15.0"), а допетрить до того, что этот джарник пропал из зависимостей (без ошибок) пришлось самостоятельно
7) всё. Все 100+ тестов (преимущественно пользовательских/внешних/функциональных/е2е) прошли, приложение благополучно задеплоилось на тестовый стенд. Но его ещё не тестили (почему-то), так что может что-то ещё вылезет. Если вылезет - напишу
Наверное, мне сильно помогло то, что проект я заводил за месяц до релиза Бута 3 и проект у меня был на Буте 2.7.4. Я на самом деле даже попытался сразу стартануть на бете Бута 3, но тогда не получилось завести то ли сваггер целиком, то ли вытягивание котлин доков - круто что уже через месяц после релиза это всё допилили.
При всём моём противоречивом (но всё более положительном в последнее время) отношении к Spring - они реально делают штуку, которая just works (tm).
#spring@ergonomic_code #project_e@ergonomic_code #case@ergonomic_code
Чем
И я, будучи таким человеком, перевёл Проект Э на Spring Boot 3.
За пару месяцев работы в 3.5 лица мы нагенеряли довольно дофига кода - 300 *.kt-файлов и тем не менее переезд мне дался довольно легко. Сделал я его часа за 2, изменения внёс следующие:
1) очевидным образом, обновил версии
2) заменой по проекту поправил javax.* -> jakarta.*
3) Поменял com.github.tomakehurst:wiremock-jre8:2.35.0 -> com.github.tomakehurst:wiremock-jre8-standalone:2.35.0. Без этого были проблемы со спекой сервлетов, что ли
4) В конфиге Spring Security заменой по файлу поправил antMatchers -> requestMatchers
5) Руками поудалял ConstructorBinding
6) Больше всего времени ушло на то, чтобы реанимировать вытягивание доков к эндпоинтам в сваггере из котлин доков. Для этого пришлось руками добавить зависимость runtimeOnly("com.github.therapi:therapi-runtime-javadoc:0.15.0"), а допетрить до того, что этот джарник пропал из зависимостей (без ошибок) пришлось самостоятельно
7) всё. Все 100+ тестов (преимущественно пользовательских/внешних/функциональных/е2е) прошли, приложение благополучно задеплоилось на тестовый стенд. Но его ещё не тестили (почему-то), так что может что-то ещё вылезет. Если вылезет - напишу
Наверное, мне сильно помогло то, что проект я заводил за месяц до релиза Бута 3 и проект у меня был на Буте 2.7.4. Я на самом деле даже попытался сразу стартануть на бете Бута 3, но тогда не получилось завести то ли сваггер целиком, то ли вытягивание котлин доков - круто что уже через месяц после релиза это всё допилили.
При всём моём противоречивом (но всё более положительном в последнее время) отношении к Spring - они реально делают штуку, которая just works (tm).
#spring@ergonomic_code #project_e@ergonomic_code #case@ergonomic_code
👍8
Ну и заодно вести с полей Проекта Э.
На скрине разработчик говорит о последнем кусочке и немножко драматизирует на мой взгляд, но в целом с проектом (именно реинжиниринга) ситуация примерно такая - местами было непросто, но, судя по всему, в этот (10ый) спринт закончим.
Обязательно напишу пост с ретро проекта, и может даже удастся это до JPoint-а осилить
#project_e@ergonomic_code
На скрине разработчик говорит о последнем кусочке и немножко драматизирует на мой взгляд, но в целом с проектом (именно реинжиниринга) ситуация примерно такая - местами было непросто, но, судя по всему, в этот (10ый) спринт закончим.
Обязательно напишу пост с ретро проекта, и может даже удастся это до JPoint-а осилить
#project_e@ergonomic_code
❤2👍1
Привет!
В Проекте Э сегодня прибили последние два микросервиса на дев окружении и в пн планируем докатить последние куски до прода.
Немного статистики:
1) 23,944 строк кода
2) 730 классов
3) 234 теста (преимущественно интеграционных)
4) 100% покрытие эндпоинтов тестами
5) 93.2% покрытия строк кода тестами
6) 1:30 минут полное время сборки, включая все тесты, тесты архитектуры, detekt, сборку и верификацию покрытия кода
7) 10 спринтов
8) 154 календарных дня активной разработки
9) ~1446.55 часов джунов
10) 590.75 часов лида (меня)
11) 55 багов:) всего - включая те, что нашли сами и QA
#project_e@ergonomic_code
В Проекте Э сегодня прибили последние два микросервиса на дев окружении и в пн планируем докатить последние куски до прода.
Немного статистики:
1) 23,944 строк кода
2) 730 классов
3) 234 теста (преимущественно интеграционных)
4) 100% покрытие эндпоинтов тестами
5) 93.2% покрытия строк кода тестами
6) 1:30 минут полное время сборки, включая все тесты, тесты архитектуры, detekt, сборку и верификацию покрытия кода
7) 10 спринтов
8) 154 календарных дня активной разработки
9) ~1446.55 часов джунов
10) 590.75 часов лида (меня)
11) 55 багов:) всего - включая те, что нашли сами и QA
#project_e@ergonomic_code
Telegram
Эргономичный код
Привет!
Раскрою одну из причин, почему я приостановил проработку Эргономичного подхода.
По сути - у меня появилась возможность на практике проверить тезис, что Эргономичный подход даёт существенный выигрыш в производительности разработчиков.
Я уже несколько…
Раскрою одну из причин, почему я приостановил проработку Эргономичного подхода.
По сути - у меня появилась возможность на практике проверить тезис, что Эргономичный подход даёт существенный выигрыш в производительности разработчиков.
Я уже несколько…
Привет!
Ретро проекта Э идёт прям тяжело (тупо прокрастинирую его), поэтому решил написать микроретро очередного релиза.
В этом релизе, мы среди прочего сделали две большие штуки:
. Реализовали поддержку множества сессий пользователей - 73 файла, ~1200 строк изменений (ввели понятие сессии и привязали рефреш-токен к ней, а не пользователям. Плюс сделали бесшовную миграцию токенов);
. Серьёзно отрефакторили модуль наблюдения, поправив логические и технические ошибки в изначальной модели - 129 файлов, ~2300 строк изменений.
Ещё хочу напомнить, что месяц назад у нас в проекте всего было 23,944 строк кода и 730 классов.
То есть в этом релизе релизе мы потрогали процентов 15 всей кодов базы.
При этом:
. Багов, найденных командой QA за 3 дня тестирования релиз-кандидата - 0 (ноль);
. Багов, найденных заказчиком и пользователями за 5 дней использования релиза - 0 (ноль);
. Багов, найденных разработчиком по коду после мёржа в мастер - 1 (один);
Лично я считаю это выдающимся достижением.
Это, безусловно, преимущественно заслуга разработчиков, но и ЭП тоже внёс существенный вклад, на мой взгляд.
Как минимум в части тестов без моков и сфокусированных на проверке наблюдаемого поведения системы.
#why_ergo_approach@ergonomic_code #ergo_testing@ergonomic_code #project_e@ergonomic_code #case@ergonomic_code
Ретро проекта Э идёт прям тяжело (тупо прокрастинирую его), поэтому решил написать микроретро очередного релиза.
В этом релизе, мы среди прочего сделали две большие штуки:
. Реализовали поддержку множества сессий пользователей - 73 файла, ~1200 строк изменений (ввели понятие сессии и привязали рефреш-токен к ней, а не пользователям. Плюс сделали бесшовную миграцию токенов);
. Серьёзно отрефакторили модуль наблюдения, поправив логические и технические ошибки в изначальной модели - 129 файлов, ~2300 строк изменений.
Ещё хочу напомнить, что месяц назад у нас в проекте всего было 23,944 строк кода и 730 классов.
То есть в этом релизе релизе мы потрогали процентов 15 всей кодов базы.
При этом:
. Багов, найденных командой QA за 3 дня тестирования релиз-кандидата - 0 (ноль);
. Багов, найденных заказчиком и пользователями за 5 дней использования релиза - 0 (ноль);
. Багов, найденных разработчиком по коду после мёржа в мастер - 1 (один);
Лично я считаю это выдающимся достижением.
Это, безусловно, преимущественно заслуга разработчиков, но и ЭП тоже внёс существенный вклад, на мой взгляд.
Как минимум в части тестов без моков и сфокусированных на проверке наблюдаемого поведения системы.
#why_ergo_approach@ergonomic_code #ergo_testing@ergonomic_code #project_e@ergonomic_code #case@ergonomic_code
👍2🔥2👌2
Привет!
Вчера в Проекте Э пришлось подравить пару МРов своими собственными руками (редкое событие в последнее время, к сожалению), чтобы успеть заталкать в релиз.
И в обоих случаях ТДД спасло меня от внесения багов.
В первом случае мне надо было замапить ошибку нарушения уникальности констрейнта с 500 на доменно-специфичную. Я как и положено начал с теста, починил, увидел зелёный тест и пошёл рефакторить. И сломал. Благо тест отловил.
Во втором случае, я в оригинальном МРе убрал часть логики (обновление времени действия пользователя в одном из кейсов). А потом выяснилось что всё-таки обновлять время надо. На этот кейс теста не было, поэтому я опять же начал с него. Вернул оригинальный код и. Тест не прошёл. Там был баг. Который я благополучно починил.
В общем прям советую взять в практику разработку через тесты. А чтобы это не было мучитльно больно - писать тесты без моков и на максимально высоком уровне абстракции (с позиции пользователя)
#project_e@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code
Вчера в Проекте Э пришлось подравить пару МРов своими собственными руками (редкое событие в последнее время, к сожалению), чтобы успеть заталкать в релиз.
И в обоих случаях ТДД спасло меня от внесения багов.
В первом случае мне надо было замапить ошибку нарушения уникальности констрейнта с 500 на доменно-специфичную. Я как и положено начал с теста, починил, увидел зелёный тест и пошёл рефакторить. И сломал. Благо тест отловил.
Во втором случае, я в оригинальном МРе убрал часть логики (обновление времени действия пользователя в одном из кейсов). А потом выяснилось что всё-таки обновлять время надо. На этот кейс теста не было, поэтому я опять же начал с него. Вернул оригинальный код и. Тест не прошёл. Там был баг. Который я благополучно починил.
В общем прям советую взять в практику разработку через тесты. А чтобы это не было мучитльно больно - писать тесты без моков и на максимально высоком уровне абстракции (с позиции пользователя)
#project_e@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code
👍4🤔1
Привет!
Потока сознания пост
У нас тут в Проекте Э был аццкий баг на андроиде. Который заключался в том, что приложение случайным образом переставало подключаться к девайсу по блютузу. Угробили на него кучу времени, сил, денег, нервов, подключились всех кого можно включая меня. В результате фикс получился в 10 символов.
Изначальный код был примерно такой:
Видите баг? Фильтр мапит список на переменную, а потом проверяет что он содержит эту переменную. Очевидно он срабатывал для любого не пустого списка. Добавили в маппинг it.device.address и всё заработало. Я до сих пор не понимаю как - если есть эксперты по андроиду/бле - напишите, пожалуйста:)
Это мне напомнило тезис, что баги - это неверные предположения разработчика. В данном случае разработчик предполагал, что после фильтра у нас в результатах скана будет нужный нам девайс, а его не было.
Во втором баге из вчерашнего поста тоже было ошибочное предположение разработчика. Там в двух разных местах использовалось одно и то же поле для обновления времени последнего действия и разработчик предполагал, что в обоих случаях поле будет содержать текущее время. Что оказалось не так в одном из случаев.
Соответственно мысль №1 - хорошие тесты должны проверять предположения разработчика относительно кода. Например, сохранение сущности значит, что её потом можно достать по иду - вот это и надо проверять. А не то что ид обновился, или что был вызван метод репоза.
Отсюда мысль №2 - моки вносят дополнительный слой предположений. Стабая что-то, разработчик предполагает что вернёт за стабанный код. И может облажаться. Мокая и верифицируя что-то, разработчик предполагает что замоканный код пережуёт то, что разработчик ему дал и породит нужный разработчику эффект. И так же может облажаться.
Я не думаю что возможно (и экономически целесообразно) жить и кодить вообще без предположений и вообще все предположения проверять. Но рефлексировать на эту тему - точно хорошее упражнение.
#case@ergonomic_code #project_e@ergonomic_code #ergo_testing@ergonomic_code
Потока сознания пост
У нас тут в Проекте Э был аццкий баг на андроиде. Который заключался в том, что приложение случайным образом переставало подключаться к девайсу по блютузу. Угробили на него кучу времени, сил, денег, нервов, подключились всех кого можно включая меня. В результате фикс получился в 10 символов.
Изначальный код был примерно такой:
scanner.startScan(filters, settings)
.filter { foundDevices->
foundDevices.map { address }
.contains(address)
}
.take(1)
Видите баг? Фильтр мапит список на переменную, а потом проверяет что он содержит эту переменную. Очевидно он срабатывал для любого не пустого списка. Добавили в маппинг it.device.address и всё заработало. Я до сих пор не понимаю как - если есть эксперты по андроиду/бле - напишите, пожалуйста:)
Это мне напомнило тезис, что баги - это неверные предположения разработчика. В данном случае разработчик предполагал, что после фильтра у нас в результатах скана будет нужный нам девайс, а его не было.
Во втором баге из вчерашнего поста тоже было ошибочное предположение разработчика. Там в двух разных местах использовалось одно и то же поле для обновления времени последнего действия и разработчик предполагал, что в обоих случаях поле будет содержать текущее время. Что оказалось не так в одном из случаев.
Соответственно мысль №1 - хорошие тесты должны проверять предположения разработчика относительно кода. Например, сохранение сущности значит, что её потом можно достать по иду - вот это и надо проверять. А не то что ид обновился, или что был вызван метод репоза.
Отсюда мысль №2 - моки вносят дополнительный слой предположений. Стабая что-то, разработчик предполагает что вернёт за стабанный код. И может облажаться. Мокая и верифицируя что-то, разработчик предполагает что замоканный код пережуёт то, что разработчик ему дал и породит нужный разработчику эффект. И так же может облажаться.
Я не думаю что возможно (и экономически целесообразно) жить и кодить вообще без предположений и вообще все предположения проверять. Но рефлексировать на эту тему - точно хорошее упражнение.
#case@ergonomic_code #project_e@ergonomic_code #ergo_testing@ergonomic_code
👍3
Привет!
В Проекте Э, мы интегрируемся с внешней системой, отправляя туда часть записей дневника пользователя по протоколу MQTT.
И коллеги попросили делать это ровно один раз.
Что невозможно в нашей вселенной.
Я написал для них обоснование невозможности выполнить их просьбу и решил это оформить в микропост в блог - может быть и вам пригодится.
Вариант, что кто-то придёт в комменты и натыкает меня носом в то, как это сделать за 5 минут - мне тоже подходит :)
#posts@ergonomic_code #project_e@ergonomic_code
В Проекте Э, мы интегрируемся с внешней системой, отправляя туда часть записей дневника пользователя по протоколу MQTT.
И коллеги попросили делать это ровно один раз.
Что невозможно в нашей вселенной.
Я написал для них обоснование невозможности выполнить их просьбу и решил это оформить в микропост в блог - может быть и вам пригодится.
Вариант, что кто-то придёт в комменты и натыкает меня носом в то, как это сделать за 5 минут - мне тоже подходит :)
#posts@ergonomic_code #project_e@ergonomic_code
Привет!
Накатал микропост о том как мы руками делали потоковый джоин двух БД для админки в Проекте Э.
Если кто-то на будущее научит меня как это можно было сделать быстрее и проще - буду благодарен:)
#case@ergonomic_code #project_e@ergonomic_code
Накатал микропост о том как мы руками делали потоковый джоин двух БД для админки в Проекте Э.
Если кто-то на будущее научит меня как это можно было сделать быстрее и проще - буду благодарен:)
#case@ergonomic_code #project_e@ergonomic_code
🔥4👍2
Привет!
Как и обещал, пишу о впечатлениях от переезда на Spring Boot 3.1.
Их нет.
Накрутил версию гредлового плагина до 3.1.0, заменил зависимость тестконтейнеров на
Чуть поинтереснее история с интеграцией с композом.
1. Добавил в грэдл
И почти всё. Была одна проблема - в какой-то обвязке кролика vhost захардкожен в "/", а нам в наследство достался нестандартный. Это подправил - и всё взлетело.
Потом ещё небольшая мелочушка была - через спринг нельзя прописать имя композ-проекта - добавил его в композ файл.
И вот это совсем всё. Теперь у нас сетап выглядит так:
1. Поставить Джаву, Идею, Докер, Гит
2. Качнуть репоз
3. Запустить приложение в Идеи
4. Готово
Я хоть и не люблю спринг за его монструозность и автомагичность, но вот такие плюшки прям подкупают.
Плюс у нас есть ещё скриптик (правда только под Linux), который качает дампы из дев кластера и если его запустить между шагами 2 и 3 - будет ещё и сетап на живых данных.
И бонусом ещё немного нашей внутренней кухни - рядом с композом инфраструктуры у нас есть композ, который умеет запускать несколько экземпляров приложения с роутингом через traefik - соответственно потестить работу в многонодовом режиме тоже можно в одну кнопку.
#tools@ergonomic_code #spring@ergonomic_code #devx@ergonomic_code #project_e@ergonomic_code
Как и обещал, пишу о впечатлениях от переезда на Spring Boot 3.1.
Их нет.
Накрутил версию гредлового плагина до 3.1.0, заменил зависимость тестконтейнеров на
testImplementation("org.springframework.boot:spring-boot-testcontainers") и всё. Приложение собралось и запустилось, все тесты прошли. Я это в мастер в следующий цикл вмёржу - может на стендах что-то вылезет.Чуть поинтереснее история с интеграцией с композом.
1. Добавил в грэдл
developmentOnly("org.springframework.boot:spring-boot-docker-compose")
2. Добавил конфиг 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 - соответственно потестить работу в многонодовом режиме тоже можно в одну кнопку.
#tools@ergonomic_code #spring@ergonomic_code #devx@ergonomic_code #project_e@ergonomic_code
Docker
traefik - Official Image | Docker Hub
Traefik, The Cloud Native Edge Router
👍2
Привет!
На денёк задержался, но это потому что у меня были очень интересные приседнания с тестами в эргономичном стиле - может после отпуска расскажу:)
И так, та-да-да, микропост с результатами анализа Jira Проекта Э.
Пост оказался микро только с точки зрения полировки, а по объёму - вполне себе приличный пост, поэтому сразу ТЛДР:
1) Мы действительно стали работать в два раза быстрее и допускать в два раза меньше багов
2) Я получил дополнительное подтверждение вцелом очевидным вещам:
2.1) Первый год разработки на микросервисах дороже разработки на монолите. Минимум на 30%;
2.2) Автоматизация тестирования снижает количество багов и трудозатрат на их устранение. Минимум в два раза;
2.3) Мотивация команды имеет огромное влияние на трудозатарты. От 30% дополнительных трудозатрат в случае низкой мотивации.
#posts@ergonomic_code #case@ergonomic_code #why_ergo_approach@ergonomic_code #project_e@ergonomic_code
На денёк задержался, но это потому что у меня были очень интересные приседнания с тестами в эргономичном стиле - может после отпуска расскажу:)
И так, та-да-да, микропост с результатами анализа Jira Проекта Э.
Пост оказался микро только с точки зрения полировки, а по объёму - вполне себе приличный пост, поэтому сразу ТЛДР:
1) Мы действительно стали работать в два раза быстрее и допускать в два раза меньше багов
2) Я получил дополнительное подтверждение вцелом очевидным вещам:
2.1) Первый год разработки на микросервисах дороже разработки на монолите. Минимум на 30%;
2.2) Автоматизация тестирования снижает количество багов и трудозатрат на их устранение. Минимум в два раза;
2.3) Мотивация команды имеет огромное влияние на трудозатарты. От 30% дополнительных трудозатрат в случае низкой мотивации.
#posts@ergonomic_code #case@ergonomic_code #why_ergo_approach@ergonomic_code #project_e@ergonomic_code
🔥6
Привет!
Сегодня у меня день релизов!:)
Во-первых, я накатал обещанный микропрост про упражнения со Spring Boot Native.
А во-вторых и в главных - опубликовал первый том ретро реинжиниринга Проекта Э!
Ну и заодно немного обновил лендинг ЭП и добавил туда кейс Проекта Э
#case@ergonomic_code #project_e@ergonomic_code #posts@ergonomic_code
Сегодня у меня день релизов!:)
Во-первых, я накатал обещанный микропрост про упражнения со Spring Boot Native.
А во-вторых и в главных - опубликовал первый том ретро реинжиниринга Проекта Э!
Ну и заодно немного обновил лендинг ЭП и добавил туда кейс Проекта Э
#case@ergonomic_code #project_e@ergonomic_code #posts@ergonomic_code
👍6
Привет!
Опубликовал вторую менеджерско-организационную часть ретро Проэкта Э.
С описанием процесса работы, того что пошло не по плану, как факапились и чем всё закончилось
#posts@ergonomic_code #project_e@ergonomic_code
Опубликовал вторую менеджерско-организационную часть ретро Проэкта Э.
С описанием процесса работы, того что пошло не по плану, как факапились и чем всё закончилось
#posts@ergonomic_code #project_e@ergonomic_code
Алексей Жидков
Как я превратил легаси-проект в конфетку за полгода. Том 2 - Алексей Жидков
https://azhidkov.pro/
Привет!
Прочитал Software Architecture: The Hard Parts, более подходящим названием которой было бы "Yet another монолит в микросервисы - практическое пособие для мазохистов по выбору инструментов самоистязания".
Если серьёзно - единственное что мне в этой книге не понравилось - посыл, что микросервисы это стильно модно молодёжно, а монолит это устаревший подход. Я с этим посылом не согласен и придерживаюсь мнения, что в большей половине проектов с врождёнными болячками монолита будет жить проще, чем с врождёнными болячками микросервисов.
В остальном - очень качественный, полноценный и "comprehensive" материал, с обзором вариантов архитектур и адекватным обзором плюсов и минусов.
Так что рекомендую.
Особенно понравилось/зацепило глаз:
1. идея разделения на статическую и динамическую сцепленность. Думаю я себе это утащу в будущий пост про неё.
2. Идея пакетирования домен.поддомен.компонент и требование, чтобы компоненты были только в листах. У меня сейчас всё компоненты, при том допускаются вложенные компоненты и это не всегда работает. Не уверен, что утащу эту идею к себе, но точно подумаю в эту сторону
3. Они там так же как и я предлагаю технику выбора имени компонента, для определения его "разумности". И в целом в части декомпозиции, возможных вариантов решения сложных случаев и советов по выбору среди них - у нас совпадение процентов 80, но в книге материал больше проработан. Думаю, чем-то из книги смогу дополнить свой подход.
4. Понравилась идея семантической сцепленности - сцепленности в самой предметной области. Правда, эта штука ещё более расплывчатая, чем сцепленность в техническом решении.
4.1. Туда же хорошая идея, что техническое решение может только ухудшить (и часто так делает), семантическую сцепленность
4.2. Туда же идея, что при дизайне архитектор может "push back"-ать требования, если они содержать избыточную семантическую сцепленность, в лёгкой форме это у меня было в дизайне интеграции с ЕМИАС, где по изначальным требованиям казалось, что заказчик хочет семантической сцепленности регистрации пользователя в системе и привязке его к ЕМИАС
#books@ergonomic_code #project_e@ergonomic_code
Прочитал Software Architecture: The Hard Parts, более подходящим названием которой было бы "Yet another монолит в микросервисы - практическое пособие для мазохистов по выбору инструментов самоистязания".
Если серьёзно - единственное что мне в этой книге не понравилось - посыл, что микросервисы это стильно модно молодёжно, а монолит это устаревший подход. Я с этим посылом не согласен и придерживаюсь мнения, что в большей половине проектов с врождёнными болячками монолита будет жить проще, чем с врождёнными болячками микросервисов.
В остальном - очень качественный, полноценный и "comprehensive" материал, с обзором вариантов архитектур и адекватным обзором плюсов и минусов.
Так что рекомендую.
Особенно понравилось/зацепило глаз:
1. идея разделения на статическую и динамическую сцепленность. Думаю я себе это утащу в будущий пост про неё.
2. Идея пакетирования домен.поддомен.компонент и требование, чтобы компоненты были только в листах. У меня сейчас всё компоненты, при том допускаются вложенные компоненты и это не всегда работает. Не уверен, что утащу эту идею к себе, но точно подумаю в эту сторону
3. Они там так же как и я предлагаю технику выбора имени компонента, для определения его "разумности". И в целом в части декомпозиции, возможных вариантов решения сложных случаев и советов по выбору среди них - у нас совпадение процентов 80, но в книге материал больше проработан. Думаю, чем-то из книги смогу дополнить свой подход.
4. Понравилась идея семантической сцепленности - сцепленности в самой предметной области. Правда, эта штука ещё более расплывчатая, чем сцепленность в техническом решении.
4.1. Туда же хорошая идея, что техническое решение может только ухудшить (и часто так делает), семантическую сцепленность
4.2. Туда же идея, что при дизайне архитектор может "push back"-ать требования, если они содержать избыточную семантическую сцепленность, в лёгкой форме это у меня было в дизайне интеграции с ЕМИАС, где по изначальным требованиям казалось, что заказчик хочет семантической сцепленности регистрации пользователя в системе и привязке его к ЕМИАС
#books@ergonomic_code #project_e@ergonomic_code
O’Reilly Online Learning
Software Architecture: The Hard Parts
There are no easy decisions in software architecture. Instead, there are many hard parts--difficult problems or issues with no best practices--that force you to choose among various... - Selection from Software Architecture: The Hard Parts [Book]
👍5🔥1
Привет!
Собираю я вчера второй хот фикс на последний кровавый релиз Проекта Э с одной регрессией бэка и двумя костылями для багов в МП, пока шёл пайплайн заглянул на хабр, а там - Релиз без ошибок. Невозможное возможно?.
У мужика процесс намного более стандартизован (бюрократизирован?) и такого я себе пока позволить не могу, но в фокусе на функциональных тестах мы уже сходимся:)
С учётом того, что я заявляю, что ЭП позволяет существенно сократить кол-во багов, а в этом релизе на бэке нашли штук 5-6 багов (справедливости ради - только при тестировании МП и в течении 2-3 недель), то я этот релиз и все баги разберу по косточкам. И постараюсь опубликовать разбор, если удастся сохранить смысл, не нарушая NDA.
#posts@ergonomic_code #project_e@ergonomic_code
Собираю я вчера второй хот фикс на последний кровавый релиз Проекта Э с одной регрессией бэка и двумя костылями для багов в МП, пока шёл пайплайн заглянул на хабр, а там - Релиз без ошибок. Невозможное возможно?.
У мужика процесс намного более стандартизован (бюрократизирован?) и такого я себе пока позволить не могу, но в фокусе на функциональных тестах мы уже сходимся:)
С учётом того, что я заявляю, что ЭП позволяет существенно сократить кол-во багов, а в этом релизе на бэке нашли штук 5-6 багов (справедливости ради - только при тестировании МП и в течении 2-3 недель), то я этот релиз и все баги разберу по косточкам. И постараюсь опубликовать разбор, если удастся сохранить смысл, не нарушая NDA.
#posts@ergonomic_code #project_e@ergonomic_code
👍5
Привет!
Вспомнили свою профессию?:)
Если нет - возможно вам поможет гайдлайн разработки Проекта Э практически без купюр:)
Я его подготовил к публикации ещё в прошлом году, но собственно опубликовать дошли руки только сейчас.
#ergo_approach@ergonomic_code #project_e@ergonomic_code
Вспомнили свою профессию?:)
Если нет - возможно вам поможет гайдлайн разработки Проекта Э практически без купюр:)
Я его подготовил к публикации ещё в прошлом году, но собственно опубликовать дошли руки только сейчас.
#ergo_approach@ergonomic_code #project_e@ergonomic_code
👍6🔥4❤2
Привет!
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.
И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)
В связи с чем у меня пачка новостей.
Книга
Это уже новость второй свежести, но для контекста надо проговорить - я договорился с менеджером проектов издательства Питер начать с апреля плотную работу над книгой про ЭП. Так что надеюсь, на горизонте пары лет книга увидит свет.
Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов
Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.
Это опять же обусловлено опытом Проекта Р - там у меня львиная доля запросов чтения рукописные, потому что SDJ не в состоянии эффективно доставать данные этого проекта, а после того, как мне пришлось ещё и два кастомных метода сохранения написать - стало понятно, что я борюсь с технологией. Этому решению так же поспособствовали пост из канала одного из участников нашей группы.
И решение перейти на UUID-ы, которое так же было обусловлено опытом разработки Проекта Р, где надо сетапать огромные графы объектов в тестах и с генераций ИДов на уровне БД это очень сложно.
Новая версия описания Эргономичной архитектуры
На мой взгляд самая крутая новость - я выложил новый подход к описанию ЭА.
По сути там ничего не изменилось, изменилась только подача.
Но эта новая подача мне настолько нравится, что я решил показать самый первый черновик.
Основная фишка - я отказался от попытки быть как все и уместить архитектуру на одну картинку и ввёл идею проекций. Их три:
1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними
Плюс я туда сразу накидал кучу примеров (пока на словах😕), а так же процессы построения всех этих структур и итоговой архитектуры.
Над единой картинкой я тоже ещё подумаю: кажется, судя по проектам физических изделий, где есть проекции по плоскостям плюс изометрия или проекты зданий, где есть тоже должны быть разные проекции и разные слои (с электропроводкой, например) - для ЭА тоже можно что-то такое сделать.
И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу😄
#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.
И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)
В связи с чем у меня пачка новостей.
Книга
Это уже новость второй свежести, но для контекста надо проговорить - я договорился с менеджером проектов издательства Питер начать с апреля плотную работу над книгой про ЭП. Так что надеюсь, на горизонте пары лет книга увидит свет.
Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов
Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.
Это опять же обусловлено опытом Проекта Р - там у меня львиная доля запросов чтения рукописные, потому что SDJ не в состоянии эффективно доставать данные этого проекта, а после того, как мне пришлось ещё и два кастомных метода сохранения написать - стало понятно, что я борюсь с технологией. Этому решению так же поспособствовали пост из канала одного из участников нашей группы.
И решение перейти на UUID-ы, которое так же было обусловлено опытом разработки Проекта Р, где надо сетапать огромные графы объектов в тестах и с генераций ИДов на уровне БД это очень сложно.
Новая версия описания Эргономичной архитектуры
На мой взгляд самая крутая новость - я выложил новый подход к описанию ЭА.
По сути там ничего не изменилось, изменилась только подача.
Но эта новая подача мне настолько нравится, что я решил показать самый первый черновик.
Основная фишка - я отказался от попытки быть как все и уместить архитектуру на одну картинку и ввёл идею проекций. Их три:
1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними
Плюс я туда сразу накидал кучу примеров (пока на словах😕), а так же процессы построения всех этих структур и итоговой архитектуры.
Над единой картинкой я тоже ещё подумаю: кажется, судя по проектам физических изделий, где есть проекции по плоскостям плюс изометрия или проекты зданий, где есть тоже должны быть разные проекции и разные слои (с электропроводкой, например) - для ЭА тоже можно что-то такое сделать.
И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу
#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥6👍4❤2
Эргономичный код
Привет! С подачи Романа Русакова запоем прочитал The API. Очень крутая книга, рекомендую. Роман - спасибо:) Так же вы, возможно, задаётесь вопросом что это я затих. Вряд ли, конечно, но я всё равно отвечу - лопачу джиру Проект Э:) Чтобы понять стоило ли…
Привет!
Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).
В целом с посылом поста я согласен (кроме мёржа REST-аннотаций в сервисы, хотя сам об этом думал), но там ничего суперкрутого - этот мой пост не про тот пост:)
А про собственную...Глу... человечность, назовём это так:)
В посте по ссылке есть тезис:
Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.
Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r
PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code
Я тут недавно прочитал Overengineering in Onion/Hexagonal Architectures (перевод).
В целом с посылом поста я согласен (кроме мёржа REST-аннотаций в сервисы, хотя сам об этом думал), но там ничего суперкрутого - этот мой пост не про тот пост:)
А про собственную...
В посте по ссылке есть тезис:
To put it another way, it is a design goal of the Application Service to host orchestration logic to allow lower-level components to become less coupled to one another.
—
Другими словами, Application Services предназначены для размещения логики оркестрации, что позволяет компонентам более низкого уровня быть менее связанными друг с другом.
Но я в 22-ом году (на 18-ом году коммерческой практики и примерно 5-ом году знания про Чистую архитектуру, ДДД, оркестрацию и сервисы приложений) всё равно изобрёл объектно-ориентированную декомпозицию. И пошёл делать по ней #project_e. И получил ровно, то, чего позволяют избегать сервисы приложений - высокую связанность между модулями-объектами.
Сколько ещё у меня таких "изобретений" из-за того что "смотрю в книгу, вижу фигу"? Вопрос риторический, конечно. Время покажет, всё что покажет - расскажу как на духу. Сегодня начал писать пост с ретро #project_r
PS>
И в топик "простых" CRUD приложений из комментов ко вчерашнему посту: в Overengineering in Onion/Hexagonal Architectures про них тоже тоже есть:
Like any tool, concentric architectures are not suitable for any software project. If the domain complexity of your problem is fairly low (CRUD-like), or if the challenge of your application is NOT in the complexity of its business rules, then the Onion/Hexagonal/Ports-Adapters/Clean Architecture might not be the best choice, and you might be better off with vertical slicing, anemic model, CQRS, or another type of architecture.
—
Как и любой другой инструмент, концентрическая архитектура подходит не для всех проектов. Если сложность предметной области вашей задачи довольно низкая (CRUDо-подобная) или если сложность вашего приложения заключается не в сложности его бизнес-правил, то архитектура Onion/Hexagonal/Ports-Adapters/Clean может оказаться не лучшим выбором, и вам, возможно, лучше использовать вертикальную архитектуру, анемичную модель, CQRS или другой тип архитектуры.
#posts@ergonomic_code #ergo_arch@ergonomic_code #ergo_approach@ergonomic_code
Victor Rentea
Overengineering in Onion/Hexagonal Architectures
Clean Architecture, Onion Architecture, and Hexagonal Architecture (aka Ports-and-Adapters) have become the norm for backend system design today. Powerful influencers have promoted these architectures without stressing enough that they are (overly)complex…
❤6
Привет!
Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!
Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.
Соответственно, сейчас моя основная задача немного допилить бэк для поддержки нового устройства и подготовить его к росту нагрузки. Плюс в бэклоге накопилась пачка фич, которые тоже надо будет сделать.
И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.
Кроме того, у меня был очень любопытный опыт приёма на поддержку собственного проекта после практически 1.5-летнего перерыва. Там, на самом деле есть прям много чего написать, но, к сожалению, не осилю. Если в целом общие ощущения - нот бэд, но за почти три года с момента начала разработки Проекта Э, Эргономичный подход сделал огромный шаг вперёд, особенно в части тестирования.
Плюс чуть подробнее поделюсь ещё одним инсайтом: идея, что можно в одном модуле попилить проект на вертикальные слайсы в пакетах и покрыть отсутствие циклических зависимостей между ними ArchUnit-тестом, для того чтобы вертикальные кусочки можно было легко вынести - оказалась тупиковой. В моей реализации, по крайней мере.
Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.
Потому что во-вторых - в тестах произошла тотальная катастрофа. Там образовался дикий клубок зависимостей, который я распутывал и распиливал неделю. Наверное, тесты надо покрывать ArchUnit-тестами тоже:)
В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!
Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.
Соответственно, сейчас моя основная задача немного допилить бэк для поддержки нового устройства и подготовить его к росту нагрузки. Плюс в бэклоге накопилась пачка фич, которые тоже надо будет сделать.
И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.
Кроме того, у меня был очень любопытный опыт приёма на поддержку собственного проекта после практически 1.5-летнего перерыва. Там, на самом деле есть прям много чего написать, но, к сожалению, не осилю. Если в целом общие ощущения - нот бэд, но за почти три года с момента начала разработки Проекта Э, Эргономичный подход сделал огромный шаг вперёд, особенно в части тестирования.
Плюс чуть подробнее поделюсь ещё одним инсайтом: идея, что можно в одном модуле попилить проект на вертикальные слайсы в пакетах и покрыть отсутствие циклических зависимостей между ними ArchUnit-тестом, для того чтобы вертикальные кусочки можно было легко вынести - оказалась тупиковой. В моей реализации, по крайней мере.
Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.
Потому что во-вторых - в тестах произошла тотальная катастрофа. Там образовался дикий клубок зависимостей, который я распутывал и распиливал неделю. Наверное, тесты надо покрывать ArchUnit-тестами тоже:)
В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Алексей Жидков
Как я превратил легаси-проект в конфетку за полгода. Том 1 - Алексей Жидков
https://azhidkov.pro/
🔥2
Вы, полагаю, уже устали от этих постов. Но мясного материала пока нет - он весь варится.
А варится у меня следующее:
1. Я в #project_e собираюсь пилить новый небольший сервис на пару ресурсов и там хочу поставить пару экспериментов.
1.1 Во-первых, сделать пару прототипов на Spring MVC + Data JDBC и http4k + jooq и посмотреть какая будет разница по потреблению ресурсов (памяти в первую очередь). Об этом я точно напишу как минимум микропост. А если http4k/jooq уместятся хотя бы в половину памяти Спринга - скорее всего возьму их в прод и тогда там будет много инсайтов о жизни вне Спринга:)
1.2. Там же хочу поставить другой эксперимент - генерировать хттп-клиенты для тестов по Open API спеке. Надеюсь, что это мне даст:
1.2.1 Чистый код контроллеров и АПИ не ограниченные поддерживаемыми возможности генераторов по коду
1.2.2 Спеку отделённую от кода, так что её сможет саппортить аналитик
1.2.3 Гарантию актуальности спеки (за счёт контроля при сборке 100% покрытия кода контроллеров тестами)
1.2.4 Отсутствие кодогенерации кода контроллеров
2. В рамках пиара исследования, я собираюсь написать пару постов
2.1 Действительно ли SOLID повышает поддерживаемость? - по науке проанализировать имеющиеся анкеты на предмет того есть ли статестически достоверная (по ослабленному критерию достоверности) корреляция между применением принципов SOLID и оценкой проекта как поддерживаемого
2.2 Эргономичная архитектура тестов - актуализировать и нормально оформить старый микропост о том, как у меня устроены тесты
В общем, стей тюнед, будет интересно:)
А варится у меня следующее:
1. Я в #project_e собираюсь пилить новый небольший сервис на пару ресурсов и там хочу поставить пару экспериментов.
1.1 Во-первых, сделать пару прототипов на Spring MVC + Data JDBC и http4k + jooq и посмотреть какая будет разница по потреблению ресурсов (памяти в первую очередь). Об этом я точно напишу как минимум микропост. А если http4k/jooq уместятся хотя бы в половину памяти Спринга - скорее всего возьму их в прод и тогда там будет много инсайтов о жизни вне Спринга:)
1.2. Там же хочу поставить другой эксперимент - генерировать хттп-клиенты для тестов по Open API спеке. Надеюсь, что это мне даст:
1.2.1 Чистый код контроллеров и АПИ не ограниченные поддерживаемыми возможности генераторов по коду
1.2.2 Спеку отделённую от кода, так что её сможет саппортить аналитик
1.2.3 Гарантию актуальности спеки (за счёт контроля при сборке 100% покрытия кода контроллеров тестами)
1.2.4 Отсутствие кодогенерации кода контроллеров
2. В рамках пиара исследования, я собираюсь написать пару постов
2.1 Действительно ли SOLID повышает поддерживаемость? - по науке проанализировать имеющиеся анкеты на предмет того есть ли статестически достоверная (по ослабленному критерию достоверности) корреляция между применением принципов SOLID и оценкой проекта как поддерживаемого
2.2 Эргономичная архитектура тестов - актуализировать и нормально оформить старый микропост о том, как у меня устроены тесты
В общем, стей тюнед, будет интересно:)
Алексей Жидков
Тестирование Trainer Advisor: теория - Алексей Жидков
https://azhidkov.pro/
❤6👍4