Абсолютно не согласен. Ну то есть вы не обсуждаете требования с PM/PO, не общаетесь и не проектируете контракт взаимодействия с Backend-командой. Используете связку Rest API + Json, только потому что везде так делали? Если вы не читали статью - то не зачем писать такие комментарии. Цель статьи - описать процесс System Design Interview для мобильного разработчика. Современные инженеры не просто верстают кнопки на компоузе, необходимо глубоко разбираться в различных аспектах начиная от протоколов взаимодействия и проектирования локальной схемы БД заканчивая оптимизацией UI. Поэтому в этой части были описаны первые 2 этапа: сбор требований и проектирование API/модели данных для дальнейшей коммуникации с сервером. Если вам это не интересно и для вас мобильная разработка - это верстка кнопок, то просто не читайте эту статью. Насчет использования ИИ - скорее вас смутила табличка со смайликами - не вижу здесь ничего плохого если это делает текст более легким для восприятия.
В основном, когда говорим о модулях в контексте android-разработки, то имеются ввиду Android-модули. Но иногда, если не нужны классы из Android SDK, то достаточно java или kotlin - библиотеки, но в оригинальной статье их тоже называют модулями.
Современные android-приложения уже давно переваливают за несколько сотен экранов. Таким образом деление на модули - способ организации кода для дальнейшего переиспользования и уменьшения связанности даже в пределах одного приложения. В статье есть примеры data-модулей, утилитных модулей - они могут пригодиться даже в небольшом проекте. А если у вас команда в проекте больше 20 android-разработчиков, то выделение в отдельные фича -модули позволяют ускорить разработку, уменьшить кол-во merge-конфликтов, снизить кол-во ошибок во всем приложении. Не зря большие команды типа Uber имеют несколько десятков, а то и сотен модулей. Если у вас небольшое приложение с небольшой командой - то скорее всего разбиение на модули и не нужно.
Здравствуйте, описанная в статье проблема — всего лишь иллюстрация типовых требований к спискам в Android. Если вам нужно реализовать так, как описано в разделе «Проблема» то вы можете используя MergeAdapter создать 2 разных адаптера (один для текста, другой для картинок) разделив тем самым логику.
Абсолютно не согласен. Ну то есть вы не обсуждаете требования с PM/PO, не общаетесь и не проектируете контракт взаимодействия с Backend-командой. Используете связку Rest API + Json, только потому что везде так делали? Если вы не читали статью - то не зачем писать такие комментарии. Цель статьи - описать процесс System Design Interview для мобильного разработчика. Современные инженеры не просто верстают кнопки на компоузе, необходимо глубоко разбираться в различных аспектах начиная от протоколов взаимодействия и проектирования локальной схемы БД заканчивая оптимизацией UI. Поэтому в этой части были описаны первые 2 этапа: сбор требований и проектирование API/модели данных для дальнейшей коммуникации с сервером. Если вам это не интересно и для вас мобильная разработка - это верстка кнопок, то просто не читайте эту статью. Насчет использования ИИ - скорее вас смутила табличка со смайликами - не вижу здесь ничего плохого если это делает текст более легким для восприятия.
В основном, когда говорим о модулях в контексте android-разработки, то имеются ввиду Android-модули. Но иногда, если не нужны классы из Android SDK, то достаточно java или kotlin - библиотеки, но в оригинальной статье их тоже называют модулями.
Современные android-приложения уже давно переваливают за несколько сотен экранов. Таким образом деление на модули - способ организации кода для дальнейшего переиспользования и уменьшения связанности даже в пределах одного приложения. В статье есть примеры data-модулей, утилитных модулей - они могут пригодиться даже в небольшом проекте. А если у вас команда в проекте больше 20 android-разработчиков, то выделение в отдельные фича -модули позволяют ускорить разработку, уменьшить кол-во merge-конфликтов, снизить кол-во ошибок во всем приложении. Не зря большие команды типа Uber имеют несколько десятков, а то и сотен модулей. Если у вас небольшое приложение с небольшой командой - то скорее всего разбиение на модули и не нужно.