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

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

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

Привет! В Проекте Э сегодня прибили последние два микросервиса на дев окружении и в пн планируем докатить последние куски до прода. Немного статистики: 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

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

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

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

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

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

Привет! Нашёл ещё один рациональный подход, к декомпозиции. Который, судя по всему, является надмножеством декомпозиции на базе эффектов. У них там тоже граф, но однородный - и операции и ресурсы представленны одинаково, плюс ещё есть понятие артефакта (выводимые данные). А вот связи между ними характеризуются 16-ю аспектами. И вот если им этот граф загрузить - они могу его с помощью тула автоматически нарезать. Только с этим тулом есть две проблемы: 1) он начал гнить 2) сформировать граф, и проставить характеристики связей надо руками:)

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

Привет! Студент прислал еженедельный отчёт:) Я считаю это успех

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

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

Привет! У меня продолжается маниакальная стадия "мне нужен идеальный ОРМ" и я накопал ещё пару любопытных линок. Либа персистентных (в смысле переживающих процесс) коллекций для Kotlin/Java. Она, кажется начинает подгнивать, но может пригодиться в некритичных задачах Вы говорите в ОРМах много магии? А как насчёт МетаОРМа? Наконец, на обе штуки я уже давал ссылки, но и себе и вам напомню, что существуют примеры того, что я считаю идеальной технологией персистанса: MicroStream и Erlang Mnesia

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

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

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

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