Давайте подытожим, что у нас со снепшотами. Соберем все плюсы и минусы:

✅ Плюсы:
👉 Нет эмуляторов – довольно жирный плюс
👉 Легко написать проверку вместо вызова кучи функций в espresso
👉 Позволяет отследить баги SDK

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

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

👉 Поехал текст на кнопке, но сама кнопка работает
👉 Запрос отправляет не на тот endpoint, из-за чего у клиента не работает оплата

Знатоки, внимание вопрос, за какой из этих багов форма вашего стула станет похожа на бутылку?

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

Да, снепшот тесты отлично проверяют внешний вид приложения, а толку то от этого? В тестах важно чтобы не было регресса в логике. Вы тут можете возразить, ведь в таких тестах можно ходить в сеть. Если под капотом снепшотов нет robolecric, вы сходите лесом, а не в сеть. Что если замокать network и проверять на фейковых данных? В этом случае вы проверите как ваше приложение работает в мире феечек с единорогами.

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

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

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

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

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

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

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

Смотрите, есть два основных подхода в архитектуре.

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

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

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

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

Если соединить эти два подхода, то ведь получается, что мы обречены писать говнокод, подумал я, не может же быть все так плохо. Потом вспоминаешь всё современное ПО, ах да, точно…

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

Компания AliExpress Russia, собес на позицию Android-разработчика. Было несколько этапов, насколько помню, три: скрининг, Android-секция и техническая. Скрининг и Android-секцию я слабо помню, видимо, вопросы были максимально банальные в стиле: "расскажите про все основные компоненты". Техническая сессия оказалась алгоритмической.

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

Вторым вопросом был flatten array. Нужно было написать кастомный iterator, который из такого списка [1, 2, 3, [4, [5, 6]]], делает такой [1, 2, 3, 4, 5, 6]. Задача была прикольная, с натяжкой можно представить, где такое можно применить.

Знаете, что было самое забавное в этих собесах? Собес в AliExpress, по ощущениям, был самым сложным по сравнению с другими, а оффер в итоге был самый маленький…

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

Знаете, я тут подумал и кажется осознал:

👉 покрывать все интерфейсами это единственно верное решение, чтобы ваша кодовая база не развалилась.
👉 npm и gradle это лучшие системы сборки, которые существуют на рынке.
👉 снепшоты это отличная замена UI тестам, в целом можно только их использовать!
👉 llm от лукавого и нужно писать весь код самостоятельно
👉 чтобы быть востребованным на рынке важно, чтобы у вас был красивый github

UPD: лучшая тема в IDE – светлая

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

Условия задачи: есть связный список, и нужно понять, есть ли в нем цикл. Цикл — это когда у нас последний элемент списка ссылается не на null, а на какой-то из элементов этого самого списка, короче, смотрите картинку.

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

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

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

👉 быстрый указатель упрется в null – цикла нет
👉 они встретятся на каком-то из элементов – цикл есть

Это собственно все... Код решения на python:

class ListNode:
    def __init__(self, x, next):
        self.val = x
        self.next = next
        
def detect_cycle(head: ListNode) -> bool:
    fast = slow = head
    circle_detected = False
    while fast and fast.next:
        slow = slow.next
        fast = fast.next.next
        if slow == fast:
            circle_detected = True
            break
    return circle_detected

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

Удивительно, но даже на решении базовой задачи умудрились придраться. Смотрите, было несколько комментов касательно решения с использованием set.

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

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

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

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

Вот, я все ждал когда уже начнут появлятся первые новости о гонке вооружений в области собеседований.

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

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

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

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

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

Работает следующая формула. В начале мы рассчитываем срок, исходя из нашего прошлого, на глазок. Затем мы умножаем это число на π и добавляем две недели. Почему на π, спросите вы? Исходим из того, что мы двигаемся от начала проекта к его концу.

Оптимистичное мышление подсказывает нам, что мы двигаемся по прямой. Однако в реальности, даже в лучшем случае, мы будем двигаться по окружности из-за разного рода проблем. Длина окружности у нас — это 2πr. Нам нужно пройти половину окружности, значит, πr, где r — это срок, который мы насчитали в начале.

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

UPD: меня в комментах ткнули носом что формула: πr/2 - ведь срок у нас это не радиус а диаметр

Наконец-то опубликовали мою статью про robolectric, немного вернулся к темам android.

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

Благо пока канал мой не трогают. Короче вот статья, старался писать не душно https://habr.com/ru/companies/tbank/articles/902180/

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

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

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

• 💰 Сохраняет стоимость внедрения фичей. Бизнесу важно, чтобы стоимость внедрения новых фичей, которые по сложности не отличаются от предыдущих, не росла в цене. Если в начале проекта стоимость внедрения фичи X, а через полгода 2X — это проёб архитектуры, который реально может сильно ударить.

• 👥 Параллелизация работы. Представьте, что на проекте один разработчик, и у него весь проект в нескольких основных файлах. Пока он один, он, возможно, даже хорошо справляется и делает всё в срок. Однако с ростом бизнеса вам нужно открывать новые направления, и одного разраба уже не хватит. Вам нужно нанять ещё 2-3. В этом случае параллелизация работы практически невозможна, вы умрёте в конфликтах. Поэтому важная часть архитектуры в том, что она должна обеспечивать разделение работы.

• 🧪 Тестирование. Это может проявляться на уровне кода, когда вы забили на DI, и нельзя никак подменить зависимость для тестов, и никак нельзя протестировать отдельную фичу, не задев ничего другого. Также может проявляться на уровне всей системы, когда у вас нет возможности поменять конфиги для QA контура, и тестировать можно исключительно на проде — это, кстати, проблема как бэка, так и фронта.

• 🚀 Развёртывание. Не актуальный пункт для мобилок, но очень важный для бэка. Архитектура должна помогать в поднятии новой версии приложения. Если у вас приложение спроектировано так, что может работать только один инстанс и при этом много пользователей, то у вас проблемы. Ведь про zero downtime можно забыть.

• 🔄 Деградация. Хорошая архитектура должна отвечать на вопрос: "А что будет, если у нас отъебнёт база?" или, если мы говорим про мобилку: "Что будет, если инет пропадёт?"

• 👁 Observability. Это уже больше про SRE, однако каждому важно понимать, что архитектура должна давать возможность трекать состояние каждого элемента системы, чтобы быстро понимать, где именно проблема.

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

Почему все так хейтят Сбер последнее время? В некоторых каналах заметил тенденцию, что HR к работникам Сбера относятся с таким же пренебрежением, как Яндекс к ребятам, которые долго сидели на php.

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

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

Основная идея, вокруг которой строится успешный продукт, — это взять одну проблему, сосредоточиться только на ней и решить её лучше всех конкурентов. Яркий пример — Telegram, который зашёл на рынок мессенджеров и вытеснил всех просто потому, что был удобнее и быстрее.

Однако после того, как компания разрастается, все начинают добавлять фичи, о которых никто не просил. Тот же Telegram в какой-то момент сказал: "Я теперь не просто мессенджер — я теперь социальная сеть нахуй, держи сторисы, ну а ещё я криптокошелёк, звезды брать будешь?".

Среди таких компаний верх неадекватности — казахстанские банки. В Казахстане два основных крупных банка — это Kaspi и Halyk. Открыв приложения этих банков, ты обнаружишь, что это не банки с функцией маркетплейса, а маркетплейсы с функцией банка. Причём доходит до абсурда — в рандомный момент тебе приходит пуш от банка с текстом: "Брат, корм для кошек будешь брать?"

Это пост без какой-то умной мысли, просто крик души.

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

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

👉 Скопление ошибок, делал про него отдельный пост. Когда фиксите баг, проверяйте соседние фичи, очень вероятно, что в них вы также обнаружите баг.

👉 Когда делаете МР, пробегайтесь по нему глазами, как будто не вы его делали. Часто на этом этапе можно найти пару косяков.

👉 Часто лучший дебаг — это сходить прогуляться на воздухе минут 20. У этого метода даже есть научная база.

👉 Три гвоздя. Сразу предупрежу, совет сомнительный, и применяйте его аккуратно. Бывало у вас такое, что просят сделать мелкую задачу, а потом оказывается, что она уже не нужна? Совет помогает защититься от таких задач. Вот вас просят сделать какую-то штуку, вы отвечаете: "Да, конечно, сейчас сделаем" и забиваете на нее, это был первый гвоздь. Потом вас спрашивают про статус задачи, это уже второй гвоздь, тут мы все еще не трогаем задачу. Затем нас торопят уже в третий раз, это третий гвоздь, и вот тут мы уже начинаем ее делать, т.к., скорее всего, это нужная задача.

Меня в комментариях поправили, что правильнее называть ПР (pull request) а не МР (merge request). Смотрите, вот в чем разница. Если у вашей компании дохуя денег и она рот топтала хостить у себя git, то у вас ПРы. Если же у компании мало денег или она хочет хостить git на своих серверах то у вас МРы.

Compose для iOS перестал быть бета-версией. Для тех, кто не в теме: Compose — это нативный React в мире Android.

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

Compose даже на Android не всегда работает корректно и по многим параметрам всё ещё уступает View по производительности. Наша команда по перформансу сделала дашборды с метриками отрисовки по каждому экрану, и по ним видно, что экраны на Compose часто отрисовываются дольше, чем аналогичные на View. Оно и ожидаемо, View разрабы Google оптимизировали лет 10, а Compose еще очень молодая технология.

Compose как и flutter использует Skia для отрисовки. Это значит, что по производительности он будет уступать нативным технологиям, которые напрямую работают с Metal, а не через прослойку в виде Skia.

Посмотрим что из этого получится, но как мне кажется нативный UI все равно никуда не уйдет. Как минимум потому что Apple оптимизирует все свои решение именно под Swift UI и UIKit. Какое бы крутое не было бы кроссплатформенное решение, оно все равно не приблизится к нативному.

Плюс это дикий риск для компании, если у тебя приложение на Swift UI, то ты быстрой найдешь крутых разрабов. Если же ты завязался на Kotlin, ну удачи найти разрабов именно под iOS специфику.

Как я попал в команду инфраструктуры?

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

👉 самими пайплайнами;
👉 автоматизацией проверок;
👉 оптимизацией Gradle (рот его еб%#*);
👉 автоматизациями, связанными с релизами;
👉 разработкой подходов к тестированию;
👉 иногда — изменениями в архитектуре проекта;
👉 очень иногда — патчами кода раннеров для тестов.

Помимо этого, периодически появляются идеи в духе "а давайте подключим нейронку к логам пайплайна и посмотрим, что будет". Поэтому это уже не совсем Android-разработка, но всё ещё где-то рядом. В этой команде широкий спектр задач, которыми можно заниматься, но есть и минус — у тебя нет чётких требований. К тебе приходит тимлид и говорит: "Сделай заебись! Требований нет, чёткого плана тоже. Всё, давай."

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

Это сыграло со мной злую шутку. Заниматься просто Android-разработкой в ближайшее время я уже не смогу — там всё стало слишком скучно. При этом полностью переключиться на бэкенд я пока тоже не готов. Вот и застрял между молотом и наковальней.