И к слову, про реальную обратную связь. И про то, что мне не дают покоя лавры анкл Боба:)
Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.
Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)
#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code
Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.
Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)
#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code
❤7
Привет!
Вести с исследовательских полей:)
Заканчиваем полировку вопросов, закинул на ревью дипсику, в рассуждениях он пишет:
А ответ начинается с
Вести с исследовательских полей:)
Заканчиваем полировку вопросов, закинул на ревью дипсику, в рассуждениях он пишет:
Ого, это же целое исследование по поддерживаемости бэкенд-кода! Пользователь явно участвует в серьезном академическом или отраслевом проекте. Видно, что команда хочет собрать максимально объективные данные, а не опираться на субъективные мнения.
...
Пользователь явно вложил много труда в этот опросник. Чувствуется системный подход и желание докопаться до истины. Главное, чтобы респонденты хватили терпения заполнить всё до конца. Хорошо, что обещают опубликовать сырые данные - это повысит доверие к исследованию.
А ответ начинается с
Это комплексный и хорошо структурированный опросник для исследования поддерживаемости бэкенд-кода!
❤4
Привет!
Я из лесу вышел - а тут такоооое!
Если вы как и я посматриваете на VS Code из-за тормозов или проблем с подпиской в IDEA, но вас среди прочего останавливало отсутствие DB Client-а, то вам может быть интересно, что MS недавно выпустили официальный плагин для PostgreSQL. Пока в превью.
#ide@ergonomic_code #tools@ergonomic_code
Я из лесу вышел - а тут такоооое!
Если вы как и я посматриваете на VS Code из-за тормозов или проблем с подпиской в IDEA, но вас среди прочего останавливало отсутствие DB Client-а, то вам может быть интересно, что MS недавно выпустили официальный плагин для PostgreSQL. Пока в превью.
#ide@ergonomic_code #tools@ergonomic_code
Visualstudio
PostgreSQL - Visual Studio Marketplace
Extension for Visual Studio Code - Develop PostgreSQL applications everywhere.
🔥8👍5
Привет!
Свершилось!🎉🎉🎉
Наша исследовательская группа — я, @goloshchapov и @VektorAB — закончила разработку анкеты и приглашает вас поучаствовать в опросе!
Напомню кратко цель исследования: выяснить, как делать проекты так, чтобы последователи сочли их поддерживаемыми.
Для этого мы планируем найти черты, которые часто встречаются у поддерживаемых проектов и редко встречаются у неподдерживаемых.
Как гипотетический пример: в 60% поддерживаемых проектов применялся DDD и в то же время он применялся только в 20% неподдерживаемых проектов. Из чего можно будет сделать вывод, что применение DDD повышает вероятность высокой оценки поддерживаемости вашего кода последователями.
Или гипотетический пример несущественной характеристики: и в поддерживаемых, и в неподдерживаемых проектах микросервисы и монолиты использовались в 50% случаев. Из этого можно сделать вывод, что архитектура системы не влияет на восприятие поддерживаемости вашего кода последователями и при выборе архитектуры можно не учитывать аспект поддерживаемости.
Что считаем важным подчеркнуть: мы не пытаемся найти объективные признаки поддерживаемости кода. В первую очередь потому что непонятно, как саму поддерживаемость объективно оценивать. Поэтому мы пытаемся найти признаки кода, которые коррелируют с субъективной оценкой этого кода как поддерживаемого среднестатистическим разработчиком. В предположении, что между субъективным восприятием и объективной поддерживаемостью есть корреляция.
Поэтому нам крайне важно собрать как можно больше исходных данных, чтобы выводы были статистически обоснованы и наш «среднестатистический разработчик» был репрезентативен. Соответственно, нам крайне важно, чтобы вы сами заполнили анкету, а также рассказали о ней всем своим знакомым разработчикам-бэкендерам.
Так же выражаем благодарность нашим восьми бета-тестерам (пожелавшим остаться анонимными), которые помогли существенно улучшить анкету и найти и исправить пропущенные запятые, непонятные формулировки и забытые важные вопросы:)
Дальнейший план исследования:
1. Примерно до 17 августа заниматься пиаром анкеты - ходить по знакомым блогерам с просьбой дать ссылку и написать небольшой пост на Хабр
2. В течение месяца после окончания пиар активностей собираем данные
3. Примерно 17 сентября закрываем анкету
4. Анализируем данные и пишем отчёт. На это, думаю, уйдёт 1-3 месяца
5. Публикуем сырые данные и наш отчёт
Потратьте 20 минут на благо всего сообщества разработчиков - заполните анкету сейчас:)
Свершилось!🎉🎉🎉
Наша исследовательская группа — я, @goloshchapov и @VektorAB — закончила разработку анкеты и приглашает вас поучаствовать в опросе!
Напомню кратко цель исследования: выяснить, как делать проекты так, чтобы последователи сочли их поддерживаемыми.
Для этого мы планируем найти черты, которые часто встречаются у поддерживаемых проектов и редко встречаются у неподдерживаемых.
Как гипотетический пример: в 60% поддерживаемых проектов применялся DDD и в то же время он применялся только в 20% неподдерживаемых проектов. Из чего можно будет сделать вывод, что применение DDD повышает вероятность высокой оценки поддерживаемости вашего кода последователями.
Или гипотетический пример несущественной характеристики: и в поддерживаемых, и в неподдерживаемых проектах микросервисы и монолиты использовались в 50% случаев. Из этого можно сделать вывод, что архитектура системы не влияет на восприятие поддерживаемости вашего кода последователями и при выборе архитектуры можно не учитывать аспект поддерживаемости.
Что считаем важным подчеркнуть: мы не пытаемся найти объективные признаки поддерживаемости кода. В первую очередь потому что непонятно, как саму поддерживаемость объективно оценивать. Поэтому мы пытаемся найти признаки кода, которые коррелируют с субъективной оценкой этого кода как поддерживаемого среднестатистическим разработчиком. В предположении, что между субъективным восприятием и объективной поддерживаемостью есть корреляция.
Поэтому нам крайне важно собрать как можно больше исходных данных, чтобы выводы были статистически обоснованы и наш «среднестатистический разработчик» был репрезентативен. Соответственно, нам крайне важно, чтобы вы сами заполнили анкету, а также рассказали о ней всем своим знакомым разработчикам-бэкендерам.
Так же выражаем благодарность нашим восьми бета-тестерам (пожелавшим остаться анонимными), которые помогли существенно улучшить анкету и найти и исправить пропущенные запятые, непонятные формулировки и забытые важные вопросы:)
Дальнейший план исследования:
1. Примерно до 17 августа заниматься пиаром анкеты - ходить по знакомым блогерам с просьбой дать ссылку и написать небольшой пост на Хабр
2. В течение месяца после окончания пиар активностей собираем данные
3. Примерно 17 сентября закрываем анкету
4. Анализируем данные и пишем отчёт. На это, думаю, уйдёт 1-3 месяца
5. Публикуем сырые данные и наш отчёт
Потратьте 20 минут на благо всего сообщества разработчиков - заполните анкету сейчас:)
🔥13👍2
Эргономичный код pinned «Привет! Свершилось!🎉🎉🎉 Наша исследовательская группа — я, @goloshchapov и @VektorAB — закончила разработку анкеты и приглашает вас поучаствовать в опросе! Напомню кратко цель исследования: выяснить, как делать проекты так, чтобы последователи сочли их …»
Привет!
У нас в группе за последнюю пару недель было сразу два холивара на тему разделения на слой приложения и домена в DDD. Я смотрел на них и про себя думал, что это очень попахивает искусственной/побочной сложностью.
В ЭП тоже есть очень похожее разделение и даже с теми же названиями, потому что выросло оно у меня из ДДД. Но у меня оно сейчас если не проще, то чётче, на мой взгляд.
В слое домена у меня живёт состояние - классы сущностей/агрегатов и репозитории*.
В слое приложения живут операции системы - в первую очередь порты/точки входа - хттп эндпоинты, обработчики крон-задач, слушатели всевозможных событий и сообщений.
Если операция системы простая - меняет только один ресурс - то она реализуется прямо в порте. В идеале - единственным вызовом репозитория, но см. правила ниже.
Если же операции надо потрогать два или более репозитория, то она оформляется в отдельный класс операции с единственным публичным методом, который помещается в слой приложения и может звать уже сколько угодно репозиториев. Но тоже см. правила ниже.
И для выбора места размещения кода у меня есть два подхода на выбор разработчика.
1. снизу вверх. Код помещается на максимально низкий уровень, где доступно требуемое состояние. Трансоформация/вычисление на базе одной сущности помещается рядом с ней. Код, меняющий только один репоз помещается рядом с этим репозом. Код трансформирующий/вычисляющий на базе нескольких агрегатов/сущностей помещается в слой приложения рядом с операцией, которая его использует или в общий код пакета, содержащего все операции, которые его используют. Код работающий с несколькими ресурсами помещается аналогично максимально близко к операции(ям), его использующим
2. сверху вниз. Код помещается на самый высокий уровень, доступный всем его клиентам. Этот подход, на самом деле имеет смысл только для трансформаций сущностей и тут по большому счёту только два варианта. Трансформация одной сущности, которая используется только в одной операции помещается рядом с ней. Если он нужен нескольким операциям - помещается рядом с сущностью.
Я обычно придерживаюсь подхода снизу вверх, вынося трансформации выше если:
1. она явно относится к одной конкретной операции
2. вокруг сущности накопилось более 10 методов, многие из которых используются только в одной операции
Кроме того у меня есть пачка защитных-правил, которые предотвращают превращение реализации в кровавое месиво бизнес-логики и ввода-вывода и разных уровней абстракции:
1. каждая технология должна быть инкапсулирована либо в порте, либо в ресурсе. При том в случае ресурса инкапсуляция означает, что технология не фонит в API ресурса. В АПИ репозитория не должны упоминаться таблицы, колонки, внешние ключи и т.п. В АПИ хттп клиента внешней системы не должны упоминаться хттп методы, заголовки, куки, мультипарты и т.д.
2. Ни порты, ни операции, ни репозитории** не могут вызывать друг друга
3. метод порта не может вызывать более одной операции или метода ресурса
4. метод порта может содержать только одну конструкцию ветвления (if/when/switch) для выбора представления ответа
5. метод, который прямо или косвенно содержит ввод-вывод (методы портов, операций и репозиториев) может иметь когнитивную сложность не более 4
6. классы поведения (операции, ресурсы) должны иметь не более 7, край 10 зависимостей. А в идеале - до 5
В общем, мне кажется, хороший подход/гайдлайн/методика разработки должен минимизировать поле для холиваров и разночтений. А для этого он должен быть определён в максимально чётко сформулированных правилах, проверку которых, в идале, можно автоматизировать.
Подробнее об этом у меня написано в заготовке статьи Эргономичная архитектура
#ergo_approach@ergonomic_code #ddd@ergonomic_code
У нас в группе за последнюю пару недель было сразу два холивара на тему разделения на слой приложения и домена в DDD. Я смотрел на них и про себя думал, что это очень попахивает искусственной/побочной сложностью.
В ЭП тоже есть очень похожее разделение и даже с теми же названиями, потому что выросло оно у меня из ДДД. Но у меня оно сейчас если не проще, то чётче, на мой взгляд.
В слое домена у меня живёт состояние - классы сущностей/агрегатов и репозитории*.
В слое приложения живут операции системы - в первую очередь порты/точки входа - хттп эндпоинты, обработчики крон-задач, слушатели всевозможных событий и сообщений.
Если операция системы простая - меняет только один ресурс - то она реализуется прямо в порте. В идеале - единственным вызовом репозитория, но см. правила ниже.
Если же операции надо потрогать два или более репозитория, то она оформляется в отдельный класс операции с единственным публичным методом, который помещается в слой приложения и может звать уже сколько угодно репозиториев. Но тоже см. правила ниже.
И для выбора места размещения кода у меня есть два подхода на выбор разработчика.
1. снизу вверх. Код помещается на максимально низкий уровень, где доступно требуемое состояние. Трансоформация/вычисление на базе одной сущности помещается рядом с ней. Код, меняющий только один репоз помещается рядом с этим репозом. Код трансформирующий/вычисляющий на базе нескольких агрегатов/сущностей помещается в слой приложения рядом с операцией, которая его использует или в общий код пакета, содержащего все операции, которые его используют. Код работающий с несколькими ресурсами помещается аналогично максимально близко к операции(ям), его использующим
2. сверху вниз. Код помещается на самый высокий уровень, доступный всем его клиентам. Этот подход, на самом деле имеет смысл только для трансформаций сущностей и тут по большому счёту только два варианта. Трансформация одной сущности, которая используется только в одной операции помещается рядом с ней. Если он нужен нескольким операциям - помещается рядом с сущностью.
Я обычно придерживаюсь подхода снизу вверх, вынося трансформации выше если:
1. она явно относится к одной конкретной операции
2. вокруг сущности накопилось более 10 методов, многие из которых используются только в одной операции
Кроме того у меня есть пачка защитных-правил, которые предотвращают превращение реализации в кровавое месиво бизнес-логики и ввода-вывода и разных уровней абстракции:
1. каждая технология должна быть инкапсулирована либо в порте, либо в ресурсе. При том в случае ресурса инкапсуляция означает, что технология не фонит в API ресурса. В АПИ репозитория не должны упоминаться таблицы, колонки, внешние ключи и т.п. В АПИ хттп клиента внешней системы не должны упоминаться хттп методы, заголовки, куки, мультипарты и т.д.
2. Ни порты, ни операции, ни репозитории** не могут вызывать друг друга
3. метод порта не может вызывать более одной операции или метода ресурса
4. метод порта может содержать только одну конструкцию ветвления (if/when/switch) для выбора представления ответа
5. метод, который прямо или косвенно содержит ввод-вывод (методы портов, операций и репозиториев) может иметь когнитивную сложность не более 4
6. классы поведения (операции, ресурсы) должны иметь не более 7, край 10 зависимостей. А в идеале - до 5
В общем, мне кажется, хороший подход/гайдлайн/методика разработки должен минимизировать поле для холиваров и разночтений. А для этого он должен быть определён в максимально чётко сформулированных правилах, проверку которых, в идале, можно автоматизировать.
Подробнее об этом у меня написано в заготовке статьи Эргономичная архитектура
#ergo_approach@ergonomic_code #ddd@ergonomic_code
Telegram
Эргономичный код - группа
Помогаем друг другу применять на практике основные идеи Эргономичного подхода - модульные монолиты, неизменяемую модель данных, функциональную архитектуру, интеграционные тесты, outside in TTD, data-oriented programming.
Канал: https://t.me/ergonomic_code
Канал: https://t.me/ergonomic_code
❤5👍3
* - на самом деле не только репозитории, но и любые штуки с состоянием - клиенты внешних АПИ, очереди сообщений, мапы в памяти, сервисы отправки почты и сообщений в телеграм и т.д.
** - в случае если какую-то пару репозиториев надо позвать в нескольких операциях и этому действию можно дать вменяемое имя, оно оформляется в доменную операцию - класс, экземпляры которого создаются руками в классах операциях, а не ДИ-контейнером/composition root-ом.
Так же есть сложные ресурсы, инкапсулирующие нескольких простых. Например, если клиенту внешнего АПИ надо кэшировать в БД системы токен авторизации, то это реализуется тремя классами - верхнеуровневым ресурсом, ресурсом-клиентом внешнего АПИ и ресурсом-дао/репозом токенов. В это случае верхнеуровневый ресурс (и только он) может вызывать вложенные ресурсы.
** - в случае если какую-то пару репозиториев надо позвать в нескольких операциях и этому действию можно дать вменяемое имя, оно оформляется в доменную операцию - класс, экземпляры которого создаются руками в классах операциях, а не ДИ-контейнером/composition root-ом.
Так же есть сложные ресурсы, инкапсулирующие нескольких простых. Например, если клиенту внешнего АПИ надо кэшировать в БД системы токен авторизации, то это реализуется тремя классами - верхнеуровневым ресурсом, ресурсом-клиентом внешнего АПИ и ресурсом-дао/репозом токенов. В это случае верхнеуровневый ресурс (и только он) может вызывать вложенные ресурсы.
👍2
И ещё мысль в догонку. Такое ощущение, что у меня сейчас на Спринге небизнес-логики практически нет. Бывает, что надо из запроса с мультипартом надо собрать команду для бизнес-логики. Или что надо сделать какую-то хитрую координацию и обработку ошибок при работе с внешней системой. Но в моих проектах такого кода прям максимум процентов 10 наберётся
👍3
Forwarded from blzr
Инженерное совершенство
и детальный анализ
#инженерия
и детальный анализ
My father-in-law is a builder. It is difficult to get his attention in a magnificent space because he is lost in wonder. We were in a cathedral together years ago and I asked him what it would cost to build it today. I will never forget his answer… 'We can’t, we don’t know how to do it.'
how come a company founded over 100 years ago has the fastest site on the internet?
After a quick look:
· Agressive pre-loading pages on hover
· fixed image dimensions - there is no layout shift when they load
· Dependency Injection - only loading the JS needed on the pages where its needed
· Uses pushstate to change pages so it feels faster than a full reload
· agressive CDN and browser caching
· Server rendered HTML (ASP.net)
Funny enough they load almost a meg of JS (YUI and jQuery) but you dont notice because it feels so snappy
#инженерия
👍5❤3🔥2
Привет!
Представляю вам первого партёнра нашего исследования - канал Саши Раковского.
Саша и в бета-тесте поучаствовал, и рассказал об исследовании своим подписчикам по собственной инициативе.
А ещё у него в канале много крутых постов, например как ниже.
Ну и пользуясь случаем ещё раз призываю вас заполнить анкету - пока что у нас только 25 анкет, надо хотя бы до 50 дотянуть
Представляю вам первого партёнра нашего исследования - канал Саши Раковского.
Саша и в бета-тесте поучаствовал, и рассказал об исследовании своим подписчикам по собственной инициативе.
А ещё у него в канале много крутых постов, например как ниже.
Ну и пользуясь случаем ещё раз призываю вас заполнить анкету - пока что у нас только 25 анкет, надо хотя бы до 50 дотянуть
Telegram
Саша Раковский
Мой маленький канал про экстремальное программирование и разработку программного обеспечения.
❤2
Forwarded from Саша Раковский
Про лапки 🥰
В статье по дизайну я упомянул design stamina hypothesis. Гипотезу, что у хорошего дизайна кривая стоимости изменений гораздо более плоская, чем у плохого. Простым языком: если код - говно, то менять его тупо дороже, простите меня за мой французский.
Так вот, проблема этой идеи в том, что это гипотеза. Почему? Потому что мы не можем ее проверить - не умеем измерять скорость разработки.
Или всё-таки умеем?
Написать какой-нибудь майнкрафт в одиночку за неделю - это точно быстро. Поэтому сказать, что мы совсем не умеем оценивать, нельзя. Проблема в том, что мы просто делаем это очень плохо.
Не хочу долго мусолить методы сравнения, но из уважения к читателям укажу основные метрики, которые мы знаем:
- строчки кода
- сторипоинты
- тест-кейсы
- количество фич
- соотношение новой работы и остальной работы
- business value
- dora-метрики
- интуиция.
В частных случаях они все могут быть даже полезными, и это тема для отдельного поста, но в общем случае их нельзя использовать для измерения скорости команд.
Дурацкая импотенция
Вот эта вот скорость - это далеко не единственная штука, с которой у нас есть проблемы. Мы отвратительно оцениваем объём работ, плохо прикидываем business value той или иной фичи, ужасно справляемся с big upfront design, простите мне этот англицизм. И, если кто-то утверждает, что он все это умеет, то он или гений, или заблуждается, или просто врёт.
Про целеполагание
И во всей этой импотенции обязательно надо понимать: цель измерений-то какая?
Вот у вас есть быстрая команда, которая фигачит в два раза быстрее остальных. А толку, если она фигачит не туда? Это прям такая классика, когда 2/3 разработанных фич пользователями либо используются крайне редко, либо не используются вообще. Есть даже название такому софту: bloatware.
То же самое касается и оценки объёма работ. Вот вам дали ТЗ. Допустим, сами пользователи дали. Вы оценили: через год будет готово. Ну вот даже если вы прям угадали, и через год все готово. Вот даже если у вас супер быстрая команда, которая сделала это в 2 раза дешевле остальных. Ну вы все равно упираетесь в тот факт, что даже сами пользователи не знают, что им реально надо. И через год у них за пол стоимости есть функционал, 2/3 из которого можно было не делать.
Дежурный пинок водопада
Водопад, на самом деле, плохо работает не только и не столько потому, что мы не очень оцениваем на дальнюю перспективу, сильно ошибаемся при предварительном проектировании больших систем и откладываем все самые неприятные неожиданности на фазу тестирования. Все это, конечно же, в разы увеличивает расходы и ломает экономику большой доли проектов, которые отменяют спустя месяцы и годы разработки.
Но вот значительную часть оставшихся проектов, где выгода во много раз должна была бы превысить затраты, добивала ситуация, когда спустя десятки недель разработки пользователи получали совсем не то, что надо. Может быть, именно то, что они просили, но точно не то, что им было нужно.
К чему я это все?
Да к тому, что без качественной работы над скоупом все эти спекуляции про продуктивность, тесты, ДДД, рефакторинг, чистый код и т.п. - это все разговоры не туда, имитация бурной деятельности.
Для большинства команд самый быстрый способ ускориться в несколько раз - это перестать делать лишнюю работу. Необходимость работы над чем-то всегда нужно доказывать.
Куда копать дальше?
Три года назад, когда моя голова была забита всей этой экстремалкой, CD и прочим аджайлом, вот этот доклад для меня перевернул все. Gojko Adzic - самый главный амбассадор борьбы с работой не туда, поэтому рекомендую ознакомиться с его работами.
Эти же идеи транслирует и Эрик Райс в своём Lean Startup. У него есть одноимённая книга, но для быстрого ознакомления рекомендую вот этот доклад.
Ну и из всей горы экспертов, советов и методологий наиболее положительно, конечно, выделяется DORA со своими Accelerate и State of Devops. Эти просто померили, что влияет на успехи компании и предикторы этих успехов, а что - нет. Никаких вам умозрительных пальцесосаний, сухая конкретика.
В статье по дизайну я упомянул design stamina hypothesis. Гипотезу, что у хорошего дизайна кривая стоимости изменений гораздо более плоская, чем у плохого. Простым языком: если код - говно, то менять его тупо дороже, простите меня за мой французский.
Так вот, проблема этой идеи в том, что это гипотеза. Почему? Потому что мы не можем ее проверить - не умеем измерять скорость разработки.
Или всё-таки умеем?
Написать какой-нибудь майнкрафт в одиночку за неделю - это точно быстро. Поэтому сказать, что мы совсем не умеем оценивать, нельзя. Проблема в том, что мы просто делаем это очень плохо.
Не хочу долго мусолить методы сравнения, но из уважения к читателям укажу основные метрики, которые мы знаем:
- строчки кода
- сторипоинты
- тест-кейсы
- количество фич
- соотношение новой работы и остальной работы
- business value
- dora-метрики
- интуиция.
В частных случаях они все могут быть даже полезными, и это тема для отдельного поста, но в общем случае их нельзя использовать для измерения скорости команд.
Дурацкая импотенция
Вот эта вот скорость - это далеко не единственная штука, с которой у нас есть проблемы. Мы отвратительно оцениваем объём работ, плохо прикидываем business value той или иной фичи, ужасно справляемся с big upfront design, простите мне этот англицизм. И, если кто-то утверждает, что он все это умеет, то он или гений, или заблуждается, или просто врёт.
Про целеполагание
И во всей этой импотенции обязательно надо понимать: цель измерений-то какая?
Вот у вас есть быстрая команда, которая фигачит в два раза быстрее остальных. А толку, если она фигачит не туда? Это прям такая классика, когда 2/3 разработанных фич пользователями либо используются крайне редко, либо не используются вообще. Есть даже название такому софту: bloatware.
То же самое касается и оценки объёма работ. Вот вам дали ТЗ. Допустим, сами пользователи дали. Вы оценили: через год будет готово. Ну вот даже если вы прям угадали, и через год все готово. Вот даже если у вас супер быстрая команда, которая сделала это в 2 раза дешевле остальных. Ну вы все равно упираетесь в тот факт, что даже сами пользователи не знают, что им реально надо. И через год у них за пол стоимости есть функционал, 2/3 из которого можно было не делать.
Дежурный пинок водопада
Водопад, на самом деле, плохо работает не только и не столько потому, что мы не очень оцениваем на дальнюю перспективу, сильно ошибаемся при предварительном проектировании больших систем и откладываем все самые неприятные неожиданности на фазу тестирования. Все это, конечно же, в разы увеличивает расходы и ломает экономику большой доли проектов, которые отменяют спустя месяцы и годы разработки.
Но вот значительную часть оставшихся проектов, где выгода во много раз должна была бы превысить затраты, добивала ситуация, когда спустя десятки недель разработки пользователи получали совсем не то, что надо. Может быть, именно то, что они просили, но точно не то, что им было нужно.
К чему я это все?
Да к тому, что без качественной работы над скоупом все эти спекуляции про продуктивность, тесты, ДДД, рефакторинг, чистый код и т.п. - это все разговоры не туда, имитация бурной деятельности.
Для большинства команд самый быстрый способ ускориться в несколько раз - это перестать делать лишнюю работу. Необходимость работы над чем-то всегда нужно доказывать.
Куда копать дальше?
Три года назад, когда моя голова была забита всей этой экстремалкой, CD и прочим аджайлом, вот этот доклад для меня перевернул все. Gojko Adzic - самый главный амбассадор борьбы с работой не туда, поэтому рекомендую ознакомиться с его работами.
Эти же идеи транслирует и Эрик Райс в своём Lean Startup. У него есть одноимённая книга, но для быстрого ознакомления рекомендую вот этот доклад.
Ну и из всей горы экспертов, советов и методологий наиболее положительно, конечно, выделяется DORA со своими Accelerate и State of Devops. Эти просто померили, что влияет на успехи компании и предикторы этих успехов, а что - нет. Никаких вам умозрительных пальцесосаний, сухая конкретика.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2
Саша Раковский
Про лапки 🥰 В статье по дизайну я упомянул design stamina hypothesis. Гипотезу, что у хорошего дизайна кривая стоимости изменений гораздо более плоская, чем у плохого. Простым языком: если код - говно, то менять его тупо дороже, простите меня за мой французский.…
Я любую нетривиальную фичу начинаю с написания "заметок по реализации" - неформального проектного решения.
И там первым разделом идёт "Что вообще происходит", в котором заполняется как обстоят дела сейчас, кого и чем это не устраивает, желаемое состояние дел и критерии оценки успеха проекта.
И очень часто даже у бизнеса нет убедительных ответов на эти вопросы, особенно на последний.
Но тем не менее, поиск ответов на эти вопросы я считаю очень полезным упражнением, которое команде стоит проделывать перед тем как тратить на какую-то фичу время.
И там первым разделом идёт "Что вообще происходит", в котором заполняется как обстоят дела сейчас, кого и чем это не устраивает, желаемое состояние дел и критерии оценки успеха проекта.
И очень часто даже у бизнеса нет убедительных ответов на эти вопросы, особенно на последний.
Но тем не менее, поиск ответов на эти вопросы я считаю очень полезным упражнением, которое команде стоит проделывать перед тем как тратить на какую-то фичу время.
👍5💯3
Привет!
С радостью представляю вам второго партнёра нашего исследования - Александр Кучук (Телеграм канал и Твиттер).
Ну и пользуясь случаем снова призываю вас заполнить анкету - пока что у нас только 26 анкет, надо хотя бы до 50 дотянуть
С радостью представляю вам второго партнёра нашего исследования - Александр Кучук (Телеграм канал и Твиттер).
Ну и пользуясь случаем снова призываю вас заполнить анкету - пока что у нас только 26 анкет, надо хотя бы до 50 дотянуть
Telegram
Блог Кучука
Простые мысли простого человека
❤3
Привет!
Представляю вам ещё одного партнёра нашего исследования - Александр Гранин.
Сашина поддержка для меня особенно ценна, так как он не просто уже написал две книги схожих по тематике и масштабу, той, которую пишу я - Functional Design and Architecture: Examples in Haskell и Проектирование на уровне типов. Системный взгляд на дизайн и архитектуру, но ещё и издал первую из них в Manning-е - одном из самых крутых издательств в сфере ИТ в мире.
Представляю вам ещё одного партнёра нашего исследования - Александр Гранин.
Сашина поддержка для меня особенно ценна, так как он не просто уже написал две книги схожих по тематике и масштабу, той, которую пишу я - Functional Design and Architecture: Examples in Haskell и Проектирование на уровне типов. Системный взгляд на дизайн и архитектуру, но ещё и издал первую из них в Manning-е - одном из самых крутых издательств в сфере ИТ в мире.
Inside a Black Hole
Lambda calculus meets creativity
🔥9
Привет!
Представляю вам ещё одного партнёра нашего исследования - канал 🦾 IT-Качалка Давида Шекунца 💪.
Давид, помимо рассказа о нашем исследовании, ещё и поучаствовал в бета-тесте анкеты, помог нам взглянуть на неё глазами Go/TypeScript-иста и существенно скорректировать наш перекос в Java.
Ну и пользуясь случаем ещё раз призываю вас заполнить анкету - до 50-ти мы уже дотянули, на данных всё ещё не хватает для того, чтобы делать статистически достоверные выводы.
Представляю вам ещё одного партнёра нашего исследования - канал 🦾 IT-Качалка Давида Шекунца 💪.
Давид, помимо рассказа о нашем исследовании, ещё и поучаствовал в бета-тесте анкеты, помог нам взглянуть на неё глазами Go/TypeScript-иста и существенно скорректировать наш перекос в Java.
Ну и пользуясь случаем ещё раз призываю вас заполнить анкету - до 50-ти мы уже дотянули, на данных всё ещё не хватает для того, чтобы делать статистически достоверные выводы.
Telegram
🦾 IT-Качалка Давида Шекунца 💪
Проектируем и разрабатываем HighLoad решения
С 🖤 от @davids_shek
С 🖤 от @davids_shek
Вы, полагаю, уже устали от этих постов. Но мясного материала пока нет - он весь варится.
А варится у меня следующее:
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
Привет!
Молния!⚡️ ⚡️ ⚡️
В Postgres 18 готовят поддержку property graph query language! А в Oracle 23 она уже есть.
Пример
Источник примера
И дев-сборку можно уже руками потрогать.
Кажется, это наконец-то решит проблему выборки иерархичных данных (aka json-ов) из реляционных СУБД.
Молния!
В Postgres 18 готовят поддержку property graph query language! А в Oracle 23 она уже есть.
Пример
SELECT DISTINCT id, fof_parents, details
FROM GRAPH_TABLE(
characters
MATCH (a IS node WHERE a.name='Samwise Gamgee')-[x IS relationship WHERE x.type='friend']->
(b IS node)-[y IS relationship WHERE y.type='friend']->
(c IS node)<-[z IS relationship WHERE z.type='parent']-
(d IS node)
COLUMNS (d.id, d.name as fof_parents, d.details as details)
);
id | fof_parents | details
----+----------------+-----------------------
2 | Bilbo Baggins | {"species": "Hobbit"}
4 | Hamfast Gamgee | {"species": "Hobbit"}
7 | Arathorn | {"species": "Human"}
9 | Thranduil | {"species": "Elf"}
11 | Gloin | {"species": "Dwarf"}
Источник примера
И дев-сборку можно уже руками потрогать.
Кажется, это наконец-то решит проблему выборки иерархичных данных (aka json-ов) из реляционных СУБД.
Please open Telegram to view this post
VIEW IN TELEGRAM
Gavin Ray Blog
Experimenting with SQL:2023 Property-Graph Queries in Postgres 18
Hands-on guide to the upcoming SQL/PGQ graph syntax using a patched Postgres 18 beta.
👍4🔥4