Человек я или пёс, вот в чём вопрос

Добрался я тут до одной из книг, которую мне в менторско-психологическом коммьюнити часто советовали:
«Не рычите на собаку».

Книга в основном о дрессировке животных, хотя многие из этих паттернов применимы и к людям.

Забавно осознавать, что в определённом разрезе и человек, и собака, и дельфин – в целом подчиняются одним и тем же заложенным шаблонам :)

Книга написана относительно легко, но идёт у меня довольно тяжело, как и любая профессиональная литература. Как я уже когда-то говорил – книги читать я не мастак. Но порой нужно.

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

Проблема в том, что если просто говорить человеку "так неправильно, переделовай", человек не поймёт, а что именно неправильно-то. И вот для этого умные дрессировщики придумали термин "подкрепления действий".

Если по-простому, то подкрепление – это способ показать человеку, что он что-то делает правильно или неправильно. Именно "делает", а не "сделал". Не после результата, а в процессе.

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

Вот "горячо" – это положительное подкрепление, а "холодно" – отрицательное.

Заметьте: вам не по щщам дали за неправильное место, а вовремя показали, что вы двигаетесь не в том направлении. В этом, кстати, разница отрицательного подкрепления и наказания.

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

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

А что у вас в обучении лучше работает? Ловили ли себя на сопротивлении, или на страхе перед наказанием, или на желании получить похвалу?

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

Ставь лайк если понимаешь, о чём я =)

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

Сейчас, например, я для этого либо смотрю Наследников, либо читаю "Нормандцы в Сицилии", либо гамаю в Корсаров.

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

Нравятся мне Корсары. Хоть они порой и вылетают, и графика там 12-летней давности, а всё же лучше игры с пиратской романтикой пока нет. Что меня, кстати, все эти 12 лет сильно удручает.

А пиратскую романтику с детства люблю. Зачитывался о том, как Генри Морган грабил Панаму, Франсуа Олонэ вырывал сердца, а Титч грабил корабли без единого выстрела чисто на бренде.

Почему мне пофиг на графику в Корсарах? Потому что когда я играю в Корсаров, я сам чувствую себя на борту пиратского корабля. А в моей голове графика отличная =)

Уход от реальности на какое-то время мне помогает освежить голову и с новым взглядом посмотреть на реальность.

А вы куда от реальности сбегаете?)

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

Взял я себе на месячное обучение ученицу.

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

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

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

Почему я вообще её взял на обучение, хотя не переношу «волков», и был практически уверен, что такие люди необучаемы? Потому что она искренне (насколько я смог распознать) хотела именно научиться делать задачи самой, а не просто сделать задачи любым способом, чтоб не выпнули с работы. И искренне не верила, что есть способ устроиться на работу другим способом, кроме как фейковать миддла, т.к. «джуны не нужны».

Ученица была в очень большом непрекращающемся стрессе. Оно и неудивительно. И сквозь этот стресс и страх мне надо было пробиться и постараться хоть чему-то научить.

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

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

Доволен ли я этим опытом? Вполне. Пока по моим границам и контракту не прошлись катком, я не так хорошо их ощущал. И теперь я – Саша Белый Гендальф Белый, и моё менторское кунг-фу стало сильнее.

Повторил бы я такой опыт? Да ну его нахер, вы чо, долбанулись. Я столько времени, как на эту ученицу, трачу обычно на троих. И ещё и чувствовал себя высосанным после каждого созвона (обычно я наоборот на подъёме после занятий).

Если честно – очень переживаю, что от меня щас отпишутся люди по двум причинам:
1) ах ты падла волков поддерживаешь (а я не поддерживаю)
2) ах ты падла ничему не научил за месяц

Задумался тут о том, что за 4 года с 2020 до 2024 мы познали:

1. Мир до ковида
2. Мир во время ковида
3. Мир после ковида, но до СВО
4. Мир во время СВО

И это всё 4 разных мира))

По одному миру в год в среднем. Норм такой темп. Мало какому поколению сломали столько шаблонов, сколько нам. А если учесть, что всё это было при максимально лёгком и быстром обмене информацией между разными точками планеты, то мы – точно уникальное поколение.

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

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

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

Так, ребятки.

По просьбам подписчиков, скоро начнётся цикл лекций постов про автотесты.

Буду раскрывать вопросы:

– какие автотесты бывают, чем отличаются
– зачем и кому они нужны или не нужны, плюсы-минусы
– практические советы по юнит-тестам и UI-тестам

Если интересует что-то ещё – накидывайте в комментарии👇.

Stay tuned.

Зачем мне писать автотесты?

1️⃣ Экономия времени и сил, улучшение прогнозируемости

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

А я ж хочу накодить фичу побыстрее и спокойно отправить в прод.

Да и при рефакторингах мне куда спокойнее, если вижу, что автотесты при рефакторинге не сломались. Значит либо я всё хорошо порефакторил, либо тесты плохо написали, а с меня взятки гладки =)

Шутка. Сам тесты поломал – сам иди и чини, умник.

Если вы вдруг подумали, что экономия времени будет заметна сразу – хрен там. Это вы увидите только после того, как написанные тесты начнут из раза в раз переиспользоваться. А в первое время будут повышенные затраты времени на написание тестов и на существующий код и на новые фичи. Чем дальше, тем больше будет заметно снижение нагрузки на QA.

Да и не всё можно автоматизировать. Вряд ли у вас получится полностью автоматизировать тестирование какого-то флоу или фичи. И часть нагрузки все равно останется на ручных тестировщиках. Задача автотестов не в том, чтобы полностью снять нагрузку с QA, задача – снизить количество итераций, желательно до одной =).

2️⃣ Улучшение стабильности, уменьшение влияния человеческого фактора

Автотесты один раз написал и наслаждаешься, а QA-шеров корми, пои, спать уложи. Автотесты не устают и не теряют фокус. И не ноют "да вы охренели все задачи за день до конца спринта в тестирование отправлять, я вам чё, осьминог?". Плюс, когда пишешь автотесты — их видят и ревьюят другие, в отличие от ручных тестов, на которых можно схалявить или протупить.

А ещё автотесты, если они долгие, можно запускать в нерабочее время. И за овертайм тестировщику доплачивать не надо, удобно =)

3️⃣ Увеличение гибкости и управляемости

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

4️⃣ Улучшение кода и его понятности

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

5️⃣ Улучшение восприятия компании

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

Какие автотесты вообще бывают?

Часть 1: Unit-тесты

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

Юнит-тесты изолированы в рамках одного слоя и его же они собсна и проверяют; все зависимости от других слоёв/модулей подменяются, чтобы они не влияли на результат проверки. Чтоб не было такого: у меня упал слой 1, потому что я накосячил в слое 2. Если слой 1 покрыт юнит-тестами и они упали – значит, косяк именно в нём, иди проверяй, чё ты там нарефакторил.

Юнит-тест проверяет “единицу поведения“ - это может быть, например, юзкейс, или метод репозитория, или класс утилит. Покрывать юнит-тестами можно или только публичный контракт, или все методы класса, включая приватные – тут кому как нравится.
Я предпочитаю не лезть в дела класса и проверять только контракт, а как он реализуется внутри – не моё собачье дело.

Классическая структура юнит-теста:
given → when → then

Given – всё, что нужно для вызова тестируемого метода. Здесь будет создание всех замоканных данных, необходимых для запуска реального метода, который мы тестируем.

When – вызов реального тестируемого метода.

Then – проверка результата вызова: ассёрты. Можно делать несколько ассёртов в тесте, если результат вызова тестируемого метода к этому располагает.

Важно стараться протестировать ассёртами и тестами все развилки логики if/else. И ни в коем случае не стоит делать if/else в самом юнит-тесте, поскольку иначе при его прохождении/не прохождении будут появляться неоднозначности.
Любое падение юнит-теста должно однозначно свидетельствовать о конкретной проблеме, безо всяких развилок "ну тут или это пошло не так, или вон то".

Юнит-тесты исполняются быстро – из-за того, что они изолированные и у них нет никаких тяжеловесных зависимостей.

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

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

Заметил, что контентные (обучающие) посты набирают мало просмотров и лайков, а не контентные (эмоции, рассуждения) в 2-3 раза больше.

При этом на контентные я трачу в разы больше времени и сил.

Забавная фигня. Я, когда начинал канал, думал, что контент людям важнее =)

И это при том, что я сюда левых людей не набираю, в основном тут только ЦА: начинающие разрабы.

А оно вона как. Интересно, интересно.

Короче я понял))

Расскажите тогда: о чём хотелось бы послушать за жизу? Буду разбавлять контентные посты жизовыми)

Какие автотесты вообще бывают?

Часть 2: Интеграционные тесты

Нужны для проверки правильного взаимодействия разных слоёв/модулей. К примеру, можно протестировать связку Repository → UseCase, или связку Repository → UseCase → Presenter → View. Все остальные слои/модули, которые не проверяются в этом интеграционном тесте, подменяются.

Важно понимать, что интеграционный тест не тестирует UI - этим занимаются UI-тесты, но при этом, в отличие от Unit-тестов, он может исполняться в классах, зависящих от платформы.

В случае android, в этом помогает Roboelectric - быстрый симулятор android на JVM и собственными заглушками (shadows) для классов из android. Также через Roboelectric можно для каждого теста указать target sdk и проводить многие другие манипуляции с платформой.

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

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

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

Какие автотесты вообще бывают?

Часть 3: UI-тесты

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

В UI-тестах мы не вызываем методы приложения напрямую, мы имитируем действия пользователя с интерфейсом приложения.
То есть в этих тестах мы реально кликаем по нашим кнопкам.

Отличия от Unit/интеграционных тестов:

1️⃣ Им для запуска необходим эмулятор/реальное устройство.

2️⃣ Проходят долго. В зависимости от размера приложения, количества тестов и железа, где всё это запускается, прохождение всех UI-тестов может занимать как минуты, так часы и даже дни.

3️⃣ Поскольку UI-тесты — попытка удержать баланс между приближением тестов к реальности и автоматизацией процесса, они довольно хрупкие: их выполнение не гарантируется, из-за того, что появляется зависимость от реальной платформы, которая не всегда предсказуема.

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

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

4️⃣ UI-тест может содержать много шагов и проверок. Их сложно писать и читать. Будет много боли и мата. А настройка CI для UI-тестов у меня когда-то заняла почти год, там столько подводных камней, что из них крепость можно построить.

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

Какие автотесты вообще бывают?

Часть 4: скриншот-тесты и end-to-end-тесты

1️⃣ Скриншот-тесты

Я их сам не использовал, знаю понаслышке, и могу где-то ошибаться. Но у меня понимание такое:

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

Скорее всего, эти скриншоты можно и автоматически нагенерить, про это я не в курсе. Если знаете – напишите в комментах.

И потом приложение делает новые скриншоты на тестируемой ветке и сравнивает со старыми. Если они не совпадают – значит тест завалился.

Грубо говоря, если при клике на кнопку "Покажи экран с собакой" у тебя показался экран с кошкой, или с наполовину уехавшей вниз собакой, или с собакой, но не с той, что на базовом скрине – то тест завалится.

Здесь, кажется, есть куча подводных камней типа:

"а если экран маленький, и контент не поместился, и просто уехал чуть ниже, а на базовом скрине был экран побольше – чё делать?"

или

"а если у меня динамический контент (например, карта, на которой могут исчезать или появляться строения и меняться их названия), то скрины будут непредсказуемо меняться и фейлиться"

Понятно, что всё это решаемо, и там вроде можно сказать "не смотри на эту часть скрина, она динамическая", но не уверен, насколько это всё будет удобно и стабильно.

Если у вас есть опыт скриншот-тестов – пишите в комментариях, нравятся ли они вам, и какие есть плюсы и минусы.

2️⃣ End-to-end (e2e)-тесты

На самом деле некорректно отделять их от остальных тестов, потому что это концепция другой категории, не противоречащая остальным. То есть, UI-тесты могут быть и e2e и не e2e.

End-to-end-тесты – означает, что мы в тестах ничего не мокаем. Проверяем на реальном сервере (понятно, что вряд ли это будет продовый сервер, но это будет или реальный тестовый сервер, на котором вы обычно тестовые сборки гоняете, или отдельное апи / сервер специально под e2e-тесты).

То есть, e2e UI-тесты максимально приближены к реальности. Никаких замоканных классов, методов, серверов. Всё работает так, как работает у реального ручного тестировщика.

Единственный момент – запускать ли их на эмуляторе или на реальном устройстве / ферме устройств. Первый вариант дешевле, но с ним много гемора, т.к. эмуляторы – неудобная и нестабильная штука, постоянно вставляющая вам палки в колёса. Зато на нём можно программно подменять версии апи и устройства. А на ферме что есть, то и есть – зато устройства реальные.

В следующих постах немного коснусь библиотек и фреймворков для автотестов. Не переключайтесь.

Привет, друзья!
Давно я не делился успехами своих учеников на менторстве.
На скриншоте – отзыв одного из моих учеников, с которым мы работали 3 месяца.

Если вкратце: пришёл тимлид из сферы поддержки, захотел стать разрабом. Сначала сам пытался, но понял, что слишком долго и больно.

За 3 месяца мы:

– освоили котлин с зачатков знаний до необходимого для android-разработчика уровня

– освоили основу android-платформы: построение иерархии активити / фрагментов, передачу данных между ними, фоновую работу (корутины), работу с бэкендом и парсинг, отображение списков

Если хотите, чтобы я и вас поставил на правильные рельсы, объяснил, в какую сторону двигаться и помог с этим – записывайтесь на менторство @ilia_a_popov

@andrdevnotes | androidmentor.ru

Когда мы с женой едем куда-то отдыхать, у нас есть два типа путешествий.

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

Второе – по России / СНГ, где меня на русском поймут. И вот в такие поездки, наоборот, я люблю ездить с компанией друзей: так получается веселее, и я лучше отдыхаю, чем если бы мы поехали вдвоём.

Такой вот путешественнический дуализм. А у вас как?

Lateinit vs by lazy

В чём разница инициализации переменных с помощью lateinit и by lazy?

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

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

Иначе, когда при создании класса ты полезешь инициализировать сразу все 10 тяжёлых переменных в UI-потоке, у пользователя всё будет тормозить. А нам этого не хочется.

lateinit тебе ничего не гарантирует, lateinit - это просто "компилятор отвали, сам разберусь"

lateinit при попытке обращения к переменной, которую ты не инициализировал, свалится с экспешном.

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

Поэтому лейтиниты используются чаще всего для инжектов DI или для вьюбайндинга. Но во втором случае все равно может быть опасно, андроид – штука не всегда предсказуемая. Захочет кильнуть тебе процесс, или doze mode какой-нибудь настанет, что-то убьётся и криво попытается пересоздасться системой, жизненный цикл пойдёт по кривому пути и привет крэш =)

А вот by lazy использовать – это на здоровье. Только сильно тоже не увлекайтесь, а то читаемость кода может стать слишком плохой, и появиться неявные зависимости при инициализации разных переменных.

Может, знаете ещё минусы поздних и отложенных инициализаций?