Школа андроид разработки яндекс

Новый набор в Школу мобильной разработки

Летом в нашем московском офисе откроется бесплатная Школа мобильной разработки. Она будет посвящена созданию приложений для Android. Преподаватели ШМР — программисты Яндекса: они расскажут про разные подходы к разработке, научат пользоваться инструментарием и объяснят, как грамотно спроектировать интерфейс приложения и провести тестирование.

Программа Школы составлена так, чтобы полученные знания можно было сразу применить в деле. Поэтому будет много практических заданий: их нужно будет выполнять на занятиях и дома. У слушателей будет возможность обменяться опытом не только с преподавателями, но и друг с другом — для этого мы предусмотрели коллективные форматы работы: хакатоны и «круглые столы».

На занятиях в Школе мобильной разработки, 2016 год

Школа мобильной разработки рассчитана на тех, кто уже пробовал сам делать приложения — даже если это был просто эксперимент «для себя». Кроме того, потребуются владение алгоритмами и базовые знания Java — этот язык необходим, чтобы в полной мере усваивать материал на занятиях. Если вы владеете и другими языками программирования, это будет дополнительным плюсом.

Занятия в Школе начнутся в июле. Они будут проходить по вечерам, после 19:00, в будние дни и по субботам, так что учёбу можно совмещать с работой. В ШМР можно поступать в любом возрасте и с любым образованием: дипломы и аттестаты мы не проверяем. Жителям других городов, которые успешно прошли отбор в Школу, Яндекс оплатит дорогу до Москвы и проживание на время обучения.

Перед занятиями рекомендуем посмотреть лекции, прочитанные в ШМР в 2016 и 2017 годах. Освежить знания Java помогут видеокурсы: для начинающих от Computer Science Center и для более продвинутых от JetBrains. Кроме того, у Computer Science Center есть отличный курс по алгоритмам.

Для поступления в Школу мобильной разработки нужно заполнить анкету и выполнить тестовое задание — создать мобильное приложение-галерею, опираясь на описание и скриншоты. После отправки задания система предложит вам пройти контест на знание алгоритмов. Это необязательный этап, но хорошие результаты дадут вам дополнительные очки. Набор в ШМР открыт до 6 мая.

Источник

Школа мобильной разработки

Чтобы не пропустить набор на следующую Школу, оставьте заявку. Мы обязательно сообщим о начале регистрации.

Приём анкет в Школу мобильной разработки 2021 закрыт.

Летом 2021 года Яндекс запустит одновременно пять школ в Москве: Школу разработки интерфейсов, Школу бэкенд-разработки, Школу мобильной разработки, Школу дизайна и Школу менеджеров. У студентов будет возможность объединиться и вместе поработать над реальными проектами Яндекса.

Обучение пройдёт с 31 мая по 31 августа.

В школе будет представлено 2 направления:

• Разработка под Android
• Разработка под iOS

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

Мы приглашаем начинающих мобильных разработчиков, готовых получать новые знания.

Для поступления в школу iOS-разработчикам нужны базовые знания Swift. Опыт создания приложений для iOS будет преимуществом.

Мы ждем, что у Android-разработчиков есть начальный опыт написания мобильных приложений на Java или Kotlin.

Опыт программирования на других языках и знание алгоритмов будет плюсом для обоих направлений.

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

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

Занятия будут проходить очно в московском офисе Яндекса.

Мы оплатим проезд и проживание иногородним кандидатам, которые отлично справились со вступительным заданием.

Отбор в школу проходит на конкурсной основе. Чтобы поступить, нужно подать заявку и справиться со вступительным испытанием до 29 марта 23:59 по московскому времени.

Вступительное испытание состоит из двух частей:

● тестовой — за ограниченное время решить несколько задач на платформе Яндекс.Контест;

● проектной — в зависимости от выбранного направления. Android-разработчикам потребуется создать приложение на Kotlin или Java, а iOS-разработчикам — выполнить задание на выбор: создать игру в консоли на Swift или приложение (если есть возможность использовать Xcode).

Источник

Бесплатное обучение от Яндекса, о котором вы могли не знать

Меня зовут Артём Сайгин, я веду телеграм канал Growth lab, в котором рассказываю о маркетинге и росте IT-продуктов.

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

Статья будет полезна тем, кто только начинает путь в IT и тем, кто хочет научиться чему-то новому.

Академия имеет несколько школ, набор в которые открывается один (или несколько) раз в год. Обучение бесплатное, но есть условия приёма в школу: нужно подать заявку, выполнить тестовое задание и дождаться результатов отбора. Подробнее об поступлении почитайте на сайте школы.

Какие есть школы:

Школа мобильной разработки — имеет два направления: разработка по IOS и разработка под Android.

Школа дизайна — также представлено два направления: продуктовый
дизайн и коммуникаций.

Школа менеджеров Яндекса — представляет аж три направления: управление проектами и продуктами, маркетинг, продуктовая аналитика.

Школа анализа данных — это бесплатная программа и длиться она два года. Рассчитана на тех, кто хочет стать продвинутым датасаентистом или архитектором систем хранения и обработки больших данных.

Так что, если интересно изучить новую профессию, или вы только начинаете свой путь в IT-индустрии — вэлкам. Очень хороший старт и возможность поработать с реальными продуктами Яндекса.

Второе — курсы на coursera.

Источник

Открываем четыре Школы: разработки интерфейсов, бэкенда, мобильной разработки и дизайна

В 2012 году трое руководителей разработки, включая меня, решились на авантюру по созданию собственного образовательного проекта. Так появилась Школа разработки интерфейсов. Спустя девять лет и одну пандемию проект живёт, и сегодня я с радостью приглашаю вас в ШРИ 2021. Но тут же должен оговориться: на Хабре я выступаю рупором для ещё нескольких моих коллег, которые курируют школы по своим направлениям. В Школе мобильной разработки будем обучать специалистов по iOS и Android — за это направление отвечает Илья Богин bryunyon, руководитель разработки приложения Яндекс и мобильного Браузера. Школа бэкенда ориентирована в основном на Python, ей заведует Александр Кошелев daevaorn (в Яндексе Саша руководит созданием сервисов для организаций). За Школу дизайна отвечают сразу трое тимлидов — Денис Мосин, Илья Александров и Дима Быков comajumper.

У Яндекса и у меня лично уже был опыт одновременного проведения школ для нескольких специализаций. Возможно, кто-то помнит проект «Мобилизация» 2016-2017 года: тогда тоже запускались сразу четыре школы. Да и в последние годы мы часто объединяли студентов разных направлений в команды для сдачи выпускного проекта. Эта базовая конфигурация сохранится: в первой половине обучения (она же — первая половина лета-2021) будут лекции, семинары и небольшая практика в каждой из школ отдельно, а затем все студенты соберутся в команды, чтобы делать совместный продакшен-проект. В любой команде будет бэкенд-разработчик, дизайнер, а также фронтенд- или мобильный разработчик. Защиты проектов пройдут в самом конце августа.

Чтобы поступить, нужно заполнить анкету. 15 февраля мы опубликуем тестовое задание, ответы на которое будем принимать до 29 марта (возможно, продлим срок на неделю — в зависимости от числа желающих). Вот какие знания нужны для учёбы:

Школа разработки интерфейсов

Нужно знать HTML, CSS и JavaScript и иметь опыт разработки интерфейсов — подойдет даже небольшой.

Книги
— Кит Грант — CSS для профи
— Николас Закас — JavaScript для профессиональных веб-разработчиков
— Николас Закас — ECMAScript 6 для разработчиков
— Кайл Симпсон — Вы не знаете JavaScript
— Роберт Мартин — Идеальный программист
— Пассиг Катрин, Яндер Йоханнес — Программирование без дураков

Попробовать себя в решении задач можно на CodeSignal и Codewars.

Школа мобильной разработки

iOS-разработчикам нужно иметь базовые знания Swift. Для Android важен начальный опыт написания мобильных приложений на Java или Kotlin. Опыт программирования на других языках и знание алгоритмов будет плюсом для обоих направлений.

Android

Книги
— Joshua Bloch — Effective Java
— Marcin Moskala — Effective Kotlin. Best practices
— Brian Goetz — Java Concurrency in Practice
— Dmitry Jemerov, Svetlana Isakova — Kotlin in Action
— The Busy Coder’s Guide to Android Development (справочник на все случаи жизни)

Книги
— Нахавандипур Вандад — iOS. Приемы программирования
— Во Ханг — Оптимизация производительности для iOS
— App Development with Swift
— The Swift Programming Language
— SwiftBook

Полезные сайты для обеих платформ

Школа бэкенд-разработки

Нужно знать основы Python, понимать, как приложения развёртываются на серверах, уметь делать запросы к базам данных и хотя бы на начальном уровне знать, как создаются веб‑приложения.

— Марк Лутц — Изучаем Python

Марк написал эту книгу по мотивам собственных курсов, которые ведёт уже более десяти лет. Здесь всё важное: обзор инструментов, типы объектов, функции плюс описания моделей и инструкции по обработке исключений.

— Антонио Меле — Django 2 в примерах

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

— Если вы можете свободно читать профильную литературу на английском, то порекомендуем пару книг о разработке на основе тестов: Harry Percival — Test-Driven Development with Python; Kevin Harvey — Test-Driven Development with Django.

— Тони Гэддис — Начинаем программировать на Python

Тимофей — один из преподавателей МФТИ. Лекций по алгоритмам множество, но эти наглядные. Особенно полезны для новичков, но и разработчику с опытом тоже пригодятся.

Школа дизайна

У Школы есть два направления — дизайн продукта и дизайн коммуникаций. Для поступления в школу продуктового дизайна нужно уметь работать в Figma и иметь хотя бы небольшой опыт в дизайне мобильных приложений или сайтов. Умение собирать динамические прототипы и работать с компонентами будет преимуществом.

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

Книги для продуктового дизайнера
— Илья Бирман — Пользовательский интерфейс
— Дональд Норман — Дизайн привычных вещей
— Эд Кэтмелл — Корпорация гениев. Как управлять командой творческих людей
— Адам Ватан, Стив Шогер — Рефакторинг пользовательского интерфейса
— Тим Браун — Дизайн-мышление в бизнесе
— Алан Купер — Об интерфейсе
— Кимберли Элам — Графический дизайн. Принцип сетки

Книги для дизайнера коммуникаций
— Майкл Джанда — Сожги свое портфолио! То, чему не учат в дизайнерских школах
— Вилли Кунц — Типографика: макро- и микроэстетика
— Юрий Гордон — Книги про буквы от Аа до Яя
— Пол Рэнд — Дизайн: форма и хаос
— Все книги Эдварда Тафти
— Ян Чихольд — Облик книги
— Эмиль Рудер — Типографика
— Джим Кэмп — Сначала скажите «нет»
— Дмитрий Чернышёв — Как люди думают
— Артемий Лебедев — Ководство

Полезные сайты
— Подобрать сочетающиеся шрифты — Fontjoy
— Найти бесплатные иконки — Flaticon
— Подобрать цветовую гамму — Coolors
— Распознать и скачать понравившийся шрифт — Font Squirrel
— Вдохновиться примерами чужих логотипов — Logobook
— Создать инфографику — Infogram
— Попробовать себя в прототипировании — Figma

Посмотрим, позволит ли обстановка провести все занятия в офлайне в московском офисе. Если нет — будем встречаться удалённо (возможно — с переходом в офлайн ближе к осени). Студентам из других городов оплатим переезд и проживание.

Я всегда говорил, что ШРИ и другие школы позволяют получить опыт промышленной разработки, релевантный для большой компании. С четырьмя потоками одновременно и богатым набором навыком в студенческих командах будет ещё круче. Желаю вам удачи!

Источник

Советы по созданию приложений к окончанию набора в Школу мобильной разработки Яндекса

Уже очень скоро завершится набор в Школу мобильной разработки, которая традиционно пройдет в Москве. Упор в ней будет сделан на практические занятия — командные мини-хакатоны, в которых помимо написания кода нужно будет принимать решения, разбираться с возникшими спорными вопросами и заниматься долгосрочным планированием. Помогать студентам — каждой команде индивидуально — будут ребята из Яндекса. Более подробно о предстоящей школе можно почитать здесь. Мы закончим принимать заявки 6 мая в 23:59 по московскому времени, а пока ещё есть время на выполнение заданий, мы решили разобрать прошлогодний вариант. Вы узнаете, какие ошибки часто допускают начинающие разработчики и чему следует уделить внимание при написании кода вашего первого приложения.

Традиционно задание построено так, чтобы мы могли обратить внимание на разные аспекты разработки. К ним относится архитектура приложения, стабильность, производительность, верстка, удобство использования. Все составляющие одинаково важны: даже идеально причесанный и разложенный на слои код с большой вероятностью не пройдет отбор, если возникнут проблемы в интерфейсе или падения в процессе выполнения базовых пользовательских сценариев. Универсального рецепта приготовления идеального приложения, которое гарантированно пройдёт отбор, нет. Есть множество подходов к разработке и разные варианты построения архитектуры, но одна из составляющих успеха — позитивные пользовательские ощущения. Продукт должен создавать впечатление законченности, независимо от того, сколько в нем полезной функциональности, экранов или элементов.

Содержание

Репозиторий и coding style

Театр начинается с вешалки, а проект — с репозитория.

Перед началом разработки добавьте соответствующий .gitignore-файл, чтобы лишние файлы точно не попали в ваш репозиторий. Например, не рекомендуется хранить в репозитории файл настроек вашей IDE, файлы с ключами для подписи приложения и любые логины и пароли.

Во время разработки следуйте золотой середине — не стоит коммитить полпроекта за раз, но и множества мелких коммитов по одной-двум строкам стоит избегать. Пишите понятные сообщения к каждому коммиту. Для отдельных фич стоит использовать ветки, чтобы разрабатывать фичи независимо и вcегда иметь актуальную (и работающую) версию приложения в master-ветке. Старайтесь сначала реализовать минимально необходимые фичи и лишь затем — все «красивости» и улучшения. Если вам нужно переключиться на другую ветку и вы не хотите коммитить незавершенный код (но и терять его не хотите), удобно использовать заначки.

Код пишется один раз, а читается многократно, поэтому важно, чтобы coding style и наименование переменных были адекватными. Оставляйте осмысленные комментарии, если они нужны, не добавляйте магические числа и не перемешивайте код из различных библиотек, которые делают одно и то же. Если код пишется одним разработчиком, то поддерживать общий стиль и подход легко, а в большой команде можно использовать анализаторы или сформировать свой стиль и закоммитить его в систему контроля версий, чтобы он подхватывался у каждого разработчика.

Вот на что еще стоит обратить внимание:

• хардкод, бесполезный код, закомментированный код,
• лишние вызовы super,
• лишние аннотации,
• отсутствующие аннотации,
• попадание в Release кода, необходимого только в Debug-сборке
• отсутствующий модификатор final,
• длинные методы,
• одинаковые методы,
• unused imports,
• new Something() без присваивания,
• magic numbers,
• копипаста, использование кода, которого вы не понимаете,
• и еще — юзайте lint.

SDK и библиотеки

Использование Android SDK и библиотек часто вызывает вопросы у начинающих разработчиков. Ниже мы перечислим некоторые типичные проблемы и их решения.

Неправильная работа со списками
Использовать LinearLayout + ScrollView для отображения множества однотипных вью — значит совершить ошибку. Такой способ создает нагрузку на память, все вью находятся в ней одновременно. Скролл начинает тормозить. Правильно в таком случае использовать как минимум ListView, а лучше — более продвинутый RecyclerView. Эти контейнеры обеспечивают переиспользование вью (с помощью механизма адаптера). Вью, которые в данный момент не видны пользователю, наполняются свежими данными.

Но и тут можно совершить ошибку. RecyclerView, в отличие от ListView, заставляет разработчика пользоваться паттерном ViewHolder. Как и следует из его названия, этот паттерн состоит в создании класса, объекты которого хранят ссылки на уже найденые в иерархии вью. Не следует вызывать findViewById каждый раз, когда нужно проставить некоторое значение. Нужно сделать это один раз, во время создания холдера.

Сохранение состояния
Ещё одна большая проблема начинающих — сохранение состояния приложения при смене конфигурации (например, когда меняется ориентация, язык, размер экрана и т. д.). Часто бывает, что новички не тестируют такие случаи. Это приводит к недовольству пользователя или даже крешам. Иногда разработчики останавливаются на фиксации ориентации — что, конечно, не спасает. Существует несколько способов поддержать смену конфигурации «из коробки». Не будем углубляться в это, всегда можно почитать документацию. Главное помнить, что такая проблема существует, тестировать, обращать внимание на диалоги (лучше использовать DialogFragment, а не AlertDialog), поскольку они тоже должны восстанавливать состояние. Нужно помнить, что хранить состояние экрана в персистентом хранилище (например, SharedPreferences) не рекомендуется. В итоге «чистый» запуск может привести к уже имеющемуся состоянию, а это не особо идиоматично.

Загрузка данных и кеширование
Ни для кого не секрет, что хождение в сеть на UI-потоке в Android запрещено. Для сети есть множество библиотек, например OkHttp, если у вас REST — добавьте Retrofit, а для загрузки картинок — Glide или Picasso. Таким образом, давно уже не нужно использовать HttpUrlConnection внутри AsyncTask (особенно для загрузки картинок — что на самом деле непросто). Но многие начинающие не задумываются, что, например, чтение и запись в БД — это тоже I/O-операция, которая может сказаться на UX из-за фризов главного потока. То же самое относится к чтению файлов, доступу к ContentProviders. Все подобные операции должны происходить в отдельном потоке. Что для этого использовать — каждый решает сам, описать всё разнообразие решений в этом формате не представляется возможным.

Изменение системного поведения кнопки Back
Часто возникает соблазн повесить туда нестандартную для системы реакцию, в том числе полностью проглотить это событие (обработать, но ничего при этом не сделать). Так вот — лучше не надо. У пользователя этой ОС есть привычки, и Back должна вести на предыдущий экран или приводить к выходу из приложения.

Архитектура

Архитектура Android-приложения часто бывает больным местом даже для опытных разработчиков. В этом разделе мы дадим несколько общих советов. Следовать ли им — решаете вы.

Архитектура и декомпозиция
Отсутствие декомпозиции — признак плохой архитектуры. Платформа не дает четких указаний, как правильно писать приложения, поэтому есть большой соблазн писать весь в код в Activity или Fragment. В итоге такой код становится нетестируемым, тяжело вносить любые изменения. Чтобы этого избежать, можно применять современные архитектурные практики и шаблоны проектирования. Почитайте про MVP, MVVM, MVI. Напишите первые три класса и покройте их тестами. Вы наверняка заметите, что писать тесты сложно и нужно думать над архитектурой.

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

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

UI (ресурсы, графика, верстка)

Внешний вид и удобство пользования приложением имеют очень большое значение. Удобный дизайн сделать сложно, но советуем обратить внимание хотя бы на моменты, изложенные ниже.

Качество верстки

Быстродействие в Android довольно сильно зависит от качества верстки. Сложные иерархии контейнеров дольше обсчитываются. Кроме того, при большой вложенности возможны падения во время обсчета и отрисовки (из-за переполнения стека). С появлением ConstraintLayout (и особенно c установкой его корневым элементом xml при создании из визарда) у новичков значительно усложнились иерархии. Чаще используются вложенные Relative/ConstraintLayout, что в корне неверно. ConstraintLayout предназначен как раз для того, чтобы делать иерархию плоской. Рекомендуем прочитать хотя бы введение в документацию. Старайтесь применять этот класс правильно и избегайте излишней вложенности ViewGroup.

Дизайн

Не у всех разработчиков есть навыки дизайнера. Часто в приложении можно увидеть неконсистентную цветовую палитру, которая нравится разработчику, но большинству пользователей — нет. Бывает, что надписи не могут прочесть не только люди с ограниченными возможностями (например, дальтоники), но и остальные пользователи. Стандартная проверка: если надписи видны в grayscale, скорее всего, большинство пользователей тоже их разглядят. Для выбора палитры цветов и общих принципов дизайна можно посмотреть две ссылки: material.io и www.materialpalette.com.

Что еще стоит сделать

Обработка ошибок

Армия пользователей вашего приложения, как хороший тестировщик, всегда найдет способ сломать вам что-нибудь. Обязательно проверяйте работу приложения в нестандартных ситуациях. Важно развивать в себе склад ума тестировщика и предвидеть всевозможные нестандартные сценарии использования (запуск без интернета, добавление записи в историю два раза, внезапная смена настроек устройства и т. п.). После окончания работы над какой-либо функциональностью важно эту функциональность протестировать и прогнать несколько сценариев, чтобы убедиться, что все работает. Проблема в том, что тестировать свой код сложно, так как есть внутреннее ощущение и надежда, что все работает правильно. Никто же не хочет писать неработающий код. Не стоит идти на поводу у своих ощущений. Лучше проверить несколько сценариев с обычными и пограничными условиями.

При обработке ошибок можно впасть в две крайности — обрабатывать всё и вся не задумываясь или не обрабатывать ничего. Второй вариант, очевидно, всплывает довольно быстро, а вот первый более коварен и приводит к непредсказуемым последствиям.

Остановимся немного подробнее на некоторых примерах таких ошибок.

try..catch. everywhere

Такая обработка, как следует из названия, состоит в заключении любого подозрительного (с точки зрения автора) кода в блок try..catch. Под раздачу попадают NPE и IndexOutOfBoundsException, IllegalArgumentException и даже OutOfMemoryError, то есть исключения, которые обычно говорят о логических ошибках в приложении, о состояниях приложения, из которых нельзя адекватно восстановить его работу. Конечно, правильным решением будет исправление логических ошибок. Кроме того, при написании кода на Java можно воспользоваться статическим анализом и проставить, как минимум, аннотации @NonNull и Nullable везде, где нужно. Это поможет отловить NPE.

WeakReference

Часто новички, узнав об утечках памяти, начинают бояться их как огня. При недостатке опыта это может обернуться оборачиванием любых объектов в WeakReference. Обычно такой прием говорит о плохом понимании жизненного цикла объектов и связей между ними. Вот пример:

Здесь в конструктор адаптера приходит ссылка на Context. Но адаптер — это часть UI, который показан в некой Activity. Следовательно, он не должен жить дольше, чем Context, а из этого следует, что WeakReference здесь не нужна.

Другой пример исопльзования WeakReference:

С виду ничего не изменилось, но AsyncTask способна пережить Activity, в которой она была создана. Следовательно, использование WeakReference здесь обосновано.

Чтобы избежать утечек памяти, в первую очередь следует понимать, каков жизненный цикл объектов, которые вы используете. Для поиска утечек памяти в существующем большом проекте можно использовать Memory Profiler и LeakCanary.

Отсутствие отмены запросов

Иногда причина ошибок кроется в отсутствии отмены асинхронных операций, сетевых запросов или таймеров. Учитывайте долговременность и периодичность этих операций, обращайте внимание на парные методы API вроде subscribe/unsubscribe, create/destroy, start/cancel.

Тесты

Отсутствие юнит-тестов

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

Каждый из перечисленных пунктов можно оспорить. Начнем с пункта про временные затраты. Возможно, в самом начале написание юнит-тестов будет отнимать много времени, но с опытом скорость будет расти. Кроме того, юнит-тесты — инвестиция в будущее, которая в дальнейшем позволит писать код быстрее. Проблема со скоростью запуска решается еще проще: достаточно один раз настроить Continuous Integration и прогонять тесты автоматически. Если юнит-тесты сложно писать, значит, вы пишете не самый качественный код. Хорошая архитектура облегчает задачу.

Бесполезные тесты

Бесполезные тесты не только затрудняют понимание исходного кода, но и влияют на время сборки приложения, так что это даже хуже, чем бесполезный код. Можно выделить несколько случаев, когда тесты бесполезны:

Тестирование чужого кода
Предполагается, что чужой код уже поставляется с тестами, поэтому такое тестирование только отнимает время.

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

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

Заключение

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

• Внесение исправлений в последнюю минуту без проверки работоспособности.
• Отсутствие или некорректность обработки ошибок в коде.
• Неверная трактовка описания метода API, упущение из виду каких-нибудь особенностей работы или ограничений компонентов платформы.
• Недостаточная внимательность при организации связей между компонентами, при работе со ссылками и при учете жизненного цикла объектов.
• Использование новых непроверенных технологий.

Всем поступающим в школу в этом году и тем, кто разрабатывает свое первое приложение, мы рекомендуем:

• Быть внимательнее и проверять работоспособность приложения даже после внесения безобидных с виду изменений.
• Изучать тонкости языка: принципы работы с объектами в памяти, виды ссылок.
• Использовать статический анализатор кода и дополнительные инструменты вроде LeakCanary.
• Изучать ограничения и особенности работы используемых компонентов платформы и библиотек.
• С осторожностью использовать новые технологии, не успевшие себя зарекомендовать на известных проектах. API или код может быть нестабильным, в сети может не найтись документации или разборов типовых ошибок, ответы на вопросы придется искать самостоятельно.

Полезные ссылки

Cовсем начинающему разработчику, который не написал ни единой строчки для Android, полезно начать свой путь с курсов от Google на Udacity (на английском с русскими субтитрами). Если не бросите курс после первых несколько видео и пройдёте его до конца, то получите не только хорошие теоретические знания, но и первое приложение, которые вы сделали сами!

YouTube-канал Android Developers — просто кладезь коротких обучающих видео и новостей из мира Android-разработки. Советуем посмотреть Android Perfomance Patterns, ведь производительность важна, не так ли?

Чтобы не отставать от трендов и всегда знать, куда развиваться дальше, можно каждую неделю по чуть-чуть учиться новому с помощью рассылки Android Weekly (на английском) или слушать по дороге домой подкасты, например Fragmented и AndroidDevPodcast.

Знакомство с Kotlin лучше всего начать с Kotlin koans — можно получить представления о базовом синтаксисе языка. А видеокурс от Computer Science Center стоит пройти, чтобы подробнее изучить язык, узнать о его плюсах и минусах, понять, почему он реализован именно так. В случае с Java также есть фундаментальный курс от Computer Science Center — теоретические знания подкрепляются с помощью большого количества практических заданий.

Посмотреть на реализации распространнёных архитектур можно в репозитории Android Architecture Blueprints.

Для изучения архитектурных паттернов часто рекомендуют книги, которые новичку сложно осилить. Для первого знакомства идеально подходит SourceMaking — материал хорошо структурирован, а к большинству паттернов есть понятные метафоры и примеры реализации на Java.

Источник