Пятничное чтиво Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте. ————————————— How Tinder Decomposed Its iOS Monolith App Handling 70M Users Очередная статья о том, как в компании решали проблемы. Сегодня это тиндер (дейтинг), который, в ходе развития iOS приложения, получил монолит с неудовлетворительным значением TTM и maintainability. Подобная ситуация привела к тому, что релиз приложения требовал долгой сборки, без гарантий, что приложение работает корректно. А в качестве решения — модуляризация зависимостей, которая поможет с парализацией сборки. Текст начинается с описания проблемы со сборкой мобильного приложения. Далее описываются принципы, по которым происходила модуляризация приложения. Тут помог компилятор swift, благодаря которому получилось построить граф зависимостей в текущем приложении. Далее описываются проблемы, которые возникли во время изоляции модулей. Кроме ручной работы, в компании заморочились и автоматизировали перемещение файлов и резолв конфликтов. #how_it_works ————————————— Kafka Error Handling: Strategic Consumer Isolation Работая с асинхронными коммуникациями, стоит помнить об обработке ошибок. Причем, поведение основного консьюмера (который получает «обычные» сообщения) и поведение консьюмера с «зафейлиными» сообщениями может отличаться. Из-за этого, логика работы консьюмеров может отличаться. Об этом задумался автор текста и как результат — решил поделиться собственным подходом к обработке ошибок в кафке. Текст начинается с объяснения проблемы с которой столкнулся автор: нельзя обработать событие и надо продолжить обрабатывать остальные сообщения (при этом, стоит помнить об увеличенном retention для таких событий). Далее описывается стратегия, которая состоит в создании 4 топиков для обработки событий: основной топик, топик для ретраев, топик для DLQ и топик для сообщений, которые приходится обрабатывать вручную. Далее описывается как создать подобную систему используя spring. В конце найдете плюсы подхода (изоляцию, разное значение retention для разных видов ошибок и так далее). К сожалению минусы автор не написал, но присутствует описание сценариев когда подход подойдет, а когда нет. Плюс, пара идей по обсервабилити. #kafka #error_handling ————————————— Technical and other Debt in IT Systems О тех долге уже делал отдельную подборку. Сегодня статья, автор задался целью описать виды долга и объяснить взаимосвязь каждого из «долгов» между собой. Т.е. ключевое, что есть в статье — диаграмма связей между видами долга между собой и какой долг приводит к другому (вторая картинка в оригинальном посте). Сам текст начинается со справки: кто придумал термин, откуда пошло массовое использование термина и что термин значит. Далее начинается главное, из-за чего статья оказалась в подборке: связь между разными видами долга с объяснением каждого из видов. Так, coding debt приводит к проблемам в рантайме и пересекается с testing debt. А к coding debt приводят проблемы с требованиями и коммуникациями. Далее описывается каждый из 10 видов долга (requirements, code and design, architecture, knowledge, technology, infrastructure, testing, security, operational, process и runtime quality issues). Для каждого вида дается краткая справка что это за долг, примеры которые говорят об этом типе долга. Главное: не ждите от статьи описания способов решения долгов, тут только классификация. Русский перевод #tech_debt