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

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

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

Хабр, привет. Меня зовут Рамиль Шайбаков, я фронтенд‑разработчик в СберЗдоровье. Последние несколько лет я часто собеседую кандидатов на позицию frontend‑разработчика в нашу компанию и заметил одну закономерность — у большинства специалистов нет опыта в тестировании. Причем знаниями о unit/интеграционных/e2e‑тестах, пирамиде тестирования, красно‑зелёном рефакторинге, TDD и BDD, скриншот‑тестировании и других техниках не могут похвастаться как новоиспеченные фронтенды, так и специалисты уровня Senior. Причины и аргументы у всех разные, но итог один — фронтенды часто не делают тесты.

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

Мы делили апельсин, много нас, а он один…

Привет! Я Слава, QA в мобильной разработке компании «СберЗдоровье». В прошлых статьях я рассказывал о наших процессах тестирования при активном росте команды и о разделении на фича-команды.

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

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

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

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

Поговорим о провайдере

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

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

Привет! Я Даша Почекуева, дизайнер в СберЗдоровье. В последние полтора года я работаю над  личным кабинетом врача телемедицины — платформой, на которой врачи СберЗдоровья общаются с пациентами.

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

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

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

Так как мы являемся mobile first-компанией, то примерно в сентябре-октябре 2021г. мы приняли решение изменить структуру и разделить две наши сервисные команды на продуктовые, в каждой из которых были бы свои разработчики, менеджеры и QA. Но где же взять людей для тестирования отдельных участков приложения...

Привет! Я Слава, QA в мобильной разработке СберЗдоровья, и я хочу рассказать о том, как менялись наши процессы тестирования за прошедший год, какие проблемы в связи с этим встречались, и как мы их решали.

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

В данной статье я расскажу как мы решали эту задачу.

Мы Дима и Настя, Android-разработчики в компании СберЗдоровье. В этой статье мы хотим рассказать о том, как мы перевели весь наш проект с LiveData на Flow, с какими трудностями столкнулись и что полезного узнали. Эта статья будет полезна тем, кто работает с LiveData, уже пробовал / хочет попробовать Flow для хранения состояний во ViewModel, а также командам, которые планируют миграцию всего проекта на новый инструмент. 

Привет, Хабр!

На связи СберЗдоровье, до 2020 вы могли слышать о нас под именем DocDoc .

Последний пост у нас в Хабре от 2013 года, а потом были 9 лет тишины.

Что же у нас произошло за это время, и почему мы вообще решили вернуться.

Рассказываем обо всём по порядку и начнём сначала.