Свежая пресса, господа!
Только что вышел Technology Radar.

Меня лично в этом выпуске зацепил фокус на том, как команды перестраиваются на удаленную работу.
Trial: Remote mob programming. Говорите что pair programming - слишком затратное дело? Thoughtworks пробует подход, когда вся команда собравшись удалённо работает над сложной задачей

Trial: Single team remote wall. Привыкли к том у что все стены в вашем офисе изрисованы схемами и увешаны стикерами? Ничего не мешает сделать виртуальную стену!

Adopt: Zero trust architecture. Когда я начинаю проект всегда встает вопрос как организовать security внутри кластера. Должны ли мы доверять вызовам, только потому что они ходят внутри защищенного периметра или все таки нет?. Zero trust architecture говорит что доверять мы не должны никому, И защищенный периметр - не лучший вариант

Adopt: 4 key metrics. На самом деле я удивлен, что они только сейчас вошли в adopt. Если вы еще не смотрели на них, то очень советую. Они про то, как померить эффективность доставки software, или при более широкой трактовке как померить эффективность работы команды

И многое другое….

https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2021/10/tr_technology_radar_vol_25_en.pdf

Графики к посту о статистике

Статистика и вероятностные методы в разработке

В сентябре на Хабре вышел перевод статьи Сони Сайдеровой о вероятностных прогнозах. Хабро-эксперты по всему на свете обошли её стороной и не закидали какахами, а зря: тема интересная и перспективная.

Статистику применяют для прогнозирования и оценки проектов, а ещё с её помощью можно отслеживать проблемы. Например, предсказывать сбои на проекте до начала пожара и вовремя замечать признаки выгорания у разработчиков. Максимально упрощенно работает так:

Что-то меняем → Смотрим на показатели → Делаем выводы

Например, внедряем CI или меняем архитектуру, а потом смотрим, как меняются трудозатраты на задачу для каждого участника процесса.

Один из авторов канала внедрял статистическое отслеживание динамики процессов разработки. Графики постом выше — было и стало по одному разработчику (исходные данные утеряны, остались только скрины с разным масштабом).
Ось X — количество жоподней на одну задачу.
Ось Y — количество задач, которые заняли соответствующее кол-во жоподней.

На первом графике горб смещен правее — это старая версия продукта, где большая часть задач занимала два дня. После изменений горб подрос и сместился левее, до одного дня. В новом продукте срок решения уменьшился вдвое, значит, изменения оказались положительны.

Разумеется, просто так собирать все подряд в гистограммы бесполезно. Нужна подготовительная работа и методики осмысления и применения результатов. Но это, уж простите великодушно, и есть тру-манагерская работа, а не только сторипоинты по спринтам раскидывать. Для старта посмотрите двухчасовой стрим Максима Дорофеева про методы прогнозирования и оценки проектов.

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

Моими самыми любимыми фичами в котлине являются null-safety и sealed-классы. Но не всегда мы работаем с модным котлином, иногда приходится брать в руки старую-добрую жабу. И если sealed классы таки завезли, то борьба с нуллами продолжается. С джавы версии 14 NPE стали чуть более информативными, но багов от этого меньше не стало. Остается надеяться только на статанализ. Одно из таких решений — NullAway от Uber. Это плагин для Error Prone, который позволит отловить NPE еще на этапе сборки. Наверное это единственное более-менее вменяемое и актуальное на данный момент решение. Или же есть что-то еще? Будет круто, если поделитесь своим опытом борьбы с NPE в комментариях (желательно успешным, но тут всякое бывает, да).

Merry Christmas!!!

В библиотеке log4j под Apache ночью вдруг нашлась 0-day уязвимость, приводящая к удаленному выполнению кода (RCE). К этому всему удовольствию прилагается рабочий PoC, опубликованный на GitHub.

На момент появления PoC у дырки не было даже CVE (сейчас уже есть - CVE-2021-44228). Известно, что уязвимость работает на куче сервисов, к примеру - Steam, iCloud и пр.

Эксплойту подвержены версии Apache log4j вплоть до 2.14.1. Сканирование сети на предмет уязвимых серверов уже идет (странно было бы ожидать другого при наличии рабочего PoC).

В качестве меры смягчения сначала предлагалось обновить log4j до версии 2.15.0-rc1, но буквально в течение нескольких часов был найден способ обхода исправления, поэтому теперь рекомендуют обновлять до 2.15.0-rc2. Кроме того, некоторые инфосек эксперты рекомендуют установить log4j2.formatMsgNoLookups в значение true.

Также LunaSec со ссылкой на китайцев говорят, что эксплойт не работает на версиях JDK выше 6u211, 7u201, 8u191 и 11.0.1.

Ну а вишенка на этом рождественском торте - эксплойт работает на всех версиях Minecraft начиная с 1.8.8.

Apache Foundation пьют валерьянку и молчат.

Merry Christmas, дорогие наши, Merry Christmas!!!

Еще один шаг сделал Котлин в борьбе с засилием примитивных типов. Котлин 1.5.0 представляет Value Classes.

В чем проблема?

fun calculateAvgSpeed(distance: Int, time: Int) { … }

fun main() {

   val weight = 64 // kg
   val time = 60 // sec 
   calculateAvgSpeed(weight, time) 
} 

Скомпилируется, выполнится без проблем. Ведь Int может представлять все что угодно: время, расстояние, вес и пр. И, скажем в Java нет никакой возможности бороться с этим.

В Котлин были data classes

data class Distance(val distance: Int) 

Которые решали эту проблему, но все же в создание они тяжелее примитивных типов: под них надо выделять место в куче, а не в стеке.

Другим вариантом были type alias

typealias Distance = Int
fun calculateAvgSpeed(distance: Distance, time: Int) { … }

но он не спасает от использования примитичного типа вместо Алиса

fun main() {

   val weight = 64 // kg
   val time = 60 // sec 
   calculateAvgSpeed(weight, time) 
}

Все еще работает :(

И вот теперь нам доступен value class

@JvmStatic
value class Distance(val distance: Int) 

Который является как бы оберткой над примитивным типом, а с другой все еще хранится в стеке, а не в куче. А это значит что Garbage Сollector не надо будет беспокоить по-мелочам.

@JvmStatic
value class Distance(val distance: Int) 

fun calculateAvgSpeed(distance: Distance, time: Int) { … }

fun main() {

   val weight = 64 // kg
   val time = 60 // sec 
   calculateAvgSpeed(weight, time)  // does not work anymore
   calculateAvgSpeed(new Distance(64), time) // works perfectly
} 

```

таким образом можно наконец-то можно навести порядок с примитивными типами
Подробности

Интересный материал от Ивана @emacsway_log о балансе между Prediction и Adaptation и о том, что маятник снова несется в сторону Prediction.

Что это вообще такое?
Prediction — проектирование заранее или наперед. Делаем то, что нужно будет в будущем. Любой агиле-коуч вам скажет, что это зло.
Adaptation — проектируем по мере возникновения потребности, адаптируемся к условиям, оттягиваем принятие решения на более поздний момент.

Во все времена в разработке был и тот и другой аспект, но в разных пропорциях. До недавнего времени лидерство было на стороне Adaptation, но кажется Prediction снова набирает обороты. В общем, будем посмотреть.

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

Webinar Software architecture the hard parts. Нил Форд и Марк Ричардсон 9 февраля будут рассказывать о Granularity and coupling in microservices. Ну и собственно о своей новой книге.
Спешите зарегистрироваться!

Певая их книга Fundamentals of software architecture просто must read. Так что, я считаю доклад нужно слушать обязательно. Английский язык

Год только начался, а мы уже устали и подвыгорели.

О выгорании мы писали ещё в прошлом году.

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

Что ещё следует знать о выгорании

Читайте, пишите в комменты, спрашивайте, может быть чем-то сумеем помочь.

Подъехала запись вебинара Нила ФОрда и Марка Ричердсона Software architecture the hard parts. Они рассказывают о Granularity and coupling in microservices https://www.youtube.com/watch?v=F9r04PuaOcs

Вышел новый техрадар thoughtworks.com/radar

Что приглянулось, чтоб подробнее поразбираться:
- транзакционная архитектура https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html

- КУПИДон https://dannorth.net/2022/02/10/cupid-for-joyful-coding/

- Четыре ключевые метрики https://www.thoughtworks.com/radar/techniques?blipid=1298

- Сальса https://slsa.dev/

- https://www.testcontainers.org/

и многое другое.

Как вам эта версия радара? Что вы отметили для себя на будущее?

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

На этот раз дыра в самом спринге, немного описания на опеннет.
Инфы пока не очень много, непонятно действительно ли все так плохо, но будем наблюдать.

UPD: CVE назначен, обновления выпущены. Больше информации по ссылке на CVE.

Участившиеся случаи нахождения дыр размером с ангар для дирижабля дает нам повод наконец-то задуматься о существующих процессах разработки. Как заведено в индустрии? Делаем фикс, даем как следует "настояться" ветке с ним, затем Его Величество Тимлид может быть смержит получившееся безобразие в свободное от заказа воды в офис время. Далее передаем на ручное тестрование в отдел QA, где фикс будет протестирован согласно плану в Q2 следующего года.

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

В первую очередь в голову приходит мысль об организации SSDLC и мысль вполне себе правильная и годная. Но только будет ли толк от всех ваших дастов, састов, аппсеков и прочих секурити-чемпионов, если банальный фикс у вас заезжает на прод целый месяц? Если же вы задумываетесь о том, как построить стабильный процесс с быстрой реализацией, деплоем и минимумом проблем, то в качестве начальной точки настоятельно рекомендуем ознакомиться с исследованием Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

Суть такова. Исследователи проанализировали работу большого количества команд (около 2000 компаний) и выявили статистически значимые организационные и технические факторы, которые влияют на скорость, стабильность и качество разработки и даже на скорость выгорания отдельного разраба. Чтобы вас заинтриговать - некоторые вещи, которые они обнаружили покажутся контринтуитивными и могут случайно сломать вашу картину мира. К примеру, только что начатый проект (который мы конечно же сделаем правильно) не обязательно разрабатывается быстрее и стабильнее чем старое пожухлое легаси, с которым никто не любит возиться. А если точнее — явной корреляции между новизной и скоростью нет.

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

Работая с тактическими паттернами DDD, в очередной раз убеждаешься какой же этот ваш DDD "душный" в хорошем смысле слова. Вот буквально на днях пилили небольшой объект-значение, отражающий количество (при этом количество может быть дробным значением). И в процессе запилки возникли вопросы вида
- Какие могут быть максимальные и минимальные значения?
- Какая должна точность дробной части?
- Как округляется значение при выполнении арифметических операций?
- Какие вообще арифметические операции допустимы, с какими аргументами и в каких диапазонах?
- Как вести себя при переполнении?

И это довольно простой класс, ничего особенного. В обычном случае пишут что-то вроде fun calculate(float: count) и забивают, мы же уделяем столько внимания казалось бы такой незначительной чиселке. И в итоге может показаться, что все это не нужно. Да и вообще тратим больше времени - нужно подумать, написать тесты, etc. Но это не совсем так, ведь мы получаем:
- Снижение когнитивной нагрузки. Мы работаем над небольшим независимым кусочком кода и за счет этого яснее видим граничные случаи.
- Сами тесты получаются проще и шустрее, их дешевле поддерживать. Местами очень хорошо заходит property-тестирование
- Самый главный пункт - мы защищаемся от нелепых багов вида "нам передали отрицательное число в качестве количества, а мы его пропустили, потому что забыли провалидировать. Теперь надо полбазы перетряхнуть на проде, чтобы устранить последствия".
- За счет инкапсуляции упрощается сам код, ведь нам не нужно таскать и копипастить разного рода проверки.

Итого, если количество тестов и растет, то время на их написание (незначительное) компенсируется отсутствием детсадовских багов, а так же более читабельным и поддерживаемым кодом.

Вдогонку к предыдущему посту. Мне кажется, что мы отчасти утратили способность видеть какие-то абстракции как в коде, причем как на уровне классов, так и на уровне целых модулей. Не берусь утверждать, но если нас попросить замоделировать, скажем, небольшой UI-фреймворк для рисования окошек в ООП-парадигме, то в итоге мы получим что-то вроде классических WindowService, ButtonService и прочих *Service, настолько мы привыкли к шаблонам типа контроллер-сервис-дао. Поэтому при проектировании мы частенько используем следующий прием: закрываем глаза и представляем как бы мы спроектировали программу/модуль/класс, если бы все данные гарантировано помещались бы в ОЗУ и никогда оттуда не исчезали. Забудьте про все идентификаторы, слои доступа к данным и тому подобное. Попробуйте прикинуть хотя бы на бумажке как это могло бы выглядеть. Думаю, основную суть вы уловили.

Конечно, в дальнейшей реализации вопросы размещения в хранилищах никуда не денутся и их придется решать, но такой подход позволяет отлепить мозг от аспектов, связаных с представлением данных в БД (мы сразу же начинаем думать про то, как разместить данные) и найти интересные конструкторские решения.

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

Мы же уделяем повышенное внимание удобству локальной разработки и следуем концепции "одной кнопки" (ну или скрипта если хотите). Идея состоит в том, чтобы частые и не очень действия на локальном компе можно было выполнить одной "кнопкой". Что это может быть
- Прогон всех тестов
- Запуск приложения со всеми зависимостями (н-р через docker-compose)
- Сборка докер-образа
- Подготовка окружения
- Накатка тестовых данных
- Прогон линтеров и статанализаторов
- etc
В общем все, что вам вздумается и потребуется. Причем у самих "кнопок" не должно быть параметров (зашиты врутри или есть по-умолчанию), либо их должно быть по минимуму, если без параметров совсем никак.

Что мы получаем, применяя такой подход:
- сниженную когнитивную нагрузку - больше не нужно помнить все параметры и комбинации действий, которые приводят к нужному результату, как следствие экономим время и душевные силы. По хорошему, мы вообще должны забыть о таких вещах. Если вы не помните как запускать приложение, а все при этом работает и разрабатывается - хороший знак.
- быстрый старт для новичков - скачал репо, жмакнул скрипт и все готово, можно браться за весло
- возможность организации труЪ-СI, ведь непрерывная интерграция - это процесс, а не билд-сервер. Билд-сервер при этом нажимает практически те же "кнопки"
- из предыдущего пункта можем получить экономию средств, так как какие-то вещи мы можем проверить локально и быстро, нежели ждать своей очереди на билде и возвращаться к нему в случае паденя. Да и тачки у разрабов обычно гораздо быстрее, нежели дохлые билд-сервера.

Да, такое нужно поддерживать, не все операции можно прогнать локально, и вообще какой-никакой порядок должен быть в проекте. Но зато вы разгружаете голову и экономите кучу нервов и времени, а используя такие вещи в повседневной рутине, вы тем самым снижаете затраты на поддержку инструментов. В общем-то это банальная автоматизация, но по нашему мнению крайне важный элемент разработки. Собсна, любой новый проект (ну или даже старый, где такого нет) мы начинаем с такого рода автоамтики. В общем, настоятельно рекомендуем попробовать подход, если еще не применяете.

Всем привет! Мы тут решили немного скооперироваться с ребятами из других каналов, (таких как @emacsway_log и других) и замутить совместный тг-канал. Будем публиковать туда значимые материалы, как свои так и не очень, проводить архитектурные и управленческие мероприятия. Надеемся, что со временем получится создать полноценную ассоциацию арихитекторов и сломать убеждение, что говнокод - это норма. Наш же канал никуда не девается, как и прежде будем публиковать свои рабочие ситуации (благо материала сейчас набралось столько, что не успеваем разобрать), наблюдения, анонсы, а так же планируем новые виды развлечений форматы.

Подробности в первом посте нового канала RSAA. Добро пожаловать!

Новое видео на канале Continuous Integration — это не Сервер и даже не Jenkins.

Continuous Integration упоминается еще в XP практиках Кента Бека задолго до появления CI Серверов. Но это прекрасное понятие трансформировалось в "Jenkins Стоящий в углу", и зачастую он уже не то что не помогает разработке а только тормозит ее.

Мы нашли 3 вопроса (в книге Accelerate), которые стоит задать себе чтобы понять насколько хорош ваш Continuous Integration процесс

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

Если сомневаетесь, посмотрите лекцию из курса:

Архитектура с высоты птичьего полета (1 час 15 минут)

Материал поможет вам начать писать здоровый код и порицать тех, кто пишет плохой 😉

Подробнее о курсе
1. Ждать группу не нужно. Начинайте в любой момент.
2. Самостоятельный формат курса доступен по двум тарифам — Экспресс (без домашек) и Базовый (с домашками и всем таким). Тарифы на сайте.
3. Талантливых учеников рекомендуем в ThoughtWorks.

Будут вопросы — пишите @dubrova_a