Руководитель мобильной разработки
Не так давно на хабре появилось несколько постов противопоставляющих функциональный и объектный подход, породивших в комментариях бурное обсуждение того, что вообще это такое — объектно ориентированное программирование и чем оно отличается от функционального. Я, пусть и с некоторым опозданием, хочу поделиться с окружающими тем, что думает по этому поводу Роберт Мартин, также известный, как Дядюшка Боб.
Привет, Хабр! Меня зовут Евгений Зорин, я ведущий разработчик в центре инноваций Future Crew. У моего проекта достаточно компактная команда. Нам постоянно нужно проверять критически важную функциональность, и часто это может сделать только сам разработчик. С появлением современных LLM, таких как ChatGPT, возникла идея об их внедрении для ревью кода. В качестве подопытного кролика был выбран Swift. В этом материале я расскажу, чего мы добились, какие инструменты использовали и как LLM справляется с поставленной задачей.
Привет, Хабр!
Меня зовут Юрий Шабалин, и, как я пишу в начале каждой своей статьи, мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.
В этой статье мне бы хотелось затронуть тему безопасной конфигурации сетевого взаимодействия, а также немного расширить предыдущую статью по SSL Pinning для механизма защиты канала связи в iOS. А именно, я расскажу про App Transport Security: для чего он нужен, использовать ли его или отключать в приложениях, в чем его польза.
На эту тему существуют статьи на англоязычных ресурсах (здесь можно многие из них найти в разделе “Ссылки“), достаточно подробно эта тема раскрыта в документации Apple, но на русском я статей практически не встречал. Но даже если они есть, я с удовольствием добавлю свой материал с практическими примерами в эту небольшую копилку.
Не будем мусолить всем известную проблему с навигацией в SwiftUI до 16 iOS, так как уже много крутых статей на эту тему есть в открытом доступе. Близится релиз 18 iOS, а это значит, что минимальные таргеты поднимутся на единичку ближе к 16 🥳
В данной статье хочу представить на `мой взгляд` наиболее удобную реализацию навигации на NavigationStack. Разумеется в концепции старого доброго MVVM, поэтому фанаты UDF извините 😜
Мы — внедрители. Мы должны внедрять, а не фантазировать!
(Рина Зеленая, к/ф «Девушка без адреса»)
Синтаксис async/await, введенный в Swift 5.5, значительно упростил асинхронное программирование, сделав его более доступным и интуитивно понятным. Однако, как и любой мощный инструмент, он может быть использован неправильно. Здесь я хочу рассмотреть пять распространенных ошибок, которые разработчики часто допускают при использовании async/await и предложить стратегии их избегания.
Ошибка 1: Необработка Ошибок
Асинхронные функции Swift могут вызывать ошибки, так же как и их синхронные аналоги. Однако многие разработчики, особенно те, кто только начинает работать с синтаксисом async/await, могут упускать обработку ошибок, что приводит к сбоям или непредсказуемому поведению.
Решение
Синтаксис do-catch в Swift - ключ к обработке ошибок из асинхронных функций. Обернув вызов асинхронной функции в блок do-catch, вы можете перехватить и обработать любые выброшенные ошибки, предотвратив сбои и обеспечивая предсказуемое поведение вашего приложения.
Иногда бывает так, что вы отправляете на проверку пул-реквест, который оказался существенно больше, чем вы ожидали. И у вас возникает вопрос:
«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»
Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:
«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»
И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.
Однако моя статья будет немного о другом:
«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»
Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.
Привет! Я Даниэль Халиулин, технический менеджер продукта в Тинькофф. Отвечаю за надежность и производительность нашего основного приложения — мобильного банка. Руковожу двумя одноименными командами, которые занимаются производительностью и надежностью. Расскажу про направления SRE и Observability в мобильных приложениях.
"Идеальный программист" Роберта Мартина давно стал руководством по профессионализму в сфере IT и одним из основополагающих трудов в современной разработке, наравне с "Чистым кодом", "Чистой архитектурой" и "Чистым эджайлом".
В посте ниже собраны наиболее значимые тезисы из "Идеального программиста".
Привет, Хабр. Меня зовут Кирилл Смирнов. Я технический лидер iOS команды в СберЗдоровье. Последний год наша команда активно занимается улучшением инструментов разработки, в том числе модуляризацией, и уже успела получить опыт, который может быть полезен другим. В предыдущем материале я рассказывал, как компании подготовиться к модуляризации iOS приложений, а в этом остановлюсь на вопросах оптимизации сборки проекта и выборе вариантов линковки артефактов компиляции.
Инженеры Apple придумали прекрасные по быстродействию и производительности процессоры Apple Silicon (M1, M1 Max и так далее) на архитектуре arm64. Но за полученное быстродействие разработчикам пришлось платить своим временем.
Рассказываем, к каким проблемам мог привести апгрейд рабочего мака и что нужно учитывать с изобретением процессоров Apple Silicon.
Статья вдохновлена ограничениями в недавно вышедшем Xcode 14.3: запуск из-под Rosetta в нём стал deprecated.
Это третья часть из серии статей про компонентный подход. В предыдущей статье мы рассмотрели, как реализовать сложный экран, разбив его на набор простых компонентов. Применим эту же идею, чтобы организовать сложную навигацию.
В статье много практики. Сначала я покажу, как с помощью Decompose и Jetpack Compose создавать отдельные флоу приложения. Далее обсудим реализацию bottom-навигации. И, наконец, объединим несколько флоу воедино, чтоб получить навигацию по всему приложению.
Я покажу примеры из реального приложения. Вы увидите, что предлагаемый подход хорошо подходит для больших приложений с десятками, а то и сотнями экранов.
Часто слышу мнение, что unit-тесты не нужны для мобильной разработки: в приложении должно быть минимум логики, основная работа с UI, а его сложно тестировать, да ещё и тесты отнимают время, которое можно было бы потратить на написание фич.
За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать.
Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов.
История о том, почему «обновить ссылку» — задача для техлида: тут и про тесты, и про вёрстку, и про архитектуры процессоров.
Мы сделали игру для проведения штабных киберучений по информационной безопасности. Чтобы не только потренировать навыки реагирования на инциденты ИБ, но и отлично провести время. Хотим с вами ей поделиться. В статье описание и материалы для игры, выводы по результатам проведенных игр и еще больше котеек.
На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.
Комплекс доменной неполноценности — это когда веришь, что доменный слой приложения должен быть самым большим и самым важным, и винишь себя в том, что в твоём коде это не так. Это происходит, если воспринимать «Чистую архитектуру» как единственно верный способ писать код.
Привет, меня зовут Саша, я Head of mobile в компании «Метр квадратный». Под катом — почему появился этот комплекс и как с ним бороться. Сразу оговорюсь, в статье много моего личного мнения, и будет круто, если в комментах вы поделитесь своим.