код функций в приложении
Кабинет Информатики
Решения для задания 8–11 класса «Нейросети и разработка приложений»
В ходе задания участники смогут попробовать себя в роли разработчика мобильных приложений и пройти все этапы разработки: исследование и анализ, создание дизайна, разработка, тестирование и публикация. Каждый этап это один уровень тренажера:
1. Провести исследование аудитории и выбрать самый популярный интерес, который станет темой приложения (рис. 1).
2. Создать дизайн приложения, выбрав функции, которые понадобятся в приложении (рис. 2).
3. Написать код для приложения на основе функций, которые были добавлены на этапе дизайна (рис. 3).
4. Протестировать функции приложения (рис. 4).
5. Заполнить анкету приложения для публикации в магазине приложений (рис. 5).
Рис. 1. Первый уровень. Анализ и исследование аудитории.
Второй уровень. Школьники могут испытать себя дизайнерами Им нужно разработать макет дизайна приложения, которое дает понять, как будет выглядеть и функционировать приложение. Ученики выбирают нужную функцию приложения из меню слева «Панель конструктор» и перетаскивает их на экран смартфона (рис. 2).
Рис. 2. Второй уровень. Проектирование дизайна приложения.
Третий уровень. Школьникам нужно написать код приложения, созданного на этапе дизайна в окне редакторе кода Code Editor. В этом ученику поможет «справочник функций», в котором перечислены коды функций, используемые в приложении. Обратите внимание, что основная часть кода уже написана. Ученику остается переписать оставшиеся функции или перенести их при помощи мышки из справочника функций и окно редактирования кода (рис. 3).
Рис. 3. Третий уровень. Разработка кода приложения.
Четвертый уровень. Школьники выступают в роли тестировщиков, которым нужно проверить работоспособность приложения по чек-листу слева. Для этого на экране смартфона нужно прощелкать функции приложения, если функция не работает, то помощник покажет, какая функция не работает и попросит добавить ее для этого нужно вернуться на предыдущий уровень и дописать недостающие функции (рис. 4).
Рис. 4. Четвертый уровень. Тестирование приложения.
Пятый уровень. Школьник закончил все этапы разработки, приложение готова, осталось опубликовать его в магазине приложений. Для этого нужно заполнить анкету приложения, где необходимо указать: название приложения, имя и фамилию автора, тему приложения, перечислить его функции в описании. После того как эти данные заполнены, можно нажать «Опубликовать».
Рис. 5. Пятый уровень. Публикация приложения в магазине.
Что такое API
Краткий ликбез по API. Выясняем, что он собой представляет, как работает и зачем нужен. Рассмотрим примеры использования, способы вызова и тенденции развития.
Что значит API?
Этот термин расшифровывается как Application Programming Interface, что в переводе на русский значит «Программный Интерфейс Приложения». Аббревиатура API используется часто и на слуху у многих пользователей, взаимодействующих с компьютерами (даже далеких от программирования). Правда, популярность термина не сделала его особо понятнее. Для многих это все еще набор символов без четкого значения. В лучшем случае пользователи в ответ на вопрос «Что такое API» скажут, что это инструмент для взаимодействия нескольких программ, в худшем – не скажут ничего.
И первые будут правы, потому что программный интерфейс включает в себя функции, классы, методы и структуры, помогающие одному приложению взаимодействовать с другим. API содержит в себе некие «мостики», позволяющие программе А получить доступ к данным из программы Б или к некоторым ее возможностям. Таким образом, программисты могут расширять функциональность своего продукта и связывать его с чужими разработками.
Все это с разрешения создателей программы А и с соблюдением всех мер безопасности, чтобы разработчики, желающие использовать API, не смогли получить доступ к конфиденциальной информации.
Главный принцип работы API. Почему его называют интерфейсом
Простыми словами, интерфейс – это «прослойка» между приложением А и приложением Б. В ней происходят процессы, которые позволяют двум программам обмениваться информацией и выполнять функции, связанные с обеими сторонами, скрывая «внутреннее строение» программ. Знакомо? Только что таким же образом мы описали API.
Такой подход позволяет наладить взаимодействие между несколькими утилитами, не задумываясь о том, как они устроены, какая программная логика ими движет и каким образом обрабатываются передаваемые данные. Интерфейсы упрощают работу как для простых пользователей, так и для программистов. Первым не приходится задумываться о том, что стоит за привычными функциями в их гаджетах, а разработчикам не нужно изучать код других программистов, чтобы подключить чужой продукт к своему.
Это называется инкапсуляцией. Сокрытием части функций ради упрощения работы в целом и минимизации участков программного обеспечения, где один из разработчиков мог бы допустить ошибку.
Набор функций в программных интерфейсах приложения
Список опций, доступных при работе с тем или иным API, зависит от разработчиков. Есть три основных пункта, описывающих работу интерфейса и методы взаимодействия с ним:
По сути, мы имеем скрытую функцию или набор скрытых функций, внутри которых происходит обработка и выдача передаваемых данных (и этот процесс скрывается благодаря инкапсуляции).
Составление набора функций в API
Внутреннее устройство API зависит от того, каким образом его организует разработчик. Есть стандартные варианты, но они не являются «догматом».
Например, кто-то в отдельный набор функций определяет возможность регистрироваться и авторизоваться. Другие программисты добавляют в API набор скрытых функций для внедрения уже существующего сервиса в стороннее приложение или на сторонний веб-сайт (платежные системы, навигация и т.п.).
Некоторые разработчики делят API на группы. К примеру, отдельно инструмент для работы с платежными системами и отдельно другие функции банка. Но можно подключать все одним набором, и тогда уже второй разработчик будет выбирать, какие из доступных возможностей API использовать.
Зачем нужен API?
Теперь нам знакомы принципы работы API и задачи, которые они помогают решить. Но они хороши не только этим. Программные интерфейсы используются еще по двум немаловажным причинам.
Во-первых, такой подход позволяет делать программы надежнее. Инкапсуляция в целом заметно упрощает жизнь разработчиков. Отдельные компоненты приложений становятся абстракциями. Создателям нового ПО не приходится лезть в логику низкоуровневых функций и разбираться в их реализации. Так заметно повышается безопасность выполняемых задач, что особенно заметно на уровне таких масштабных программных продуктов, как операционные системы. Программы постоянно выполняют сотни внутренних задач, при этом они проходят незаметно для пользователя и не могут навредить друг другу.
Во-вторых, на API можно заработать. Например, сервисы, предоставляющие информацию с метеовышек, берут плату за каждый запрос актуальной погоды, если их API используется в сторонних приложениях. Аналогичные условия могут предлагать и другие компании, предоставляющие услуги. Будь то навигация, конвертация файлов в другие форматы и прочие возможности, реализуемые через API.
Почему разработчики используют API?
Есть как минимум еще 4 причины, объясняющие интерес программистов к API:
Примеры API
Работа API представляет собой передачу данных по определенному запросу со стороны клиента или другого приложения. Допустим, нужно выудить информацию с существующего сайта и передать ее в программу.
В браузере будет дан запрос и ожидаться ответ в виде HTML-страницы. Если же используется API в стороннем приложении, то ему может быть достаточно фрагмента данных в формате JSON. Более точное техническое описание работы любого из существующих API доступно только их создателям.
На стороне пользователя такая реализация интерфейса будет выглядеть как банальная возможность выполнить действие, связанное с программой А в программе Б. То есть убрать лишний переход в стороннюю программу.
Ниже разберем частные случаи использования API с перспективы пользователей, а не разработчиков.
Google Календарь
Те, кто использовал приложения-календари для iOS или Android, знают, что данные в них можно синхронизировать, подключив один из популярных сервисов: Apple iCal или Google Calendar. Обе компании предлагают разработчикам API, позволяющие подключить свой календарь напрямую к сторонним приложениям. Благодаря подобной интеграции люди могут использовать несколько разных программ со схожей функциональностью и иметь на руках актуальную информацию о всех своих делах.
API позволяют создавать новые события и напоминания, удалять уже существующие, редактировать их и т.п.
Погодное приложение
Существующие погодные приложения (встроенные в операционную систему или сторонние из App Store или Google Play) получают информацию о погоде из сторонних источников.
Есть сервисы, взаимодействующие напрямую с метеостанциями и обладающие информацией о текущей погоде. Разработчики приложений для мобильных устройств эту информацию покупают.
А чтобы весь процесс упростить, сервисы, сотрудничающие с метеостанциями, разработали соотвествующие API. В них содержится набор функций, помогающий делать запросы о погоде в конкретных местах. Эти запросы через посредника (приложение) отправляются на «метеостанцию», а их результат возвращается пользователю тем же путем.
Сервис по заказу авиабилетов
Здесь аналогичная ситуация. Помимо сайтов и приложений, принадлежащих авиакомпаниям, есть так называемые агрегаторы. У нас популярен Aviasales, но есть и другие.
Такие сервисы собирают информацию о стоимости авиабилетов в разных авиакомпаниях и отображают ее в едином окне. Чтобы добыть эту информацию, разработчики используют функции сервисов авиакомпаний, которые помогают в реальном времени обновлять информацию о направлениях и стоимости билетов.
Кнопки авторизации
Наверняка вы видели на различных сайтах кнопки, позволяющие зарегистрироваться с помощью уже существующих аккаунтов на популярных площадках. Сейчас такие есть у Google, Facebook, Apple, Twitter, ВКонтакте и т.д. Набор доступных опций на конкретном ресурсе полностью зависит от его хозяев. Это тоже делается через API. Условная Apple создала набор защищенных функций, который можно с минимальными затратами подключить к своему проекту и предоставить пользователям доступ к удобному и безопасному способу авторизации.
При этом жизнь пользователей становится проще, а у владельцев ресурса остается доступ к почтовым адресам и другим персональным данным для взаимодействия с вновь зарегистрировавшимся человеком.
Навигация на сайтах и в приложениях
Тут почти как с погодой. Есть несколько крупных корпораций, предлагающих картографические данные. Те же Apple, Google, Yandex и парочка других. Некоторые из этих компаний разработали API, позволяющие подключить собственный картографический сервис к другим площадкам. Иногда они используются во внутренних продуктах. Яндекс.Транспорт построен на базе Яндекс.Карт, к примеру. Иногда API используются крупными партнерами. Uber использует для навигации сервис компании Google.
То же самое делают разработчики многих приложений под Android. Так как это API, встроенный в операционную систему, подключить карты Google к своему сервису доставки еды или приложению для бегунов проще всего. На iOS ситуация иная – там проще работать с Apple Maps.
Но у API навигационных сервисов есть и более скромное применение. Например, интерактивные мини-карты в футерах местечковых заведений, на которых указана схема проезда с возможностью быстро построить маршрут.
Как вызвать API?
Взаимодействие с API описано в нем самом. Создатели программного интерфейса обеспечат вас документацией, в которой подробно расскажут, как и что работает. Поэтому универсальной инструкции по вызову API не существует.
Это может выглядеть так, например:
А вот как выглядит запрос к API Yandex.SpeechKit (для озвучки текста):
Косвенные вызовы API
Выше были описаны методы вызова API напрямую. То есть разработчиком (или программой для тестирования функций). Они бывают разных типов, но все сводится к одной идее – работе непосредственно с кодом.
Но не только разработчики участвуют во взаимодействии с API. Пользователи тоже зачастую обращаются к интерфейсам. Банальная кнопка «Создать новую вкладку» в браузере – уже интерфейс (конкретно в этом случае – графический интерфейс). За ним так же скрывается набор функций, выполнение которых в конечном итоге приводит к появлению новой страницы в браузере.
Таких примеров масса. Можно брать в расчет любую возможность компьютера, которая непонятна обывателю. Вся эта «магия под капотом» как раз и есть API, с которыми на постоянной основе контактируют люди, далекие от программирования.
Особенности современного API
В развитии программных интерфейсов наблюдаются следующие тенденции:
Вместо заключения
API – программный стандарт, постепенно становящийся все более востребованным. Сервисы и приложения обрастают интерфейсами, поэтому к ним обязательно стоит найти подход.
Программистам, еще не освоившим работу с API, определенно стоит углубиться в эту тему и чаще их использовать, чтобы уметь быстро подключать сторонние решения в своих сервисах и уметь создавать качественные программные интерфейсы для уже существующих продуктов.
Краткое руководство. Создание функции Python в Azure с помощью Visual Studio Code
Из этой статьи вы узнаете, как создать функцию Python, которая отвечает на HTTP-запросы, используя Visual Studio Code. После тестирования кода в локальной среде его необходимо развернуть в бессерверной среде Функций Azure.
Выполнение этого краткого руководства предполагает небольшую дополнительную плату в несколько центов США в учетной записи Azure.
Существует также версия этой статьи для интерфейса командной строки.
Настройка среды
Перед началом работы убедитесь, что выполнены следующие предварительные требования.
Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно.
Расширение Python для Visual Studio Code.
Создание локального проекта
В этом разделе показано, как использовать Visual Studio Code, чтобы создать локальный проект Функций Azure на Python. Далее в этой статье вы опубликуете код функции в Azure.
Выберите расположение для рабочей области проекта и нажмите кнопку Выбрать.
Рассматриваемые в этой статье шаги выполняются вне рабочей области. В этом случае не нужно указывать папку проекта, которая является частью рабочей области.
Введите следующие сведения по соответствующим запросам:
Выберите псевдоним Python для создания виртуальной среды. Выберите расположение интерпретатора Python.
Если расположение не отображается, введите полный путь к двоичному файлу Python.
Используя эти сведения, Visual Studio Code создает проект функций Azure с триггером HTTP. Файлы локального проекта можно просмотреть в Explorer. Дополнительные сведения см. в разделе Generated project files (Созданные файлы проекта).
Локальное выполнение функции
Visual Studio Code интегрируется с Azure Functions Core Tools, чтобы перед публикацией в Azure можно было запустить этот проект на локальном компьютере разработки.
При возникновении проблем с запуском в Windows убедитесь, что в качестве терминала по умолчанию для Visual Studio Code не используется оболочка WSL.
В поле Ввести текст запроса вы увидите значение текста запроса < "name": "Azure" >. Нажмите клавишу ВВОД, чтобы отправить это сообщение запроса в свою функцию.
При выполнении функции локально и возврате ответа в Visual Studio Code отобразится уведомление. Сведения о выполнении функции отображаются на панели Терминал.
Убедившись, что функция выполняется правильно на локальном компьютере, опубликуйте проект в Azure с помощью Visual Studio Code.
Вход в Azure
Прежде чем публиковать приложение, необходимо войти в Azure.
Если вы уже выполнили вход, перейдите к следующему разделу.
При появлении запроса в браузере выберите учетную запись Azure и войдите в нее с помощью учетных данных.
Выполнив вход, можно закрыть новое окно браузера. Подписки, принадлежащие учетной записи Azure, отображаются на боковой панели.
Публикация проекта в Azure
В этом разделе показано создание приложения-функции и сопутствующих ресурсов в подписке Azure и последующее развертывание кода.
Публикация в существующее приложение-функцию перезаписывает содержимое этого приложения в Azure.
Щелкните значок Azure на панели действий, а затем в области Azure: Функции выберите кнопку Deploy to function app. (Развертывание в приложение-функцию).
Введите следующие сведения по соответствующим запросам:
Выбор папки. Выберите папку из рабочей области или перейдите к папке, содержащей приложение-функцию.
Этот элемент не отобразится, если вы уже открыли допустимое приложение-функцию.
Выбрать подписку. Выберите подписку, которую нужно использовать.
Если у вас только одна подписка, вы не увидите этот параметр.
Enter a globally unique name for the function app (Ввод глобально уникального имени для приложения-функции). Введите имя, допустимое в пути URL-адреса. Имя, которое вы вводите, проверяется, чтобы убедиться, что оно уникально в функциях Azure.
Select a location for new resources (Выбор расположения для новых ресурсов). Для повышения производительности выберите регион рядом с вами.
Расширение показывает в области уведомлений состояние отдельных ресурсов по мере их создания в Azure.
После завершения в вашей подписке создаются следующие ресурсы Azure с именами, производными от имени приложения-функции:
После создания приложения-функции и применения пакета развертывания отобразится уведомление.
По умолчанию ресурсы Azure, необходимые для приложения функции, создаются на основе указанного имени приложения функции. По умолчанию они также создаются в той же новой группе ресурсов, что и приложение-функция. Если необходимо настроить имена этих ресурсов либо повторно использовать существующие ресурсы, опубликуйте проект с дополнительными параметрами создания.
Выберите View Output (Просмотреть выходные данные) в уведомлении, чтобы просмотреть результаты создания и развертывания ресурсов Azure. Если вы пропустили уведомление, щелкните значок колокольчика в правом нижнем углу, чтобы снова просмотреть его.
Запуск функции в Azure
В поле Ввести текст запроса вы увидите значение текста запроса < "name": "Azure" >. Нажмите клавишу ВВОД, чтобы отправить это сообщение запроса в свою функцию.
При выполнении функции в Azure и возврате ответа в Visual Studio Code отобразится уведомление.
Очистка ресурсов
При переходе к следующему шагу и добавлении привязки очереди службы хранилища Azure к функции, вам потребуется сохранить все ресурсы, чтобы использовать их в будущем.
В противном случае выполните следующие действия, чтобы удалить приложение-функцию и связанные с ним ресурсы и избежать дополнительных расходов.
На вкладке Обзор выберите именованную ссылку рядом с полем Группа ресурсов.
На странице Resource group (Группа ресурсов) просмотрите список включенных ресурсов и убедитесь, что именно их требуется удалить.
Выберите Удалить группу ресурсов и следуйте инструкциям.
Удаление может занять несколько минут. После этого на несколько секунд появится уведомление. Кроме того, можно выбрать значок колокольчика в верхней части страницы, чтобы просмотреть уведомление.
Дополнительные сведения о затратах на использование Функций см. в статье Estimating Consumption plan costs (Оценка затрат на план потребления).
Дальнейшие действия
С помощью Visual Studio Code вы создали приложение-функцию с простой функцией, активируемой HTTP-запросом. В следующей статье показано, как расширить эту функцию путем подключения к службе хранилища Azure. Дополнительные сведения о подключении к другим службам Azure см. в статье Подключение функций к службам Azure с помощью привязок.
Как написать чистый код для Android
Дядя Боб говорил в своей книге: «Вы читаете эту статью по двум причинам. Во-первых, вы разработчик. Во-вторых, вы хотите стать лучше как разработчик».
Представьте, что вы в библиотеке и ищете книгу. Если издания рассортированы и каталогизированы, вы быстро найдёте нужное. А если у библиотеки приятный интерьер и архитектура, во время поиска вам будет особенно комфортно.
Так же и с кодом. Если вы хотите создать что-то хорошее, нужно уметь писать понятный код и организовывать его в проекте. Когда коллегам понадобится найти что-то в коде, будет достаточно посмотреть названия методов, классов и пекеджей, чтобы разобраться. И не придётся переписывать всё с нуля, махнув на вашу работу рукой.
Что такое чистый код
Как вы понимаете, недостаточно просто побыстрее написать приложение. Если другим разработчикам будет тяжело в нём разобраться, это просто увеличит технический долг.
Код можно назвать чистым, если его с ходу понимают другие разработчики. Тогда его можно читать и изменять, расширять и поддерживать.
Почему это важно
Код отражает ваш мыслительный процесс. Поэтому нужно стараться сделать код более простым и читаемым.
Основные характеристики чистого кода
Разница между умным разработчиком и профессиональным в том, что второй ставит читаемость во главу угла. Профессионалы используют весь свой опыт, чтобы писать код, который поймут остальные.
Создавайте говорящие названия
Выбор хорошего говорящего названия отнимает время, но в итоге экономит ещё больше. Название переменной, метода или класса должно отвечать на все основные вопросы. То есть объяснять, для чего этот класс (метод, переменная), что он делает и как его использовать. Если приходится пояснять что-то в комментариях — значит, название недостаточно говорящее. Посмотрим на пример:
Имена классов
Названия классов и объектов должны быть существительными типа Customer, WikiPage, Account, AddressParser. Избегайте в именах слов Manager, Processor, Data или Info, потому что они мало говорят о функциональности объекта. Не используйте глаголы.
Имена методов
В названиях методов как раз нужны глаголы типа postPayment, deletePage, save.
Используйте названия из предметной области
Если общепринятого термина нет, используйте название из предметной области. Тогда разработчик, который поддерживает ваш код, сможет спросить о его значении эксперта.
Комментарий автора статьи
Например, вы пишете софт для телекоммуникационного оборудования. Ваши области задачи (экспертизы, решения) — это текстовое и голосовое общение, видеосвязь. Неважно, на каком языке, как и на какой платформе вы пишете, — предметная область от этого не меняется. Если вы разрабатываете приложение для создания и продажи фотоконтента, то предметная область включает фотографию и e-commerce. Любой человек, который видит ваш код в первый раз, должен сразу понимать, чем занимается каждый класс, модуль или пекедж в вашем приложении. Думайте об этом, когда добавляете в название что-то из предметной области этого класса.
Пишем код, используя принципы SOLID
Эти принципы были введены в практику ООП Робертом Мартином, а SOLID — мнемоническая аббревиатура для них. Они описывают подход к проектированию простых, читаемых и надёжных программных решений не только в Android-разработке, но и в целом в объектно-ориентированном программировании.
Принцип единой ответственности (Single Responsibility Principle — SRP)
У класса должна быть одна задача. Изменить состояние класса можно только для того, чтобы выполнить конкретную задачу. Не добавляйте в класс функциональность просто потому, что можете. Если класс выполняет разные задачи — разбейте его на два или вынесите часть задач в другие классы. Избегайте божественных классов. Посмотрим на пример:
В классе RecyclerView.Adapter есть метод onBindViewHolder, который занимается посторонними задачами. Adapter должен только создавать ViewHolder и передавать в него данные. Он не должен обрабатывать эти данные в методе onBindViewHolder. Даже само название метода говорит нам об этом.
Принцип открытости-закрытости (Open-Closed Principle — OCP)
Классы должны быть открыты для расширения, но закрыты для изменения. Иными словами, если кто-то захочет внести коррективы в ваш класс А, то его можно расширить (отнаследоваться от него), но никак не менять напрямую.
Простой пример — тот же RecyclerView.Adapter. Вы можете отнаследоваться от него, чтобы создать свою имплементацию с необходимыми вам свойствами и поведением. Но вы не можете внести эти изменения непосредственно в RecyclerView.Adapter.
Принцип подстановки Барбары Лисков (Liskov Substitution Principle — LSP)
Класс-потомок никогда не изменяет поведение класса-родителя. То есть подкласс может переопределять методы родительского класса, только если это не меняет его функциональность.
Например, вы создаёте интерфейс, у которого есть метод onClick(). Затем вы имплементируете интерфейс в MyActivity, и когда onClick() вызовется — отобразите в нём Toast. Не прописывайте эту функциональность в интерфейсе. Дополняйте onClick(), только переопределяя его в классе-потомке.
Принцип разделения интерфейсов (Interface Segregation Principle — ISP)
Ни один наследник не должен имплементировать методы, которые он не использует. Если у вас есть класс или интерфейс А и вы имплементируете его в классе B, то не нужно переопределять все методы А в B.
Для примера рассмотрим имплементацию в вашей Activity SearchView.OnQueryTextListener(). Вам нужен оттуда только один метод, но там их два:
Как сделать так, чтобы вы не имплементировали ненужную функциональность? Отнаследуйтесь от SearchView.OnQueryTextListener(), создайте свой колбэк и передавайте дальше только то, что вам нужно:
Как это будет выглядеть в нашей Activity:
Или можно написать функцию-расширение, как это принято в Kotlin:
Как это будет выглядеть в Activity:
Принцип инверсии зависимостей (Dependency Inversion Principle — DIP)
Зависимости должны быть от абстракций, а не от конкретных имплементаций. Роберт Мартин приводит два аргумента:
Высокоуровневые модули, в которых прописана сложная бизнес-логика, должны легко переиспользоваться и не зависеть от изменений в низкоуровневых модулях. Чтобы это работало, вам нужно определить абстракции, которые отделяют высокоуровневые модули от низкоуровневых.
Простой пример — паттерн MVP, где вы определяете интерфейсы, которые помогают передавать данные из одного конкретного класса в другой. Это значит, что UI-часть (Activity/Fragment) не должна ничего знать о том, как именно работают методы Presenter. И если вы измените что-то в Presenter, Activity этого даже не заметит. Посмотрим на примере. Presenter имплементирует интерфейс:
То же самое в Activity:
Мы создали интерфейс, отделяющий имплементацию Presenter от Activity, которая содержит ссылку на интерфейс, а не на Presenter.
Если вы уже разрабатывали приложение, в котором были бессмысленные названия, божественные классы, спагетти-код — поверьте, я тоже такое делал. Поэтому и делюсь знаниями от Дяди Боба о чистом коде. Надеюсь, они вам помогут.
Дядя Боб говорил в своей книге: «Вы читаете эту статью по двум причинам. Во-первых, вы разработчик. Во-вторых, вы хотите стать лучше как разработчик».
Представьте, что вы в библиотеке и ищете книгу. Если издания рассортированы и каталогизированы, вы быстро найдёте нужное. А если у библиотеки приятный интерьер и архитектура, во время поиска вам будет особенно комфортно.
Так же и с кодом. Если вы хотите создать что-то хорошее, нужно уметь писать понятный код и организовывать его в проекте. Когда коллегам понадобится найти что-то в коде, будет достаточно посмотреть названия методов, классов и пекеджей, чтобы разобраться. И не придётся переписывать всё с нуля, махнув на вашу работу рукой.
Что такое чистый код
Как вы понимаете, недостаточно просто побыстрее написать приложение. Если другим разработчикам будет тяжело в нём разобраться, это просто увеличит технический долг.
Код можно назвать чистым, если его с ходу понимают другие разработчики. Тогда его можно читать и изменять, расширять и поддерживать.
Почему это важно
Код отражает ваш мыслительный процесс. Поэтому нужно стараться сделать код более простым и читаемым.
Основные характеристики чистого кода
Разница между умным разработчиком и профессиональным в том, что второй ставит читаемость во главу угла. Профессионалы используют весь свой опыт, чтобы писать код, который поймут остальные.
Создавайте говорящие названия
Выбор хорошего говорящего названия отнимает время, но в итоге экономит ещё больше. Название переменной, метода или класса должно отвечать на все основные вопросы. То есть объяснять, для чего этот класс (метод, переменная), что он делает и как его использовать. Если приходится пояснять что-то в комментариях — значит, название недостаточно говорящее. Посмотрим на пример:
Имена классов
Названия классов и объектов должны быть существительными типа Customer, WikiPage, Account, AddressParser. Избегайте в именах слов Manager, Processor, Data или Info, потому что они мало говорят о функциональности объекта. Не используйте глаголы.
Имена методов
В названиях методов как раз нужны глаголы типа postPayment, deletePage, save.
Используйте названия из предметной области
Если общепринятого термина нет, используйте название из предметной области. Тогда разработчик, который поддерживает ваш код, сможет спросить о его значении эксперта.
Комментарий автора статьи
Например, вы пишете софт для телекоммуникационного оборудования. Ваши области задачи (экспертизы, решения) — это текстовое и голосовое общение, видеосвязь. Неважно, на каком языке, как и на какой платформе вы пишете, — предметная область от этого не меняется. Если вы разрабатываете приложение для создания и продажи фотоконтента, то предметная область включает фотографию и e-commerce. Любой человек, который видит ваш код в первый раз, должен сразу понимать, чем занимается каждый класс, модуль или пекедж в вашем приложении. Думайте об этом, когда добавляете в название что-то из предметной области этого класса.
Пишем код, используя принципы SOLID
Эти принципы были введены в практику ООП Робертом Мартином, а SOLID — мнемоническая аббревиатура для них. Они описывают подход к проектированию простых, читаемых и надёжных программных решений не только в Android-разработке, но и в целом в объектно-ориентированном программировании.
Принцип единой ответственности (Single Responsibility Principle — SRP)
У класса должна быть одна задача. Изменить состояние класса можно только для того, чтобы выполнить конкретную задачу. Не добавляйте в класс функциональность просто потому, что можете. Если класс выполняет разные задачи — разбейте его на два или вынесите часть задач в другие классы. Избегайте божественных классов. Посмотрим на пример:
В классе RecyclerView.Adapter есть метод onBindViewHolder, который занимается посторонними задачами. Adapter должен только создавать ViewHolder и передавать в него данные. Он не должен обрабатывать эти данные в методе onBindViewHolder. Даже само название метода говорит нам об этом.
Принцип открытости-закрытости (Open-Closed Principle — OCP)
Классы должны быть открыты для расширения, но закрыты для изменения. Иными словами, если кто-то захочет внести коррективы в ваш класс А, то его можно расширить (отнаследоваться от него), но никак не менять напрямую.
Простой пример — тот же RecyclerView.Adapter. Вы можете отнаследоваться от него, чтобы создать свою имплементацию с необходимыми вам свойствами и поведением. Но вы не можете внести эти изменения непосредственно в RecyclerView.Adapter.
Принцип подстановки Барбары Лисков (Liskov Substitution Principle — LSP)
Класс-потомок никогда не изменяет поведение класса-родителя. То есть подкласс может переопределять методы родительского класса, только если это не меняет его функциональность.
Например, вы создаёте интерфейс, у которого есть метод onClick(). Затем вы имплементируете интерфейс в MyActivity, и когда onClick() вызовется — отобразите в нём Toast. Не прописывайте эту функциональность в интерфейсе. Дополняйте onClick(), только переопределяя его в классе-потомке.
Принцип разделения интерфейсов (Interface Segregation Principle — ISP)
Ни один наследник не должен имплементировать методы, которые он не использует. Если у вас есть класс или интерфейс А и вы имплементируете его в классе B, то не нужно переопределять все методы А в B.
Для примера рассмотрим имплементацию в вашей Activity SearchView.OnQueryTextListener(). Вам нужен оттуда только один метод, но там их два:
Как сделать так, чтобы вы не имплементировали ненужную функциональность? Отнаследуйтесь от SearchView.OnQueryTextListener(), создайте свой колбэк и передавайте дальше только то, что вам нужно:
Как это будет выглядеть в нашей Activity:
Или можно написать функцию-расширение, как это принято в Kotlin:
Как это будет выглядеть в Activity:
Принцип инверсии зависимостей (Dependency Inversion Principle — DIP)
Зависимости должны быть от абстракций, а не от конкретных имплементаций. Роберт Мартин приводит два аргумента:
Высокоуровневые модули, в которых прописана сложная бизнес-логика, должны легко переиспользоваться и не зависеть от изменений в низкоуровневых модулях. Чтобы это работало, вам нужно определить абстракции, которые отделяют высокоуровневые модули от низкоуровневых.
Простой пример — паттерн MVP, где вы определяете интерфейсы, которые помогают передавать данные из одного конкретного класса в другой. Это значит, что UI-часть (Activity/Fragment) не должна ничего знать о том, как именно работают методы Presenter. И если вы измените что-то в Presenter, Activity этого даже не заметит. Посмотрим на примере. Presenter имплементирует интерфейс:
То же самое в Activity:
Мы создали интерфейс, отделяющий имплементацию Presenter от Activity, которая содержит ссылку на интерфейс, а не на Presenter.
Если вы уже разрабатывали приложение, в котором были бессмысленные названия, божественные классы, спагетти-код — поверьте, я тоже такое делал. Поэтому и делюсь знаниями от Дяди Боба о чистом коде. Надеюсь, они вам помогут.