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

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 и обратно. Вы решите самого активного футболиста повесить на стену позора. Американцев и китайцев эта угроза мотивирует меньше косячить, одним нельзя быть лузерами, а другим важно сохранить лицо. А вот российские программисты демотивируются и будут на кухне обсуждать вашу тиранию и планы по слому системы. Но это, конечно, моё субъективное мнение. Если у вас другое — велкам ломать копья в комментах.

Test-driven Development (TDD), не замедляет вас.

Он делает вас быстрее!.

Люди говорят, что TDD да и даже написание тестов занимает много времени, потому что нам приходится писать много тестов.

Если у вас нет времени на написание тестов, это значит у вас есть время на:
• отладку вашего кода
• исправление ошибок на продакшене
• исправление сломанных CI/CD пайплайнов
• постоянный запуск вашего приложения вручную
• ручной ввод тестовых данных снова и снова

Разработчики часто забывают учитывать все часы, потраченные на отладку, исправление дефектов и поддержку не протестированного кода.

Хорошее тестовое покрытие устраняет все эти потери, экономя огромное количество времени и нервов.

Тесты не дорого, Исправлять одни и те же ошибки снова и снова Дорого.

P.S. Лично мне нравится код писать, а не в формочки тыкать. А Вам?

А мы по-прежнему ищем ведущего разработчика)

https://spb.hh.ru/vacancy/90016905

Кто такой CTO, что он умеет и как ему живется (не очень)

Ютуб подкинул видео Simon Raik-Allen о позиции CTO — Chief Technical Officer или Технический директор.

Краткие выводы:

1. CTO — ещё более несчастное животное, чем тимлид. Ему нужно усидеть одной задницей на трёх стульях между продавцами, Большими Боссами (CEO) и инженерами (VP of Engineering).

2. Чтобы быть CTO, нужно понимать бизнес, шарить в технологиях и погонять разрабов, чтобы красили забор в срок.

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

Ролик на Ютубе: https://www.youtube.com/watch?v=alQzU0Uob5Y

Мы с Серёжей постоянно нудим, что писать тесты нормально и здорово для всего, кроме разве что совсем примитивных вещей типа геттера/сеттера.

Есть ещё одна вещь, которой вроде не нужны тесты — ин-мемори хранилище.

Это паттерн Fake, который позволяет нам заменить весь data access layer с базой данных на легковесное хранилище в памяти, часто реализуемое на какой-нибудь HashMap. В прод такое, конечно, не идёт, но чтобы показать прототип пользователям и заказчикам годится и сильно экономит время. Так вот, код в этом случае выглядит максимально примитивно:

fun save(e: Entity) {
storage[e.id] = entity
}

или

fun find(id: EntityId) = storage[id]

Кажется, что тут ошибиться негде, но даже в такой фигне я делаю ошибки. Недавний рекорд — 3 ошибки на 3 строки кода. Перепутал в фильтре not, > и < и забыл смержить результаты. Пришлось три раза передеплоивать кластер и напрягать мозговину, пока не нашёл. С тестами на это ушло бы меньше времени и нервов.

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

В общем, писать тесты нужно. Не написал тест — считай, что не написал код.

Ребята, есть тут кто тесты не пишет принципиально?

Вопрос к вам. Как выходные проходят? Всё успели починить?

В комментариях к недавнему посту товарищ Roma Jadrovski написал верное замечание. Если сохранить сущность, как это указано у нас, а затем изменить её состояние методом, в хранилище окажется уже как бы не совсем она. То есть:

// В одном конце вселенной 
entity.setField(value1)
repo.save(entity)

// Во другом конце вселенной
entity.setField(value2)

// В третьем конце вселенной
entity = repo.get(id)
entity.getField() == value1 // false ???

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

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

Из внутреннего: однажды у тимлида

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

Тесты для слоёнки писать было сложно и занудно. Зато, когда QA находили баг и я лез в глубины бэка искать его причины, погонщик спокойно спрашивал:

— А ты написал тест? Если написал — сиди ровно.

И в 95% случаев он оказывался прав: баги находились где угодно, но только не на бекенде.

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

Мораль. Мы, конечно же, ни к чему не призываем. Каждый сам выбирает, спать ему по ночам после релиза или нет.