Третья часть разбора чистого кода. В этот раз про обработку ошибок и исключения 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-

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

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

Например я обожаю удалять код, обновлять зависимости, использовать готовые решения вместо самопальных и прокачиваться в vim. Мне нравится проектировать предметную область. я с удовольствием пишу тесты (там где хороший сетап) и занимаюсь инфраструктурой. Одновременно с этим я не люблю задачи на оптимизации, у меня никогда не возникает желания залезть куда-то в кишки и попробовать переписать на go/rust/c/асемблер. Да если надо я буду оптимизировать, но для этого должна быть причина и отсутствие тех кому бы я мог это делегировать :) Отдельно, много лет назад я обнаружил в себе любовь к фронтенду. Причем как верстальщик я скорее копипастер, но при этом обожаю собирать интерфейсы из готовых элементов типа bootstrap или, сейчас, mantine.

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

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

А от чего прет (или не прет) вас?

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

В сегодняшнем выпуске разбираю главу "Модульные тесты" книги "Чистый Код" Мартина.
https://youtube.com/watch?v=DqgAqCpYsbs

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

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

В интернете кто-то не прав

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

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

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

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

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

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

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

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

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

Помимо того, чтобы не принимать на себя сказанное другими, я придерживаюсь следующего принципа:

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

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

p.s. А вы попадали в такие перепалки? Какое было послевкусие?

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

Почему провалился BDD?

Программирование управляемое поведением когда-то захватило умы разработчиков и об этом говорили буквально на каждом углу. Для поддержания этой идеи появился целый пласт инструментов, использовать которые было просто обязательно для любого прогрессивного разработчика. Активно пошли в мир тестовые подходы и фреймворки типа cucumber и rspec, отовсюду звучало Given-When-Then. А потом раз и все это исчезло как и появилось. Что случилось?

Идея BDD не нова, кейсы, примеры, сценарии существовали десятилетиями: Use Cases (1990-е), User Stories (начало 2000-х), Acceptance Criteria, примерно весь классический системный анализ.

BDD, по сути, внес такую формулировку:

⁃ Пример и есть требование.
⁃ Примеры и есть документация.
⁃ Примеры и есть тесты.

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

Feature: User login

  Scenario: Login fails with invalid password
    Given a registered user exists
    And I am on the login page
    When I enter "[email protected]" into the "Email" field
    And I enter "wrong-password" into the "Password" field
    And I click the "Login" button
    Then I should see "Invalid email or password"
    And I should remain on the login page

Читается? Да. Понимает ли это бизнес? Возможно, в первый день.
Но это только верхушка айсберга. Реальная работа происходит в другом месте - в описаниях шагов, так называемых step definitions, которые нужно писать отдельно:

Given("a registered user exists") do
  @user = User.create!(
    email: "[email protected]",
    password: "correct-password"
  )
end

Given("I am on the login page") do
  visit "/login"
end

When('I enter "{string}" into the "{string}" field') do |value, field|
  fill_in field, with: value
end

When('I click the "{string}" button') do |button|
  click_button(button)
end

Then('I should see "{string}"') do |text|
  expect(page).to have_content(text)
end

Then("I should remain on the login page") do
  expect(page).to have_current_path("/login")
end

И вот тут начинается жопа. Этот слой быстро разрастается до сотен методов (даже для простых кейсов), которые должны быть одновременно “универсальными”, “переиспользуемыми” и “человеко-читаемыми”. На практике это приводит к бесконечному количеству абстракций вида “When I click the ‘Login’ button” и “Then I should see ‘Success’”, которые не помогают ни бизнесу, ни разработчикам, ни тестировщикам. Стейкхолдеры даже не открывали эти сценарии.

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

BDD провалился, потому что его реальная ценность была в коммуникации, а его реальная практика стала про автоматизированные UI-тесты. Несмотря на это, в те годы родилось много инструментов, элементы которых до сих пор живут в разных экосистемах. Например те же матчеры отлично прижились в vitest/jest, в ruby мире по прежнему популярен rspec.

p.s. Хорошее видео по теме https://www.youtube.com/watch?v=Bq_oz7nCNUA

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

Неправильно называть рефакторингом переход с синхрона на асинхрон, это уже как минимум другой контракт, скорее всего и Use Case поменяется, добавятся очереди и бог его знает что.. Это уже другая по сути фича. А рефакторинг это же когда поведение программы (класса) не меняется и даже интерфейсы не меняются. Как у метода sort на вход был массив, так и остаётся, только вместо пузырька стали merge-sort использовать

Такой коммент оставили к видео про тесты youtube.com/watch?v=DqgAqCpYsbs Тут у меня приподнялась бровь, потому что у человека (судя по другим комментариям и лайкам) восприятие рефакторинга прочно ассоциируется с внутренними модулями. А раз есть такое восприятие, то не грех это проговорить.

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

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

А что обычно вы имеете ввиду когда говорите что делаете рефакторинг или тут нужен рефакторинг?

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