Crash Budget
Тесты — лишь инструмент. Не стоит думать, что любой тест сразу улучшает метрики качества. Плохой тест даже хуже отсутствующего. Он выполняется медленнее ручных или еще хуже дает неправильную инфу о причинах.
В авито есть множество метрик, которые отвечают за качество. Все они работают исключительно в рамках своего юнита. Подробнее можно почитать тут. Но есть проблема, что отсутствует сквозная объективная метрика стабильности приложения на основе данных пользователей, позволяющая отслеживать состояние и принимать решения. Поэтому придумана к уже существующим метрикам добавить сквозную автоматизированную метрику Crash Budget.
Метрика будет учитывать влияние каждого отдельного юнита на Crash-free users и подсвечивать проблемы.
Начальный порог на 1 юнит - 0.0179%
формула = целевой crash-free/число юнитов
Мониторинг работает автоматически + уведомляет юниты в случае привышения бюджета по крешам. В случае игнорирования юниту выдаются санкции.
Crash-free users — процент пользователей, у которых не было крэшей в приложении за выбранный период.
Crash Budget — допустимый процент крэшей у пользователей в расчете на 1 юнит за выбранный период.
Таким образом команда задумывается не просто о написании тестов, как об отчетности. Она сплочена общей проблемой и использует инструменты тестов, как повышение стабильности этих показателей.
Тесты — лишь инструмент. Не стоит думать, что любой тест сразу улучшает метрики качества. Плохой тест даже хуже отсутствующего. Он выполняется медленнее ручных или еще хуже дает неправильную инфу о причинах.
В авито есть множество метрик, которые отвечают за качество. Все они работают исключительно в рамках своего юнита. Подробнее можно почитать тут. Но есть проблема, что отсутствует сквозная объективная метрика стабильности приложения на основе данных пользователей, позволяющая отслеживать состояние и принимать решения. Поэтому придумана к уже существующим метрикам добавить сквозную автоматизированную метрику Crash Budget.
Метрика будет учитывать влияние каждого отдельного юнита на Crash-free users и подсвечивать проблемы.
Начальный порог на 1 юнит - 0.0179%
формула = целевой crash-free/число юнитов
Мониторинг работает автоматически + уведомляет юниты в случае привышения бюджета по крешам. В случае игнорирования юниту выдаются санкции.
Crash-free users — процент пользователей, у которых не было крэшей в приложении за выбранный период.
Crash Budget — допустимый процент крэшей у пользователей в расчете на 1 юнит за выбранный период.
Таким образом команда задумывается не просто о написании тестов, как об отчетности. Она сплочена общей проблемой и использует инструменты тестов, как повышение стабильности этих показателей.
👍4🔥1
😁4
Property Observers
🟢 lvl: jun
В Swift есть два типа свойств:
⚪ stored properties — это константа или переменная, которая хранится как часть экземпляра определенного класса или структуры. Сохраняемые свойства могут быть либо переменными хранимыми свойствами
⚫️ computed properties — выполняют вычисления на основе этого состояния
ℹ️ Когда вы объявляете stored property, у вас есть возможность определить наблюдателей свойств с блоками кода, которые будут выполняться при установке свойства. Наблюдатель willSet запускается до сохранения нового значения, а наблюдатель didSet запускается после. И они выполняются независимо от того, равно ли старое значение новому значению.
Иногда это удобно для валидации поля перед отправкой (рис. 3).
https://nshipster.com/swift-property-observers/
🟢 lvl: jun
В Swift есть два типа свойств:
⚪ stored properties — это константа или переменная, которая хранится как часть экземпляра определенного класса или структуры. Сохраняемые свойства могут быть либо переменными хранимыми свойствами
⚫️ computed properties — выполняют вычисления на основе этого состояния
ℹ️ Когда вы объявляете stored property, у вас есть возможность определить наблюдателей свойств с блоками кода, которые будут выполняться при установке свойства. Наблюдатель willSet запускается до сохранения нового значения, а наблюдатель didSet запускается после. И они выполняются независимо от того, равно ли старое значение новому значению.
Иногда это удобно для валидации поля перед отправкой (рис. 3).
https://nshipster.com/swift-property-observers/
👍7
"Грокаем алгоритмы"
Вода: 0%
Полезность: 4.5 из 5*
Думал ли писать микро-рецензию на most popular книгу про алгоритмы... Кажется каждый, кто начинал разбираться в теме всеми путями выходил на нее. Ютуберы, статьи, коллеги. Ее советует каждый. Особенно фронтендеры, которые с алгоритмами работают реже всего и форма подачи других книг — непривычна
Лучше книги для старта нет. Здесь нет математики и доказательств, что отпугивают изнеженных мобильщиков. Вместо них бесконечность аналогий из жизни, дабы упростить усвоение пищи.
Напоминаю, что все книги тут
Вода: 0%
Полезность: 4.5 из 5*
Думал ли писать микро-рецензию на most popular книгу про алгоритмы... Кажется каждый, кто начинал разбираться в теме всеми путями выходил на нее. Ютуберы, статьи, коллеги. Ее советует каждый. Особенно фронтендеры, которые с алгоритмами работают реже всего и форма подачи других книг — непривычна
Лучше книги для старта нет. Здесь нет математики и доказательств, что отпугивают изнеженных мобильщиков. Вместо них бесконечность аналогий из жизни, дабы упростить усвоение пищи.
Напоминаю, что все книги тут
👍12
Зачем мне нужны юнит тесты?
Как я уже говорил, у UI тестов есть плюсы:
- Их легче писать.
- Они быстрее дают обратную связь.
- они документируют пользовательские сценарии
Но есть и минусы:
- в 90% случаев UI тестами покрывается только 1 успешный кейс и забывается про кучу корнеркейсов. Для всех их дорого писать и они будут очень долго выполняться.
- они детектят только факт падения, но не дают причины
- Не знают о деталях работы сервисов, холдеров и тп за рамками UI
В итоге получается, что мы просто экономим на ручном тесте с сообщением "иди посмотри у тебя тест упал".
Как мне помогают юнит тесты? Сейчас я сделал фичу, которая выйдет в релиз в марте 2023 года. За 6 месяцев мне нужно как-то убедиться, что фича не упадет на проде и доедет в рабочем состоянии. Да, UI тесты и мок-данные могут обезопасить и как-то сэкономить время на детект.
Но когда мне придет факт о сломанном проде мне нужно время, чтобы освежить память и найти ответы на вопрос "А что я делал пол года назад и как это должно быть в 9 из 10 других случаях, которые не покрыли UI тесты?".
Я бы мог задокументировать и описать в каком-нибудь конфлюенсе, но есть риск, что он устареет. Поэтому, на уровне атомов, юнит тесты могут мне быстрее погрузиться в детали актуального прода.
Также они не дадут накопиться снежному кому недоработок, которые будут появляться из-за аффекта зависимых сервисов.
Как я уже говорил, у UI тестов есть плюсы:
- Их легче писать.
- Они быстрее дают обратную связь.
- они документируют пользовательские сценарии
Но есть и минусы:
- в 90% случаев UI тестами покрывается только 1 успешный кейс и забывается про кучу корнеркейсов. Для всех их дорого писать и они будут очень долго выполняться.
- они детектят только факт падения, но не дают причины
- Не знают о деталях работы сервисов, холдеров и тп за рамками UI
В итоге получается, что мы просто экономим на ручном тесте с сообщением "иди посмотри у тебя тест упал".
Как мне помогают юнит тесты? Сейчас я сделал фичу, которая выйдет в релиз в марте 2023 года. За 6 месяцев мне нужно как-то убедиться, что фича не упадет на проде и доедет в рабочем состоянии. Да, UI тесты и мок-данные могут обезопасить и как-то сэкономить время на детект.
Но когда мне придет факт о сломанном проде мне нужно время, чтобы освежить память и найти ответы на вопрос "А что я делал пол года назад и как это должно быть в 9 из 10 других случаях, которые не покрыли UI тесты?".
Я бы мог задокументировать и описать в каком-нибудь конфлюенсе, но есть риск, что он устареет. Поэтому, на уровне атомов, юнит тесты могут мне быстрее погрузиться в детали актуального прода.
Также они не дадут накопиться снежному кому недоработок, которые будут появляться из-за аффекта зависимых сервисов.
👍8
Forwarded from iOS Dev
Насколько необходимы основы программирования, та самая база?
📖 Бруно Роша, разработчик в Spotify, рассуждает в своей статье о необходимости алгоритмов, презирании этой темы в сообществе и проводит параллели с развитием музыканта.
Я постарался выделить основные моменты, и позволил себе добавить некоторые комментарии.
Проблема в том, что сообщество часто направляет ненависть к подобным собеседованиям не по назначению. Негатив вокруг этого формата интервью стал настолько велик, что теперь часто можно встретить людей, испытывающих неприязнь к самой теории, которая не имеет ничего общего с непонятными головомками в программировании.
Это мнение стало настолько популярным, что теперь практически невозможно упомянуть концепцию программирования на абстрактном уровне без того, чтобы кто-то немедленно не начал холивар о практике проведения интервью. А это вредит в том числе и индивидуальной карьере инженеров, которым говорят держаться подальше от этих знаний по причинам, не поддающимся логике.
Поднимаются важные вопросы
🔴 Теория не отражает того, что человек будет делать на самом деле в своей работе.
🔴 Знание теории не является показателем мастерства человека в данной практической роли.
🔴 Теория вообще бессмысленна. Зачем разработчику iOS знать, что такое граф?
Всё это создает у людей впечатление, что основы бесполезны, в то время как на самом деле они используют их постоянно!
Я не могу передать, сколько раз я слышал, как разработчик iOS говорил: "Я могу с уверенностью сказать, что никогда в своей работе мне не приходилось использовать граф", а затем радостно рассказывал о чем-то интересном, с чем они работали, используя иерархии UIView. Это одно и то же!
Объекты, которые могут соединяться друг с другом с целью создания единой связной карты элементов, - это буквальное определение графа, поэтому они не только знают, что такое граф, но и используют его с самого первого дня работы в качестве разработчика!
🟢 Графы/деревья: UIView.
🟢 Связные списки: UIResponder.
🟢 Хеш-таблицы: Dictionary<K,V> и протокол Hashable.
🟢 Побитовые операции: OptionSet.
Примечание: автор прав, говоря о том, что даже не зная формальных определений, разработчики с самого начала карьеры (или даже прохождения каких-то курсов), уже получают необходимые знания, пусть и не зная нужных терминов.
Так действительно ли нужно всё это знать. Попробуем провести параллель с профессиональным музыкантом?
Для этого можно ответить самому себе на следующие вопросы:
🔘 Хочу ли я изучать это как хобби и никогда не выходить за рамки игры на диване для развлечения?
🔘 Хочу ли я играть в группе и зарекомендовать себя как музыкальный исполнитель?
🔘 Стремлюсь ли я выйти за рамки простого звания «музыкальный артист», живя и дыша классической музыкой, становясь неотъемлемой частью Венского филармонического оркестра, путешествуя по миру и войдя в историю как легенда, которая буквально сформировала концепцию самой музыки?
Так почему же ведущие компании делают то, что делают?
Для такой компании, как Google, неинтересно нанимать кого-то, кто посвятил свою жизнь изучению всего, что касается UIKit в iOS — их проблема не в том, какие API UIKit использовать, а в том, что API, которые им нужны, не существуют вообще.
Эти проблемы решаются благодаря пониманию computer science и способности создавать новые и эффективные решения. Ваше понимание программирования как концепции доказывает, что вы тот самый тип программиста, который им нужен.
В сочетании с обычными заданиями альтернативные (как, например, код-ревью) могут дать вам действительно хорошее представление о практических знаниях кандидата, поскольку они имеют отношение к должности и задачам, которые нужно будет решать.
📖 Про сложность алгоритмов можно прочитать здесь.
📖 Про подход в Neflix и Tiktok.
@iOS Dev
📖 Бруно Роша, разработчик в Spotify, рассуждает в своей статье о необходимости алгоритмов, презирании этой темы в сообществе и проводит параллели с развитием музыканта.
Я постарался выделить основные моменты, и позволил себе добавить некоторые комментарии.
Проблема в том, что сообщество часто направляет ненависть к подобным собеседованиям не по назначению. Негатив вокруг этого формата интервью стал настолько велик, что теперь часто можно встретить людей, испытывающих неприязнь к самой теории, которая не имеет ничего общего с непонятными головомками в программировании.
Это мнение стало настолько популярным, что теперь практически невозможно упомянуть концепцию программирования на абстрактном уровне без того, чтобы кто-то немедленно не начал холивар о практике проведения интервью. А это вредит в том числе и индивидуальной карьере инженеров, которым говорят держаться подальше от этих знаний по причинам, не поддающимся логике.
Поднимаются важные вопросы
🔴 Теория не отражает того, что человек будет делать на самом деле в своей работе.
🔴 Знание теории не является показателем мастерства человека в данной практической роли.
🔴 Теория вообще бессмысленна. Зачем разработчику iOS знать, что такое граф?
Всё это создает у людей впечатление, что основы бесполезны, в то время как на самом деле они используют их постоянно!
Я не могу передать, сколько раз я слышал, как разработчик iOS говорил: "Я могу с уверенностью сказать, что никогда в своей работе мне не приходилось использовать граф", а затем радостно рассказывал о чем-то интересном, с чем они работали, используя иерархии UIView. Это одно и то же!
Объекты, которые могут соединяться друг с другом с целью создания единой связной карты элементов, - это буквальное определение графа, поэтому они не только знают, что такое граф, но и используют его с самого первого дня работы в качестве разработчика!
🟢 Графы/деревья: UIView.
🟢 Связные списки: UIResponder.
🟢 Хеш-таблицы: Dictionary<K,V> и протокол Hashable.
🟢 Побитовые операции: OptionSet.
Примечание: автор прав, говоря о том, что даже не зная формальных определений, разработчики с самого начала карьеры (или даже прохождения каких-то курсов), уже получают необходимые знания, пусть и не зная нужных терминов.
Так действительно ли нужно всё это знать. Попробуем провести параллель с профессиональным музыкантом?
Для этого можно ответить самому себе на следующие вопросы:
🔘 Хочу ли я изучать это как хобби и никогда не выходить за рамки игры на диване для развлечения?
🔘 Хочу ли я играть в группе и зарекомендовать себя как музыкальный исполнитель?
🔘 Стремлюсь ли я выйти за рамки простого звания «музыкальный артист», живя и дыша классической музыкой, становясь неотъемлемой частью Венского филармонического оркестра, путешествуя по миру и войдя в историю как легенда, которая буквально сформировала концепцию самой музыки?
Так почему же ведущие компании делают то, что делают?
Для такой компании, как Google, неинтересно нанимать кого-то, кто посвятил свою жизнь изучению всего, что касается UIKit в iOS — их проблема не в том, какие API UIKit использовать, а в том, что API, которые им нужны, не существуют вообще.
Эти проблемы решаются благодаря пониманию computer science и способности создавать новые и эффективные решения. Ваше понимание программирования как концепции доказывает, что вы тот самый тип программиста, который им нужен.
В сочетании с обычными заданиями альтернативные (как, например, код-ревью) могут дать вам действительно хорошее представление о практических знаниях кандидата, поскольку они имеют отношение к должности и задачам, которые нужно будет решать.
📖 Про сложность алгоритмов можно прочитать здесь.
📖 Про подход в Neflix и Tiktok.
@iOS Dev
❤🔥15🔥5👍2🌭1
Все вообще вижу критику ежедневных стендапов. А некоторые мои знакомые-коллеги категорически отказываются идти в команды, где это необходимость. А как вы относитесь к ежедневным ритуалам скрама и какие пользы видите в них?
Лично я считаю норм, если команда не справляется
vc.ru/opinions/289552
Лично я считаю норм, если команда не справляется
vc.ru/opinions/289552
vc.ru
«Ежедневные стендап-совещания? Нет уж, спасибо»: почему они нужны только адептам микроменеджмента и лентяям — Мнения на vc.ru
Почему начальники рискуют потерять сотрудников и как могут следить за прогрессом без совещаний — рассуждает программист и соучредитель трейдинговой платформы Supercede Йезен Томас.
Ежедневный дэйли это норм?
Anonymous Poll
36%
Норм всегда
21%
Норм, если команда не справляется
23%
Не норм
21%
Синки лучше через день
Static свойства
🟢 lvl: jun+
static свойствами называют свойства и методы, принадлежащие типу, а не экземплярам типа.
Инициализация static пропертей (а также глобальных переменных) происходит лениво, при первом обращении, инициализация гарантированно произойдет только один раз даже при паралельном обращении с нескольких потоков.
Когда мы должны использовать static свойства и методы?
🟣 Использование статических свойств для конфигурации
Самый частый кейс — использовать свойства, единственной целью которых является настройка других объектов (см скрин 1).
Так удобно юзать настройки цветов и шрифтов в одном месте, а использование enum не требует конструктора
⚪ Использование статических свойств для дорогих объектов
Юзать как кеш. Создание некоторых объектов может быть дорогим. Такие объекты можно сохранить в статическом объекте (см скрин 2)
Создание фабрики со статическими методами
🔵 Использование для синглтонов
Каждый из перечисленных имеет статическое свойство, которое содержит экземпляр по-умолчанию. URLSession.shared, UserDefaults.standard, NotificationCenter.default, DispatchQueue.main.
Основное преимущество таких определений — это потокобезопасность и гарантия того, что 2 URLSession не выполнят одновременно один запрос.
- Эффективно используем статические свойства
- Swift Properties
🟢 lvl: jun+
static свойствами называют свойства и методы, принадлежащие типу, а не экземплярам типа.
Инициализация static пропертей (а также глобальных переменных) происходит лениво, при первом обращении, инициализация гарантированно произойдет только один раз даже при паралельном обращении с нескольких потоков.
Когда мы должны использовать static свойства и методы?
🟣 Использование статических свойств для конфигурации
Самый частый кейс — использовать свойства, единственной целью которых является настройка других объектов (см скрин 1).
Так удобно юзать настройки цветов и шрифтов в одном месте, а использование enum не требует конструктора
⚪ Использование статических свойств для дорогих объектов
Юзать как кеш. Создание некоторых объектов может быть дорогим. Такие объекты можно сохранить в статическом объекте (см скрин 2)
Создание фабрики со статическими методами
🔵 Использование для синглтонов
Каждый из перечисленных имеет статическое свойство, которое содержит экземпляр по-умолчанию. URLSession.shared, UserDefaults.standard, NotificationCenter.default, DispatchQueue.main.
Основное преимущество таких определений — это потокобезопасность и гарантия того, что 2 URLSession не выполнят одновременно один запрос.
- Эффективно используем статические свойства
- Swift Properties
👍14
Lazy Props
🟢 lvl: jun+
Хоть мы и любим ленивые свойства, но у них не все так гладко.
В примере выше мы узнали, что lazy не гарантирует инициализацию свойства только один раз. Но еще могут быть проблемы?
Вот есть несколько статей, которые освежат память:
-Потокобезопасность lazy переменных
- Проблемы lazy var part 1
- Проблемы lazy var part 2
🟢 lvl: jun+
Хоть мы и любим ленивые свойства, но у них не все так гладко.
В примере выше мы узнали, что lazy не гарантирует инициализацию свойства только один раз. Но еще могут быть проблемы?
Вот есть несколько статей, которые освежат память:
-
- Проблемы lazy var part 1
- Проблемы lazy var part 2
👍3👌1
Порцию контекта вам наваливаю
https://www.youtube.com/playlist?list=PL6Wui14DvQPySdPv5NUqV3i8sDbHkCKC5
https://www.youtube.com/playlist?list=PL6Wui14DvQPySdPv5NUqV3i8sDbHkCKC5
YouTube
Тренировки по алгоритмам
Приглашаем вас потренироваться в решении алгоритмических задач. 8 лекций с домашними заданиями и 4 разбора заданий. Лектор - Михаил Густокашин, Директор цент...
🔥10👍2
Сейчас уже месяц как я ежедневно решаю задачи. Во-первых мне интересно какие навыки я получу. Во-вторых, проверить свою мотивацию и дисциплину.
Вот и чел год решал задачи на литкоде. По его наблюдениям он улучшил:
- стал лучше дебажить код
- лучше понимать язык
- узнал новые подходы и техники
- улучшил написание юнит-тестов🙂
Насчёт последнего пункта. Все больше считаю, что разрабатывать через тестирование — это отдельный уровень качественной разработки.
https://youtu.be/CNXuEjfaNYs
Вот и чел год решал задачи на литкоде. По его наблюдениям он улучшил:
- стал лучше дебажить код
- лучше понимать язык
- узнал новые подходы и техники
- улучшил написание юнит-тестов🙂
Насчёт последнего пункта. Все больше считаю, что разрабатывать через тестирование — это отдельный уровень качественной разработки.
https://youtu.be/CNXuEjfaNYs
YouTube
Год решал задачи на LeetCode
Курсы по программированию: https://clck.ru/37iG2b
Потренироваться проходить собеседования: https://clck.ru/3C2CY3
Консультации:
https://getmentor.dev/mentor/vladimir-balun-191
https://solvery.io/ru/mentor/vladimir_balun
00:00 - Введение
00:09 - Что такое…
Потренироваться проходить собеседования: https://clck.ru/3C2CY3
Консультации:
https://getmentor.dev/mentor/vladimir-balun-191
https://solvery.io/ru/mentor/vladimir_balun
00:00 - Введение
00:09 - Что такое…
👍11
вы когда-нибудь покупали спички?
попробуем поэкономить
плюс один повод докапываться на ревью
https://www.globalnerdy.com/2016/02/03/concatenating-strings-in-swift-which-way-is-faster/
попробуем поэкономить
плюс один повод докапываться на ревью
https://www.globalnerdy.com/2016/02/03/concatenating-strings-in-swift-which-way-is-faster/
Global Nerdy
Concatenating strings in Swift: Which way is faster? : Global Nerdy
Creative Commons photo by Jaguar MENA. Click to see the source. Stack Overflow user “James” asked: Which is the quickest, and most efficient way to concatenate multiple strings in Swift 2? // Solution 1... let newString:String = string1 + " " + string2 //…
❤8👍1