Привет!

Когда ещё весной-летом делал первый подход к посту о декомпозиции на базе диаграммы эффектов захомячил крутой пост про связанность и сцепленность.

Сейчас делаю второй подход к посту декомпозиции, откопал его, перечитал, снова впечатлился и на это раз решил поделиться с вами:)

#posts@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

Привет!

Пост про ОО-декомпозицию начинает обретать вменяемый вид - надеюсь в течении пары недель закончить:)

А тем временем, буду радовать вас линкопостами:)
Вот очень крутой конспект/лекция (?) из MIT-а про изменяемость/неизменяемость, с хорошими примерами рисков, которые несёт изменяемость. Если вы по дефолту используете изменяемое состояние - рекомендую прочитать, может быть передумаете:)

А если вы используете неизменяемое состояние и Котлин - то вот небольшая библиотека для упрощения жизни. Сам ещё не пробовал её

#posts@ergonomic_code #whyfp@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

В продолжение темы неизменяемых данных: Почему Java делает так много штук неизменяемым?
ТЛ/ДР - потому что неизменяемые штуки потоко-безопасны и благодаря постоянным улучшениям JVM создание нового объекта зачастую может быть быстрее мутации старого

#posts@ergonomic_code #immutable_domain_model@ergonomic_code #java@ergonomic_code

Привет!

Что-то я прокрастинирую пост о декомпозиции. Самое мясо с декомпозицией написал, а вот полировка буксует - то пойду писать спинофф про эффекты, то доделывать спинофф "почему всё-таки объектно-ориентированная?", то пинать Spring Data Jdbc, то болеть.

Но я его точно допишу.

А пока вот ещё одна любопытная линка - альтернативное массиву предстваление строк.

#posts@ergonomic_code

Привет!

Я молния! опечатка по фрейду

Молния! Я разочаровался в Spring Data JDBC. Вкратце, по трём причинам: отсутствие наследования, отсутствие спецификаций и отсутствие возможности автоматически подтянуть ридонли агрегат по ссылке. Потом, может, подробнее распишу.

Поэтому я снова полез гуглить идеальный орм и откопал любопытную штуку. Он пока у меня особо доверия не вызывает и на мой у него довольно многословное АПИ, но идея прикольная.

#tools@ergonomic_code @spring_data_jdbc@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

У меня продолжается маниакальная стадия "мне нужен идеальный ОРМ" и я накопал ещё пару любопытных линок.

Либа персистентных (в смысле переживающих процесс) коллекций для Kotlin/Java. Она, кажется начинает подгнивать, но может пригодиться в некритичных задачах

Вы говорите в ОРМах много магии? А как насчёт МетаОРМа?

Наконец, на обе штуки я уже давал ссылки, но и себе и вам напомню, что существуют примеры того, что я считаю идеальной технологией персистанса: MicroStream и Erlang Mnesia

#posts@ergonomic_code #tools@ergonomic_code #ergo_persistance@ergonomic_code

Привет!

Накопал любопытный пост, в которой автор переносит виды сцепленности из структурного дизайна, на современную разработку.

Не совсем согласен, но ознакомиться рекомендую.

#posts@ergonomic_code #coupling@ergonomic_code #structured_design@ergonomic_code

Привет!

Чуствую себя тем мальчиком из притчи, который кричал волки.

Сегодня у меня настоящая молния, но я, кажется, обесценил это слово в этом канале.

Меня с докладом про декомпозицию на базе эффектов взяли на JPoint!

Привет!

Последний месяц я занимался разработкой алгоритма декомпозиции на базе эффектов. Я хотел сделать детерминированный алгоритм, который давал бы одни и те же результаты, вне зависимости от того, кто его выполняет. Иииии я это не осилил. В какой-то момент я вообще отчаялся оформить это в виде руководства к действию и собрался ограничиться только критериями оценки декомпозиции.

Однако, попадание в программу JPoint, некоторое упрощение задачи (отказ от полной детерменированности) и ещё одна бессонная ночь и у меня кое-что получилось.

Тематический тизер алгоритма декомпозиции:

fun clusterize(diagram: Diagram) {
    var proceed = true
    while (diagram.hasFreeElements() && proceed) {
        proceed = false
        for (r in diagram.freeResources) {
            val tightlyCoupledOperations = r.operations
                .filter { o -> o.resources.size == 1 ||
                               (o.writtenResources.size == 1 && o.writtenResources[0] == r) ||
                               (o.isReadOnly && God.isPrimaryResource(o, r)) }
            diagram.makeCluster(r, tightlyCoupledOperations)
            proceed = tightlyCoupledOperations.isNotEmpty()
        }

        for (e in diagram.freeElements) {
            val adjaсentClusters = e.elements.map { it.cluster }.toSet()
            if (adjecentClusters.size == 1) {
                diagram.extendCluster( adjacentClusters.first(), e)
                proceed = true
            }
        }

        for (r in diagram.freeResources) {
            val possiblePairs = r.operations.flatMap { it.resources }
            val bestMatch = God.findBestMatch(r, possiblePairs)
            if (bestMatch != null) {
                diagram.aggregate(r, bestMatch)
                proceed = true
            }
        }
    }
    if (diagram.hasFreeElements) {
        diagram.finalyzeClusterization()
    }
    diagram.nameClusters()
    diagram.hideSubmodules()
    diagram.groupModules()
}

Кажется, общий ход алгоритма получилось описать достаточно чётко:) А если учесть то, что сейчас могут нейронные сети, то, кажется, они вполне могут справиться с реализацией функций isPrimaryResource и findBestMatch не как боженька, конечно, но не хуже джуна уж точно.

Т.е. гипотетически, алгоритм объектно-ориентированной декомпозиции действительно можно сделать полностью автоматическим. Подаёшь на вход .drawio файл с диаграммой эффектов и на выход получаешь .drawio файл, с декомпозицией, которую надо просто перепроверить. Ну а генератор скелета проекта по drawio файлу с декомпозицией я прямо сейчас без всяких нейронных сетей за вечерок напишу.

А с учётом того, что нейронные сети уже умеют писать код и моих склонностей к мании величия и нарциссизму, у меня в мечтах диаграмма эффектов уже стала самым распространённым языком программирования 5-ого поколения:) М? Мощно задвинул?:)

Осталась только самая мелочь - забутстрапить систему и нарисовать диаграмму эффектов, по которой GitHub copilot сможет сгенерировать код генерации кода по диаграмме эффектов:)

Привет!

Студент прислал еженедельный отчёт:)

Я считаю это успех

Привет!

По посту с декомпозицией пока особых новостей нет и не будет до JPoint-а, поэтому пока накатал микропост с описанием опыта внедерния тулов статического анализа кода (Detekt, Kover, ArchUnit) в Проект Э.

#posts@ergonomic_code #tools@ergonomic_code #case@ergonomic_code

Привет!

Нашёл ещё один рациональный подход, к декомпозиции. Который, судя по всему, является надмножеством декомпозиции на базе эффектов.

У них там тоже граф, но однородный - и операции и ресурсы представленны одинаково, плюс ещё есть понятие артефакта (выводимые данные). А вот связи между ними характеризуются 16-ю аспектами.

И вот если им этот граф загрузить - они могу его с помощью тула автоматически нарезать.
Только с этим тулом есть две проблемы:
1) он начал гнить
2) сформировать граф, и проставить характеристики связей надо руками:)

#papers@ergonomic_code #design@ergonomic_code

Привет!

Сегодня рубрика и смех и грех.

Диалог со студентом (примерный):
С - а как вы раньше запросы писали?
Я - о_О
С - ну там иерархическая модель, сетевая, всё такое
Я - О_О

Кажется мне пора начать подкрашивать седину 😂

На всякий случай историческая справка - иерархическая и сетевая модели имели наибольшее распространение в 60-70-ых годах прошлого века.

Привет!

Мне выдали именной промокод на скидку 20% на персональные билеты на JPoint: AZhidkov2023JRGpc:)

Приходите, развиртуализируемся:)

Привет!

Мне тут пришла рассылка от CodeFest (конференция в Новосибирске). Говорят места на квартирники остались, зазывают провести квартирник, бесплатные билетики (всем) обещают. Но нужна экспертная группа:) Айда похоливарим?

Мои предложения по темам:
1) Из очевидного - как декомпозировать системы?
2) Ту жэпэа ор нот ту жэпэа?
3) Сеттеры - инкапсуляция или фикция? Или что имел ввиду Алан Кей, когда придумывал ООП?
4) Интеграционные/юнит тесты это скам (нужное подчеркнуть)

Но если мне будет что сказать - готов и к вашей теме подключиться:) Да и к вашей заявке:)

Ну и заодно вести с полей Проекта Э.

На скрине разработчик говорит о последнем кусочке и немножко драматизирует на мой взгляд, но в целом с проектом (именно реинжиниринга) ситуация примерно такая - местами было непросто, но, судя по всему, в этот (10ый) спринт закончим.

Обязательно напишу пост с ретро проекта, и может даже удастся это до JPoint-а осилить

#project_e@ergonomic_code

Привет!

У меня есть уникальное предложение для жителей и гостей города Новосибирск!

Совместно с Сибериан.Про организовали оффлайн митап с тестовым (уже третьим) прогоном моего доклада на JPoint. Если не едете в Москву, то можете посмотреть кусочек JPoint-а практически не сходя с места:)

После прогона, будет небольшая тусовка, где можно обсудить актуальные темы:)

Количество участников ограничено (размером офиса), поэтому регистрация обязательна:)
Приходите, будет интересно:)

Привет!

В Проекте Э сегодня прибили последние два микросервиса на дев окружении и в пн планируем докатить последние куски до прода.

Немного статистики:
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

Привет!

Прошу прощения - я на радостях побежал впереди паравоза и опубликовал не рабочую ссылку.

Если кто-то уже зарегестрировался - повторите регистрацию по новой ссылке, пожалуйста. Или, как вариант, просто под этим постом оставьте любой комментарий

Так, ну большинство вроде за, поэтому начну:)
Кто против - мьютьтесь, но не отписывайтесь, это всего на пару дней:)