Выпуск про по мобильную разработку с Алексеем Гладковым. Смотрим и наслаждаемся https://youtu.be/Vfw1vVBFuIU?si=YUuzxDltkII8EgJn

Альтернативные ссылки: Аудио | vk

Восстановление состояния в тестах

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

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

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

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

Ну и наконец вариант, который наиболее распространен и встроен во все богатые фреймворки (laravel, django, rails, spring boot, ...). В этих фреймворках до каждого теста стартует транзакция, которая в конце теста откатывается (и вложенные транзакции тоже хорошо обрабатываются). Это решение позволяет вообще не думать об очистке в процессе. Иногда делают по другому, включают автоматический truncate таблиц в базе при каждом старте тестов. Причем не ручками, а это фактически стратегия очистки, встроенная в некоторые фреймворки, где можно выбирать как чистить (или идет доп пакетом как в rails).

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

Ссылки: Телеграм | Youtube | VK

p.s. Как у вас? Мокаете или реальная база с откатом?

Ориентация на бизнес

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

Самая распространенная точка зрения, что делать для бизнеса это понять что от нас хотят, доуточнить все требования, может предложить какие-то улучшения и качественно, в срок реализовать и задеплоить. От синьора ждут, что он не просто будет делать что-то о чем попросили, но и критически на это посмотрит.

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

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

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

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

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

Начинаем серию прожарки фреймворков для тех кому интересно, что происходит в других стеках. Сегодня говорим про spring boot https://youtu.be/ElzbKGKjDrU?si=4rjFUinqkQFUQUJ4 (прошу прощения за звук, у меня был включен не тот микрофон)

Альтернативные ссылки: Аудио | vk

Третья часть разбора чистого кода. В этот раз про обработку ошибок и исключения https://youtu.be/bfhUhim0V1Y?si=oVpHi697gPjtgh_E

Альтернативные ссылки: Аудио | vk

А всё таки, когда моки зло, а когда нет?

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

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

Последний случай, описывает процесс мокирования. То есть мок, это когда мы проверяем то, как код что-то делает, а не что он делает. Иногда говорят, что мы тестируем методом white-box, потому что мы знаем как конкретно написан тест и завязываемся на это, а не на результат работы этого кода, как в black-box тестировании.

Когда мы проверяем как код работает, мы связываем тест с внутренней реализацией. Любое изменение внутри функции (например, вызов другого метода или смена порядка действий) может поломать тест, даже если внешнее поведение программы остаётся тем же. В итоге тест перестает быть защитой от ошибок и превращается в тормоз для рефакторинга. В подкасте про спринг я услышал классный термин: "бетонирование кода", вот это оно и есть.

Когда же моки все таки нужны? Допустим мы пишем систему с поддержкой хуков, например фреймворк для тестирования. В тестах такого фреймворка вполне допустимо проверить что хуки setup, teardown, beforeSetup, afterSetup и так далее, вызываются в нужном порядке и с нужными аргументами.

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

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

Например:

- Фейковая база данных, которая хранит данные в памяти.
- Фейковые сервисы какого-нибудь облака, например AWS
- Поддельный HTTP клиент, который возвращает заранее заготовленные ответы.
- Заглушка почтового сервиса, которая записывает письма в список, а не отправляет их.

Все эти решения делают тесты быстрыми, предсказуемыми и независимыми от инфраструктуры, при этом вы все еще проверяете поведение системы снаружи, не нарушая принцип black-box.

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

Итого

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

Ссылки: Телеграм | Youtube | VK

У меня сегодня с утра был созвон с разработкой Хекслета, где мы обсуждали разные задачки и там всплыла такая история. К разработке пришли ребята из b2b с просьбой. Говорят, что есть клиент, который сейчас должен оплатить подписку для b2b (она немного отличается от b2c подписки), но есть моментик. Они покупают много, поэтому им согласовали скидку на стоимость подписки.

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

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

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

Ссылки: Телеграм | Youtube | VK

Сложность обучения

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

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

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

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

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

В сухом остатке получается, что лучше делать проще и получать скучающих профи, чем делать сложно и получать по щщам от начинающих. До определенного момента конечно.

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

Все это конечно не отменяет, что сам материал никогда не написан идеально и должен постоянно дорабатываться :)

Ссылки: Телеграм | Youtube | VK

Пропускаем выпуск

Простите ребята, заболел. Не смог записаться ни с гостем ни сам, а план был вам про Хаскель рассказать. Ну ничего, скоро сделаем.

Сегодня воскресение, поэтому без кода и технических тем. Расскажу немного про погоду и почему я переехал :)

Вообще климат и вода для меня значат очень много. Это, можно сказать, была ключевая причина начать кататься по миру, а потом и совсем уехать. Еще в 2012 году, я заболел тайландом. Тогда набирал оборот дауншифтинг, люди вели блоги на ЖЖ, где рассказывали про то как это классно. Вроде даже по телику шли передачи про это. Короче я все это читал и смотрел, изучал регионы, где есть коворкинги и какая где жизнь.

Первый раз выехать туда получилось в 2014 году, тогда у меня уже появился ребенок, поэтому мы смогли заценить как это, когда не надо надевать на себя 10 слоев одежды. Жили кстати на Пхукете, он довольно круто прокачен в плане детских штук (в эту же поездку я встречался с девелоперами Aviasales там же). Спустя несколько лет мы пожили в Паттайе и даже в Малайзии, в городе с красивым названием Петалинг Джая.

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

Буквально через полгода после той поездки в тай, мы смогли съездить в штаты. Я тогда удачно продал машину и у меня возникло дикое желание прокачать английский. Поэтому я оформил себе учебную визу и поехал в Санта Монику (один из городов Лос Анджелеса) учиться. План был такой, я на месте осматриваюсь в течение месяца, а потом приезжает моя семья. Всего на поездку заложили полгода. Именно тогда я написал первую версию кодбатла на эрланге :)

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

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

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

Первое впечатление в Майами меня испугало. Слишком жарко, везде бегают ящерицы, вокруг какая-то разруха. К счастью последнее оказалось просто неудачным местом. Потом я переехал в город Sunny Isles Beach и прожил там еще 5 месяцев вместе с женой и дочкой. Кстати, таки заговорил на английском, пробил какой-то барьер.

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

Многие думают, что Майами это что-то типа Тая по климату. Вообще не так. Например два дня назад утром было 6 градусов. Зимой ночью бывает и минус. Климат в майаме такой что с октября по март погода как в Калифорнии. Днем тепло, дождей нет (они в сентябре начале октября), утром и вечером достаточно прохладно, вплоть до того, что приходится надевать джинсы и ветровку. Я так понимаю что пришла зима :) Со стороны это может показаться смешным, но когда проходит 3-4 года, ты начинаешь острее чувствовать такие переходы, хотя первые годы, я боялся конца лета, всегда было ощущение, что щас будет слякоть, тьма и противные дожди.

Да летом жарко, но лучше мы летом куда-нибудь уедем (как тут все и делают), зато остальное время кайф. Такие дела :)

Ссылки: Телеграм | Youtube | VK

Полезные ресурсы

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

1. https://github.com/Hexlet/ru-test-assignments - самый большой сборник тестовых заданий от разных компаний. Через них и на компании выйти легче и попрактиковаться не грех. Кстати, если там нет вашей компании, то пулреквест может это исправить :)

2. https://github.com/Hexlet/ru-projects-for-contributing - список опенсорсных проектов, в которых можно участвовать чтобы нарабатывать опыт. Речь идет не про библиотеки и какую-то мелочь, а про законченные проекты для конечных пользователей типа Code Basics.

3. https://github.com/Hexlet/ru-interview-questions - список вопросов с реальных собесов по куче направлений и уровню.

4. https://github.com/Hexlet/ru-local-communities - список локальных сообществ по городам. Сейчас это чаще онлайн, но есть и офлайн

5. https://codebattle.hexlet.io/ - один из самых больших и значимых проектов Хекслета. Кодбатл это место, где в реальном времени можно на скорость решать задачи с другими людьми, по принципу PvP. Проект пользуется популярностью по всему миру

Все это опенсорс, в котором можно и желательно участвовать :)

Ссылки: Телеграм | Youtube | VK

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

https://www.youtube.com/watch?v=ZaASNKUgHx8

Почему нужно использовать DTO

Data Transfer Object, термин, который для разработчиков на статических языках является чем-то самим разумеющимся, но вот остальные его могут не знать (даже если пользуются). Хотя в эпоху интеграций, фронтенд-бекенд, сервис-сервис, очереди, это крайне важная конструкция.

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

⁃ Модель => DTO => json/protobuf/sql/...
⁃ json/protobuf/sql/... => DTO => Модель

Нафига? Почему не сразу преобразовывать из, допустим, json в нашу модель или наоборот? Тем более во всех экосистемах есть механизмы, которые позволяют упаковывать любые объекты, задавая правила преобразования через метаданные, аннотации или еще как-то. Пример из Java:

@Entity
public class User {
    @Id
    private Long id;
    @JsonIgnore              // приходится скрывать
    private String passwordHash;
    @JsonProperty("created_at")
    private LocalDateTime createdAt;

    // getters/setters ...
}

var json = new ObjectMapper().writeValueAsString(dto);

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

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

DTO позволяют отделить представление от модели в коде, создавая по сути промежуточный слой. Имея его, вы можете независимо развивать свою модель и API для взаимодействия с ним. И да, это один из аспектов MVC, конкретно Model-View.

Готовые DTO гораздо легче чем модели конвертировать в типы на TS если у вас есть такая потребность. Например мы наши DTO (используем Alba), превращаем в типы TS с помощью готового инструмента (Typelizer). С моделями так легко не получится.

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

Но это только базовая история. Если мы еще подключаем инструменты генерации из sql (как в go) или openapi как везде, то те самые DTO создаются вообще автоматически на основе описаний.

Пример для sqlc.Библиотека на базе этого запроса и схемы базы генерирует DTO. Запрос:

INSERT INTO links (original_url, short_name)
VALUES (sqlc.arg(original_url), sqlc.arg(short_name))
RETURNING *;

DTO:

type CreateLinkParams struct {
 OriginalUrl string `json:"original_url"`
 ShortName   string `json:"short_name"`
}

Причем для update будет создана своя структура:

type UpdateLinkParams struct {
 OriginalUrl string `json:"original_url"`
 ShortName   string `json:"short_name"`
 ID          int64  `json:"id"`
}

Здесь отличается только id, но в реальных кейсах, отличий в создании или обновлении одной сущности обычно значительно больше, поэтому количество DTO тут становится еще больше.

DTO, кстати, должны быть имутабельны, иначе туда потечет логика

p.s. Вы сами пишите DTO или генерируете?

Ссылки: Телеграм | Youtube | VK

Ура, новый выпуск уже на канале. В этот раз парный лайвкодинг Vim версус Idea https://youtu.be/YST1h-MAAto?si=B2_Pf0zfCtC3s7V-