StringConcat - разработка без боли и сожалений

ООП vs функциональное программирование? Или все же они прекрасно дополняют друг друга?
Смотри новое видео на нашем канале https://www.youtube.com/watch?v=3rhP73g9z5U

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вышел новый техрадар 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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще один шаг сделал Котлин в борьбе с засилием примитивных типов. Котлин 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
} 

```

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

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!!!

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

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

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

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

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

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

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

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

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

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