Разобрали проблемы Layered Architecture, теперь поговорим о чем-то позитивном. Например о Clean Architecture и как она решает проблемы, созданые Layered Architecture https://www.youtube.com/watch?v=A37crsbFYeo

Почему Hexagonal Architecture лучше Layered Architecture, почему с ней проекты реже превращаются в big ball of mud? Потому что она точнее описывает правила и оставляет меньше возможностей для различной интерпретации. Вот скажите разработчикам “используем Layered architecture” и один сделает зависимости из домена на слой доступа к данным, а другой наоборот. Один решит что можно и пропустить слой домена и вызвать из API сразу Repository, чтобы сохранить несколько тактов процессора. А другой решит что так нельзя. И каждый из них по-своему прав. Слоненка она такая…

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

Но самый интересный пункт — скатывание самой ЧА в ком грязи. Расскажите, пожалуйста, в комментариях, что конкретно произошло, желательно указав технологию, ибо некоторые технологии прямо таки провоцируют.

Очень интересно. А мы попытаемся разобраться в причинах.

Я решил подвести итоги по опросу:
70% Layered Architecture превращается в Big Ball of Mud
и только 9% Clean Architecture.

Поделился своими выводами вот здесь https://youtu.be/zl-wsU_Frd4

Господа, продолжение цикла про Clean Architecture. На этот раз рассматриваем на примере. И без кода! https://youtu.be/W6jCUNb3yPg

Реальная история как я ходил на собеседование.

Позвали меня в финтех-стартап местный в Сингапуре пособеседоваться на Principal Engineer. HR говорит все будет easy, приди, вы там с инженером поговорите по-душам о ваших любимых программистах штучках и все. Никакого верчения деревьев на время.

Прихожу:
- Привет
- Привет
- (и с порога) Что ты можешь сказать о коллекциях в Java?
Тут мне показалось что хорошего диалога не выйдет. Ну, оказалось что не казалось
- Ну говорю, чего там у нас Collection, который вроде как Iteratable, и Map в стороне сиротливо стоит. Ну и вот от коллекшена унаследованы, List, Set, Queue и что там еще
- а еще там Стек есть.
- Круто, да.

- Ну ок, а расскажи как HashSet работает
⁃ Я говорю черт его знает, надо будет — посмотрю исходники. Но название намекает на то что внутрях то используется HashMap. Вот ключ явно Хеш, а значение… хим, может сам объект, может Список а может еще что
⁃ Знаешь, а там вот дерево используется
⁃ Круто. Рад за них

⁃ Как реализована SyncronizedHashMap?
⁃ Ну говорю, в жизни не видел, так как она вроде устарела еще до моего рождения, но намекает что наверное ацессоры синхронизированы.
⁃ Мммм, ну там не сам аццессор синхронизирован, а бакет внутри мапы.
⁃ Круто, расскажи мне еще про бакеты 🙂

И вот так мы беседовали час. Ну думаю, либо я сейчас уйду и меня будут считать полным идиотом, или я все таки попробую перевернуть эту ситуацию. И говорю:
- То есть, у вас в проекте используется вся эта асинхронщина каждый день?
⁃ Нет, какой там.
⁃ Ну то есть планируете использовать в будущем
⁃ Ну может быть когда-нибудь, но до этого далеко
⁃ Хорошо, а какие у вас сейчас проблемы?
⁃ Ну у нас нет ни тестов, ни архитектуры. А как оно работает мы сами не до конца понимаем (я вот не шучу сейчас).
⁃ То есть мы с тобой потратили час времени на то, чтоб говорить о вещах, которые совершенно не релевантны проекту, но зато не поговорили действительно о том что вам нужно, и на что у меня даже есть бесплатный курс?
Молчание было мне ответом….

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

На контрасте. Еще одно собеседование из моей жизни

Опять собеседуюсь на Principle Software Engineer (Lead Team Lead’ов) в один финансовый стартап.

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

Мы с ними интересно пообщались: я узнал у них реальные не функциональные требования, предложил решения их болей из моего опыта. И мы вместе нарисовали диаграмму to-be системы.

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

Вот на мой взгляд это пример очень хорошего подхода к собеседованиям!

Не важно кого вы собеседуете: архитектура и программиста, будете вы кодить вместе или будете рисовать диаграммы:
Просто возьмите типичную и интересную задачу, которую вы реализовали и попросите кандидата ее реализовать. Обсуждайте ее так, как бы вы ее обсуждали с членом своей команды.
И вы узнаете как кандидат справляется с практическими задачами, а не с абстрактными кручениями деревьев в голове (если конечно кручение деревьев — не типичная задача в вашей компании). А так же как он организует свою работу: как относится к тестам, думает ли о том как будет проект деплоится, или его “работа” заканчивается написанием кода.

Кстати, как вам подход? Напишите в комментариях какие ваши любимые подходы к собеседованию и почему. Обсудим!

Амазон Prime Video сократил стоимость инфраструктуры на 90% перейдя с микросервисов на монолит.

Сразу оговорюсь, не весь Amazon Prime, а конкретное подразделение, следящие за качеством видеопотока на наших с вами ноутбуках, мобильниках, и где мы там еще смотрим видео.

Сейчас на пальцах объясню что произошло:

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

И они очень логично решили, что один сервис будет нарезать видео на кадры, складывать их в Amazon S3 (файлохранилище), а толпа других (анализаторы) будет из S3 читать скриншоты и искать дефекты.
Плюшки подхода:
- они могут масштабировать сервисы независимо друг от друга
- использовать amazon Lambda
- они легко могут добавлять новые анализаторы и старые ничего об этом не узнают.
И тут все очень логично. Я не могу их обвинить в злоупотреблении микросервисами. Ей богу, я бы сам так же сделал!

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

В итоге:
Они решили что обмен данными внутри процесса будет намного дешевле и слепили эти микросервисы в монолит, попутно выпилив S3, так как скриншот передается теперь просто в памяти.

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

Вот так… 90% экономия на инфраструктуре. Впечатляет!

Расскажите в комментариях, что вы сами думаете о микросервисной архитектуре, приходилось ли вам видеть проект написанный на микросервсиах ради микросервисов?

Пруф: https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

10 июня стартует обучение новой группы по практическому курсу "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

С сегодняшнего дня объявляем предзапись на курс. Тем, кто оплатит курс до конца месяца, делаем скидку в 5000 рублей. Цена со скидкой 85 000 руб. Есть рассрочка.

Чтобы воспользоваться скидкой, надо "застолбить место" на сайте howto.stringconcat.com/enterprise и оплатить до 30 мая часть курса. Бронь места идёт в счёт тарифа (НЕ допом к тарифу).

На весь курс набираем всего 25 человек. 7 мест уже занято. (Если вы договаривались о записи раньше, то скидка будет автоматом)

В отличие от тарифов «экспресс» и «базовый» в "максимальной прокачке":

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

Что ожидать от курса?
(При условии, что вы посмотрите все лекции, сделаете практику, будете активно участвовать во всех живых встречах и прочтёте хотя бы часть из списка литературы)

1. Систематизация знаний и преодоление синдрома самозванца. Изучение принципов и основных граблей энтерпрайза.
2. Полное руководство по созданию энтерпрайз-приложений.
3. Анализ, что не так с вашим приложением, и разработка плана по его улучшению.
4. Подготовка к собеседованиям в крупные компании, после которой вас не поставят в тупик вопросы про SOLID

Для записи переходите на сайт и выбирайте тариф «максимальная прокачка»: howto.stringconcat.com/enterprise

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

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

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

Петин мозг в данном случае воспримет эту ситуацию как прямую угрозу жизни. Он, конечно, постарается сделать все, чтобы ее исправить, но осадочек, что называется, останется. И в тот момент, когда вы будете ему рассказывать про tdd, подсознательно его больше будет волновать тот факт, что если он опять накосячит с тестами, то его вышвырнут на улицу, а попробовать что-то новое без косяков невозможно, поэтому да ну его.

Как это исправить? Для этого умные люди придумали SCARF-модель, которая построена на удовлетворении 5 критически важных для мозга социальных потребностях: статус, определенность, автономность, принадлежность и справедливость.

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

Опустим закадровое желание побить Петю и посмотрим, что дает такая формулировка:
🔹+2 к статусу ("без тебя не смогли", "нам важна твоя работа")
🔹+1 к определенности (ты, конечно, налажал, но мы тебя не выгоняем)
🔹0 про автономность (увы)
🔹+1 к принадлежности ("команда")
🔹+1 к справедливости (ты что-то сделал, оно привело к таким-то последствиям, вот что тебе нужно сделать, чтобы исправить ситуацию).
Итого: 5 баллов.

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

ArchDays

27-го октября пройдет конференция ArchDays. Мы начинаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

В предстоящей конференции есть желание сделать упор на практическую деятельность: порешать архитектурные кейсы, провести архитектурную Ката, собрать архитектурное видение новых концепций архитектуры.

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

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Продолжаем (а может даже завершаем) цикл телеперерач о чистой артихектуре. Теперь с кодом! https://www.youtube.com/watch?v=q6NPKBek-BE

В прошлом посте https://news.1rj.ru/str/stringconcat/142 мы объявили о старте предзаписи на курс "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

Сегодня расскажем о программе курса. Курс затрагивает такие темы:

1. Разработка и управление требованиями
Разработка требований — самый важный этап в жизненном цикле ПО. Если вы думаете, что требования нужны только аналитикам, то сильно заблуждаетесь, ведь если неправильно разработать требования, то о качественном продукте можно забыть.

О чем ты узнаешь:
- Какие бывают требования и какую роль они выполняют
- Как подстраиваться под постоянное изменение требований
- Различие в водопадном подходе и Agile с точки зрения требований
- В чем разница между UseCase и UserStory, что из этого и когда использовать
- Как разрабатывать требования и не утонуть в неопределенности
Практика: Разработка требований через построение карт пользовательских историй

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

О чем ты узнаешь:
- Что такое CI на самом деле
- Зачем в современном мире нужен trunk-based development
- Когда правильно организовывать репозитории
- Всегда ли нужны code-review
Практика: построение процесса непрерывной интеграции

3. Архитектура: с высоты птичьего полета
Архитектура — основа всей системы. Именно она определяет успех предприятия, а не то, сколько новомодных фреймворков напихано в проект. Поначалу на нее не обращают внимания, а когда вспоминают, то проект уже идет ко дну.

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

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

О чем ты узнаешь:
- Какие основные проблемы сопровождают проект на уровне кода
- Какие метрики кода существуют и зачем они нужны
- Что такое SOLID на самом деле и зачем он нужен
- Как организовывать модульность и какие способы ее оценки существуют
- Как защитить свою архитектуру
Практика: разбор проекта на основе метрик

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

6. Sensible defaults
Практики, которые используются в приличных заведениях и чтобы от них отступить нужны веские причины.

О чем ты узнаешь:
- Как экстремальное программирование помогает справиться с неопределенностью
- Разработка через тестирование (TDD) — что это такое и почему тесты всего лишь побочный эффект методологии.
- Как парное программирование экономит время
Практика: парное программирование по TDD

7. Domain-Driven Design
Самая сложная часть курса и мозг вашего приложения. Разбираемся, почему разработчикам так тяжело понимать заказчиков и пользователей, а добавление одной кнопки требует 5 человеко-месяцев.

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

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

О чем ты узнаешь:
- Как понять действительно ли вам нужны микросервисы
- Каких проблем добавляют микросервисы
- Основные паттерны и антипаттерны при построении микросервисных архитектур
- Где находятся границы микросервисов и причем тут Domain-Driven Design

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

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

10. Тесты и тестирование
Писать тесты или нет? Если да, то для чего? И почему наши тесты снова "протухли"? Ставим точку в этих вопросах.

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

Старт новой группы – 10 июня!
Для записи переходите на сайт и выбирайте тариф «максимальная прокачка»: howto.stringconcat.com/enterprise

Почему я (Сергей) решил учить английский

Шел 2016 год, стартап, в котором я работал, банкротится и мы всей командой разработчиков идем на onside собеседование Crossover(Это американский бодишоп на который можно работать удаленно и получать не самую высокую зарплату по меркам США, но очень приличную по любым другим меркам). К слову зарплата маячила в районе 8-10k USD в месяц. Я прохожу несколько этапов coding-challenge, коллеги постепенно отваливаются. И вот остается человек 5 из 30+ и последний этап — собеседование на английском. После которого мне говорят: ты, конечно, парень умный, но приходи к нам как подтянешь немного английский. Вот так из-за английского от меня уплыли 10к USD в 2016 году в провинциальной России…

Но это дало мне нешуточную мотивацию учить английский и в конечном итоге оказаться в Сингапуре

Мой товарищ написал очень хороший гайд по тому, как ему удалось выучить английский до уровня C2.
Если вы решили что английский вам нужен — приятного чтения: https://howto.stringconcat.com/blog/how-to-learn-english

Мне очень интересно узнать что лично вас мотивировало начать учить английский, с какими трудностями вы столкнулись и какой совет дали бы тем, кто-только учит?

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

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

Требования к программистам простые:
- уметь читать написанный код
- отличать плохий код от хорошого
- обязательно уметь писать тесты до кода
- немножечко уметь писать код хотя бы на одном языке
- и уметь рефлексировать над своими провалами

Теперь посмотрим как это имплементируется в собеседованиях:

Этап 0. Собеседование с HR
Достаточно быть более-менее адекватным: не пускать слюни на интервью, более-менее понимать что тебя спрашивают по-английски. Хотя надо признать, что даже HR’ы наврят ли пропустят кандидата после фразы «а я без тестов в прод деплою прям с ноута».

Этап 1. Coding Challenge (1,5 часа)
Вам заранее высылают маленький проект на вашем любимом языке и дают ознакомится с кодом.
На самом собеседование вас обязательно спросят, что понравилось в коде, а что бы вы улучшили.
Бывали случаи, когда ребята с 5+ годами опыта говорили, что все хорошо, но лучше использовать 2 отступа вместо 4 и комментарии добавить. Тут, конечно, можно уже и не кодить. Я лично, по крайней мере от Лидов, ожидаю критику архитектуры.

Далее кандидата просят закодить одно небольшое бизнес-требование. И тут смотрим на кандидата как он:
- анализирует требования и задает уточняющие вопросы
- кодит типичную энтерпрайз-задачу
- может ли подсветить плохой код и даже быстренько его отрефаткорить
- и самое главное: пишет ли он тесты или сразу лихо начинает кодить.

По секрету скажу, что к этой задаче достаточно немного порефактрить и написать 5 строчек продакшен-кода. И тесты, куда же без них.

Кстати, напишите в комментариях, а что бы вы исправили вот в этом тестовом проекте. Можете выбрать любой язык 😉

Продолжение следует…

Завтра заканчивается предзапись на курс "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

Подробнее по ссылке - t.me/stringconcat/142
Места ещё есть.

Курс рассчитан на практикующих разработчиков. Чтобы во всём разобраться и получить от курса максимум пользы, вам потребуется:

1. Опыт работы на коммерческих проектах.
2. Знакомство с основными паттернами и инструментами разработки.

В курсе мы говорим о вещах не привязанных к какому-либо языку. Домашнюю работу вы можете делать на любом языке.

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

Как можно себя проверить?

У нас есть бесплатный курс "Поваренная книга
Дядюшки Боба: как готовить Clean Architecture". Справляетесь с поваренной книгой? Значит справитесь и с основным курсом.

Проверить себя: t.me/sc_stringconcat_bot
Записаться на курс: howto.stringconcat.com/enterprise

Продолжаем говорить про собеседование в Thoughtworks

Этап 2. Технический кругозор (1,5 часа)
Для начала кандидата спрашивают о прошлых проектах: что было интересного и чем можно гордиться.

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

Почему выбрали микросервисы — поможет понять, анализировал ли кандидат другие варианты или взял первое, что попалось
Что бы вы сделали по другому — покажет, рефлексировал ли кандидат над содеянным
Если кандидат упомянул, что знает несколько языков, спросим какой из них любимый и почему
Можно спросить о технических деталях — про особенности распределенных транзакций и всякие garbage collector’ы, — если только кандидат упоминал, что работал с ними

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

Этап 3. Culture Fit
Финальная часть собеседования, на которой оценивается насколько органично кандидат вольётся в коллектив. Для этого задаём стандартные поведенческие вопросы про ситуации на работе, два стула, вот это всё.

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

Если вам понравился процесс и вы готовы попробовать свои силы, то сейчас Thoughtworks набирает разработчиков во Въетнам 😉