Вдогонку к предыдущему посту. Мне кажется, что мы отчасти утратили способность видеть какие-то абстракции как в коде, причем как на уровне классов, так и на уровне целых модулей. Не берусь утверждать, но если нас попросить замоделировать, скажем, небольшой 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

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

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

От себя добавим. Книга по DDD от этого автора действительно лучшая из того что мы читали по этой теме.

Если кто не знает, Мартин Клеппманн — это автор знаменитой книги Designing Data-Intensive Applications (которая с кабанчиком, да)

👀 Новое видео на канале!
Топ жести на собеседовании: https://youtu.be/KdmYL8TJEIA

Что делают большинство разработчиков, когда им нужно провести собеседование? Правильно, гуглят 100 вопросов на собеседование на ${любимый_язык}. А потом мы все жалуемся, что на собеседованиях творится какая-то вакханалия.

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

🙏 Не забудьте поставить лайк и подписаться на YouTube канал, если видео вам понравилось!

Пост немножечко ни о чем

Работал тут намедни с участком системы, у которой а) отсутствовала «единая кнопка» и б) не было тестов.
Все это появилось до моего прихода на проект и возводить такие конструкции мы сознательно не стали, ибо этот код в скором времени должен быть убран из проекта насовсем. Но что-то в нём пофиксить бывает нужно прямо сейчас, пока он ещё существует.

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

Если вы испытываете те же чувства, то крайне рекомендуем присмотреться к пирамиде тестирования и другим геометрическим фигурам. Если вы сможете её реализовать, по другому уже работать не захотите, проверено на себе.

Господа, начинаем цикл видео “Философия Kotlin для Java разработчиков”. Для начала разберем что такое null safety в Kotlin и как его использовать в реальной жизни
https://youtu.be/AkL7uFm8ze4

А в следующем видео разберем не менее важное: immutability в Kotlin. Stay tuned!

Недавно писали про энтерпрайз-деформацию, теперь еще раз столкнулись с этим на практике. Очень показательный случай вышел.

Суть такова. Дали нашему подопечному задание реализовать марсоход (задание на тренировку TDD). В первом варианте решения были угадайте что? Прааавильно, Spring и MarsRoverService. Спустя несколько итераций задание было побеждено голой джавой без фреймворков (ну разве что junit остался). Комментарий автора:

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

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

Новое видео “Философия Kotlin”. На этот раз поговорим об Immutability: как добиться и какие плюшки она дает. Приятного просмотра
https://youtu.be/1p36DxAGP_0

Коллеги, на этот раз мы делимся информацией как использовать Immutable Коллекции в Kotlin и чем они отличаются от Java Immutable коллекций. Если вы только присматриваетесь к Котлину очень рекомендую https://youtu.be/m8X8gp5nqi4

Мы уже много раз говорили и про локальный CI (когда все или почти все проверки проходят локально) и про удобный интерфейс "одной кнопки". При использовании такого подхода, помимо очевидной экономиии времени есть еще и экономия вычислительных мощностей билд-сервера. Можем меньше платить как за потребленные ресурсы, так и машины выбирать чуть послабее. На скришоте результат работы команды из 3,5 человек за пару-тройку дней. Тут всего 2 падения. Первый раз сборка упала из-за экспериментов на инфраструктуре, второй раз - потому что я не проверил локально (запушил мимо хука). Специально замерил, в лучшем случае мне удается прорваться сквозь статанализаторы и прочие проверки где-то с 3-4 раза, даже если изменения несущественны. Думаю понятно, сколько времени и ресурсов мы в итоге сэкономили.

Если вы не можете объяснить начальству что такое технический долг и легаси, то вот вам хороший пример от нетехнаря (поэтому могут быть неточности), но со способностью хорошо объяснять сложное.
https://vitalyfilatov.ru/all/techdebt-and-legacy/

Продолжается прием заявок на доклады конференции по архитектуре IT-решений ArchDays 2022!

В этом году мы возвращаемся в офлайн!
Конференция пройдет 21 октября в Москве + Online-трансляция.

Основные тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
6. Кейсы

Всего в программе будет около 30 докладов и 4 очных воркшопов.

Подать заявку на выступление: https://archdays.ru/#speaker

Кажется мой доклад взяли на ArchDays 2022!

Новое видео на нашем канале. Наводим порядок в проекте, смотрим примеры, делаем выводы