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

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

Хоть публикация уже довольно старая, но мы пользуемся описаным подходом в своих проектах и лучше пока ничего сообразить не смогли. Есть только одно НО. Скажем, любители анемичных моделей могут не понять, что такое Domain, а так же испытают трудности при запиливании тестов для репозиториев, но таков их путь

Скоро выйдет перевод важной книги — Изучаем DDD – предметно ориентированное проектирование

Зачем читать. Изучаем DDD — актуальный сборник знаний по предмету. Со времён Эванса индустрия шагнула вперёд, появились события, микросервисы и другие ништяки. Автор рассматривает DDD не в академическом вакууме, а в контексте применения на современных проектах.

Кому читать. Да всем, собственно. Книга рассказывает простым языком о базовых концепциях: Bounded Context, Ubiquitous Language, Aggregate Root и прочих. Постепенно автор переходит к вопросам практики: какие конкретно паттерны использовать, как правильно поделить приложение на микросервисы.

Не только теория. Книга не оставит вас один на один с кучей теории. В ней описаны практические эвристики, которые помогут принимать решения. Заодно сможете доказать коллегам, что DDD — это не про Entity, Managers и Domain Service, а в первую очередь метод эффективного управления сложностью предметной области.

К переводу приложил руку и я (Женя). Книжку пришлось несколько раз вдумчиво прочитать, поэтому могу смело её вам рекомендовать.

Книжка ещё не в продаже, но мы сообщим, как откроется предзаказ.

🇯🇵 Почетное первое место в номинации «Самый поехавший процесс разработки» занимают японские IT-компании. 🇯🇵

Мой коллега-китаец проработал год у японцев и сбежал оттуда с криком «да там нет места для творчества!»” А, поверьте мне, креативность и творчество — это не самая сильная черта китайской нации… Далее рассказываю с его слов.

Окрестности Токио, 2020 год. Компания работает по водопадной модели. Но так как это японцы, то водопадная модель возведена в абсолют, до уровня религиозной догмы.

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

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

Документация — истина в последней инстанции. Если документация вам кажется нелогичной, то вам просто кажется. Немыслимо написать код, который не соответствует документации.

Что мешает человеку, который пишет столь подробную документацию, сразу написать код? Это филосовский вопрос. В Японии у каждого своя зона ответственности.

А теперь представьте, сколько времени занимает проектирование и написание этой документации! Какая уж тут быстрая обратная связь.

P.S. Теперь я понимаю, почему не знаю ни одной большой софтины из Японии. Но я не понимаю, как они умудряются таким образом все таки писать актуальные прошивки для фотокамер Fuji, Canon и Nikon.

P.P.S. А ещё попробуйте представить, что будет, когда в Японии дойдут до аджайла со скрамом, которые они реализуют буквально и со своим звероподобным рвением.

Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»

Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂

Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.

Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).

Like/Share 🙂

Сережа Баранов мутит встречу по ES, рекомендуем заглянуть!

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

Подробности в видео https://youtu.be/sCVPvZrIrpM

Не согласны? Или знаете другие недостатки? Давайте дискутировать в комментариях!

Теперь и в наличии)

https://bhv.ru/product/izuchaem-ddd-predmetno-orientirovannoe-proektirovanie/

Как IT-специалисту вырасти до $360.000 в год?

Мы открыли доступ к лекции о лучших инженерных практиках Thoughtworks из нашего основного курса. Знания этих практик увеличивают стоимость специалиста на рынке до 30.000 $ в месяц. В ролике к этому посту Серёжа подробно рассказывает, откуда эта цифра и как всё взаимосвязано.

Лекция откроется сразу после прохождения опроса. Он займёт 5 минут, а нам поможет заточить курсы под ваши потребности и чаще радовать вас качественным контентом :3

Опрос и лекция:
https://forms.gle/RxjaKxMMdQkVsEF98

Разыскивается Backend Lead (Kotlin)

Воспользуюсь служебным положением и поделюсь вакансией. Ищу себе в команду бекенд-лида со знанием котлина, который разделяет те ценности, о которых мы тут вот уже несколько лет рассказываем. Кому интересно, оставляйте отклик на HH.

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

Чтобы понять, не стала ли архитектура проекта «дорогой», пройдите по опроснику. Для каждого вида свой набор вопросов.

Монолитная
- Достаточно ли команда инвестировала в модуляризацию?
Какое выбрано направление зависимостей между этими модулями?
- Не предполагается ли наплыв пары миллиардов пользователей в ближайшее время?

Микросервисная
- Может ли команда независимо деплоить микросервисы?
Если один из микросервисов ушёл отдохнуть, смогут ли оставшиеся продолжить работу?
- Достаточно ли команда вложила в devops-практики или таскает исполняемые файлы на прод руками?
- Подтверждено ли автоматическим тестированием совместимость микросервисов?
- Достаточно ли команда инвестировала в мониторинг?

Слоеная
- Договорились ли вы с командой, какой вариант слоёнки вы используете: открытые или закрытые слои, каково направление зависимостей, особенно между доменом и data access layer.
- Какие слои, собственно, у вас есть? Куда вы положили слои, выбивающиеся из стройного ряда API Layer, Business layer, Data Access Layer? Например, где лежит взаимодействие с другими сервисами?
- Уверены ли вы, что приложение не слипается в big ball of mud и вы хорошо отделили один слой от другого?

Hexagonal\Clean Architecture
- Вся ли команда понимает принципы этой архитектуры и почему она выбрана для проекта?
- Достаточно ли вы изолировали слои и контролируете направление зависимостей между ними?
- Если кто-то притащит в домен половину вашего любимого фреймворка, то через сколько часов или дней вы это заметите?

Event-Driven architecture
- Как вы понимаете, отвечает ли код бизнес-процессам или нет?
Как вы ищете проблему в коде, когда поняли, что что-то идет не так?
- Может ли текущая версия любого сервиса запроцессить event, пришедший ей 2 года назад?
Те же вопросы стоит задать микросервисной архитектуре, только с лампой в лицо опрашиваемому, поскольку цена ошибки тут много выше.

А какие вопросы вы бы задали, светя лампой в лицо опрашиваемому тимлиду\архитектору?

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

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

За час совместной работы мы распутали большую часть кренделей и избавились от нескольких циклов ревью. Понятно, что менеджерам польза не очевидна, но вам-то объяснять не нужно.

State of Developer Ecosystem

Подъехали результаты большого ежегодного исследования разработчиков от JetBrains.

👉77% разработчиков используют ChatGPT, а 46% – CoPilot. Самый частый сценарий – задавать вопросы общего характера про программирование.
👉Выгорание за свою карьеру переживали 73% разработчиков.
👉Для 58% первым шагом к обучению программированию было формальное образование. На втором месте – книги, но уже только 10%.
👉Только у 63% разработчиков в проекте есть юнит тесты.
👉Среди языков программирования единственным растущим остался Rust.
👉Три самых высокооплачиваемых языка: Scala, Go, Kotlin.
👉Новые языки чаще всего учат просто ради интереса, для работы над личными проектами и чтобы следить за трендами.

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

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

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

Первый матч команда выиграла, но во втором проиграла. Шансы на выход в финал стали призрачными и наш тренер уехал домой.

Выводы. Если вы работаете в международной компании, и уж тем более руководителем, учитывайте менталитет.

Хакатон с чествованием победителей сильно взбодрит американцев. Но азиаты просто не поймут, зачем это всё. А немцы вообще не придут, потому что рабочий день закончен.

Или, скажем, тестировщики начнут играть с разработчиками в футбол, перекидывая задачи из DEV в QA и обратно. Вы решите самого активного футболиста повесить на стену позора. Американцев и китайцев эта угроза мотивирует меньше косячить, одним нельзя быть лузерами, а другим важно сохранить лицо. А вот российские программисты демотивируются и будут на кухне обсуждать вашу тиранию и планы по слому системы. Но это, конечно, моё субъективное мнение. Если у вас другое — велкам ломать копья в комментах.