Архив недели
Понедельник
Всем хорошего начала рабочей недели!
На этой неделе хостить буду я.
Кто я?👇
PO в платформенной iOS команде 🧬 Сбера
Что за платформенная команда? Об этом позже 👇
О чём расскажу на неделе:
👨🏭DevOps инфраструктура
🧩Как готовить модульность в крупном проекте
🚀Как управлять перфомансом
💎Особенности работы над долгоживущим приложением
🧬Роль платформенной команды
🤔Что-то не про работу на выходных
Вообще не про работу на выходных не всегда получается. Глаза горят, много крутых вещей хочется сделать, в общем, у нас в команде ребят бывает сложно остановить 😬. Не знаю как там во всей остальной разработке.
Тред (Миша Харитончик)
First things first! DevOps для проекта Сбербанк Онлайн – это краеугольный камень поддерживающий масштабирование кодовой базы.
Приложение эволюционировало
от классического джентльменского стартерпака в виде монорепозитория с пайплайном построенном на fastlane скриптах
до грандиозной модульной архитектуры с мультирепозиторием и набором инструментов созданных с нуля под наши нужды
В СБОЛе более 100 модулей (читай framework-ов), каждый из которых может быть легко вынесен в отдельный репозиторий или может быть совмещён с любым другим репозиторием. С точки зрения работы над кодом ничего не изменится, для попадания изменений в develop ветку нужен всё ещё 1 PR
До того как мы пришли к целевой картине DevOps архитектуры было много сомнений и периодический мы возвращались к вопросу "Монорепо VS Мультирепо", ведь большинство зарубежных гигантов продвигают Монорепозиторий.
Теоретическое представление о том как это должно работать всегда имело больше плюсов, чем минусов. Поэтому мы единожды законспектировали выводы в Confluence и больше не возвращались к этому вопросу.
Монорепозиторий прост и понятен, но только до тех пор пока вы не начинаете сражение с проблемами. А проблемы не любят говорить о себе сразу, толстая git история в определённый момент заставит вас отказаться от blame-а и сделать форк, либо подружиться с решениями вроде VFSForGit
Проблемы распределённой параллельной разработки имеют свои "проклятья", плоскость этих проблем чем-то схожа с многопоточным программированием. Как мне кажется, тут проще найти компромисс между непрерывностью разработки, сложностью поддержки и стабильностью сборки.
Жизнь в отдельном репозитории стимулирует к созданию отделяемых компонентов, упрощается слитие git историй, снижается нагрузка на BitBucket
Ревью PR-ов:
кросс-ревью всё ещё реализуется за счёт плагинов
упрощение просмотра кода за счёт логической кластеризации модулей
Вторник
Общее хранилище кода даёт важное преимущество – синхронность вносимых изменений
Один PR лучше, чем несколько последовательно зависящих друг от друга
Эту проблему мы решаем спец. механизмом, который позволяет создавать множество зависящих друг от друга PR-ов и вливать их разом
Инструментарий который стоит за всем этим имеет свою специфику и детали имплементации, могу остановиться и обрисовать более подробно любой аспект нашей инфраструктуры, если от вас будет запрос 😊
Тред (Миша Харитончик)
Сегодня был тяжёлый день, твитты сами себя не напишут, но ретвитты сделают своё дело. Вечер ретвиттов годноты из личного аккаунта объявляю открытым!
Среда
В СБОЛе модульность появилась ещё до того как это стало мэйнстримом. Самое сложное в таком подходе – это выдержать разумную стратегию разделения проекта с учётом размеров модулей, их взаимозависимостей и дальнейшей перспективой развития/удаления/отделения функционала.
Реалии мобильной разработки говорят о том, что все Фреймворки приложения работают в едином процессе и делят общие ресурсы, ответственность на всех и каждом. Поэтому мы не можем отпустить владельцев модулей в свободное плавание, нужны стандарты, чтобы управлять энтропией.
Контроль списка фреймворков приложения обеспечивается инхаус менеджером зависимостей, конечный список того что пойдёт в приложение известен заранее и стоит под пристальным надзором, «резолвить» граф для этого не нужно
Это также избавляет нас от необходимости «умного» разрешения зависимостей, когда несколько Фреймворков требуют одну и ту же зависимость, но разных версий.
Тред (Миша Харитончик)
Свой менеджер зависимостей невероятно полезен, большая часть оптимизаций времени сборки проекта реализована за счёт дополнительных знаний в коде инструментов сборки о архитектурных концептах принятых в нашем проекте
К примеру, не нужно делать лишний checkout репозитория для постарения полного графа зависимостей, в архиве с бинарным артефактом есть всё для этого
В архиве хранится дополнительная информация о ответственной за модуль команде, ссылка на jira пространство и прочие детали помогающие быстро составить представление о значении модуля в проекте.
Четверг
🧩 Модульная архитектура после первого десятка фреймворков неизбежно превратится в вертикальный граф зависимостей, это заблокирует возможность параллельной сборки, а также возникнет проблема невозможности взаимного импортирования фичемодулей (A.framework <-> B.framework).
Решение этих проблем кроется в создании банальной прокси для межмодульного взаимодействия
Фичемодулей, теперь они не используют друг друга напрямую, а «общаются» через технический.framework
Граф зависимостей становится плоским, гарантируется отсутствие циклических зависимостей
Неправильно: фичемодульА -> фичемодульБ
Правильно: фичемодульА -> технический.framework •••> фичемодульБ
Технический Фреймворк должен неявно (без импортирования) знать о том какие есть публичные интерфейсы и какой объект(принадлежащий более верхнеуровнему модулю) реализует его
У нас есть нечто особенное для разделения модулей по слоям, мы уходим от отдельного прокси фреймворка в сторону более гибкой схемы с разделением модуля на фреймворка «интерфейса» и «имплементации».
«Интерфейс» фреймворки не могут импортировать другие «интерфейс» фреймворки, «имплементации» свободно импортируют «интерфейсы» но не могут импортировать «имплементации»
Модуль состоит из:
Interface.framework
Implementation.framework
Mock.framework (фейк имплементация интерфейса)
Наличие моков в каждом модуле значительно упрощает тестирование и снимает головную боль по настройке моков, достаточно 1 раз сделать сетап моков модулей которые используются в модуле
Ставшая легаси objc реализация прокси раньше также загружала lazy фреймворки через dyld при первом обращении к модулю. Перфоманс стал намного лучше, когда мы перешли на статическую линковку.
На сегодняшний день улучшеная реализация легаси прокси имеет минимальный оверхед в рантайме, все что возможно предрассчитывается и подставляется кодгеном
Тред (Миша Харитончик)
Воодушевляет работа над приложением Сбербанк Онлайн, для меня это больше, чем просто профессия или работа, это – история, частью которой приятно себя осознавать.
Пятница
Работа с перформансом в мобильных приложениях сводится к приоритизации существующих проблем
Время на оптимизацию кода бывает неоправданно велико по отношению к профиту. Держим в уме, что это может навредить читаемости, а также сломать работающий функционал
Нужно иметь чувство меры, оптимизация производительности – это чертовский затягивающий процесс
Мобильные CPU на сегодняшний день работают непредсказуемо быстро
Проход по массиву там, где может быть использована хэшмап может работать быстрее за счёт небольшого количества данных, и зачастую данных в мобильных приложениях немного
Оптимизация – это последний этап разработки, корректность первостепенна!
Не забывайте про тесты ⚠️
🏚Сделайте каркас из юнит тестов перед тем как приступать к оптимизациям
🧪Тестовые данные должны способствовать нахождению граничных кейсов
Тред (Миша Харитончик)
Самый плохой код в моей жизни был написан ночью выходного дня после трудной рабочей недели 😵💫
Последствия стоили дополнительную неделю работы
💸 Компании теряют миллионы из-за банальных ошибок
🙄 Давайте делать мир лучше, не нужно романтизировать переработку, недосып и усталость
Мы не участвуем в конкурсе «кто больше устанет»
Трудовой кодекс эволюционирует веками, лимит в 8 часов выбран не просто так
Стабильный burn rate лучше, чем burst & fatigue
Парадоксально, что в IT индустрии есть все инструменты, чтобы работать «головой, а не 12 часов в день»
Мы должны были бороться со злом (человеческий труд), а не примкнуть к нему
Тред (Миша Харитончик)
Суббота
Проще научить программированию человека знающего английский, чем программиста научить английскому
Гугли на языке знаний 🤓
Плавный скролл для платформы iOS был большой фишкой и техническим челенджем начиная с момента презентации первого айфона, но по какому-то недоразумению остается проблемой для некоторых приложений по сегодняшний день
Люблю смотреть непрофильные конференции
На этой неделе следил за cppcon
Побочный эффект моей любознательности – развитие аэрофобии
Не легаси, а винтаж!
История повторяется, потому что мир – это симуляция, где мы застряли во временной петле целочисленного переполнения времени
#year2038problem
Кстати, помогаю делать podlodka.io/ioscrew, если есть что рассказать про анимации на платформе iOS, то пиши мне в t.me/resultBuilder
Вам достался код на новом проекте. Что бы вам хотелось в нём видеть?
🤔
58.8% Подробная документация🤔
41.2% Юнит тестыС чем лучше иметь дело?
Лаконичный, сделанный по всем правилам архитектуры код, юнит тесты прилагаются, но код не выполняет свою задачу, нужно править
Легаси, руки чешутся переписать, тестов нет, есть костыли, но код выполняет свою задачу
🤔
53.4% Красивый, некорректный🤔
46.6% Некрасивый, корректныйВоскресенье
Cat Copilot
Неделя подходит к концу, этот вечер уделю близким мне людям.
На этом всё, спасибо что читали
