Курсы андроид разработчиков от яндекса

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Как стать программистом за 60 секунд или «Яндекс.Практикум» — НЕ ковчег судьбы

От автора

В данной статье я не хочу пытаться что-то доказать или опровергнуть, моя цель и мотивация лишь поделиться своими впечатлениями от сервиса по On-line образованию от «Яндекса» по направлению «WEB-разработчик», но суть статьи, как мне кажется, в целом о сервисе «Яндекс.Практикум». Я так же ни к чему не призываю и не от чего не отговариваю, хотя все же не так… призываю думать своей головой – говорят это полезно. Да бы вы не умерли от скуки читая очередную статью, постараюсь добавить немного юмора.

Погнали наши городских

Итак дорогой друг, если ты читаешь эту статью, то скорее всего ты так же как и я решил стать «программистом», и попытавшись самостоятельно разобраться во всех тонкостях программирования и твёрдо решив стать «мидлом», а если попрёт то может даже «сеньёром-помидором» за 1 год, но быстро понял что как то не очень получается и решил попробовать сервис от Яндекса — «Яндекс.Практикум». Так вот постараюсь максимально однозначно ответить на твой вполне логичный вопрос: «Стоит ли платить свои кровные бабосики за данный продукт».

Что могу сказать сразу, над чем Яндекс точно хорошо поработал, так это над маркетингом. Чего стоит только название — «Яндекс.Практикум», что должно явно натолкнуть на мысль что тут только нужная инфа про то, на какие кнопки нужно тыкать, что бы стать реальным программистом, а всякая ерунда по типу лекций и прочей ерундистики где «слишкоммногобукв» не применяется. Спешу разочаровать очарованных, теория присутствует в сжатом виде, ну как сжатом…. если ты не хочешь во всём разбираться, а просто пролететь курс по-быстрому — то сойдет, а так будь бобром почитать литературу на внешних сайтах, ссылочки тебе предоставят, и их будет много… очень много и в том числе на английском языке, а ты как хотел быть программистом без знаний английского языка что ли? И о боже да!, это все БЕСПЛАТНЫЕ ресурсы, которые находятся тем же поиском «Яндекса» или «Google», главное сформулировать запрос, если конечно он у тебя есть. Может быть ты используешь «Mail.ru» — но тут уже ничего не поделать.

Едем дальше…

Ох как же круто и звучно «У Вас будет НАСТАВНИК!» и сразу вспоминается фильм где тренер кричит: «Вставай уткин сын», и он встаёт. и конечно наносит сокрушительный удар сопернику, или что-то про альпинизм, где сильный лидер на себе вытащит раненого на самую вершину, где они крепко обнимутся… Но жизнь есть жизнь и в ней все иначе… Наставник тоже человек для которого «наставничество» способ подзаработать или это человек которого прет тема программирования и он хочет поделиться и делает это круто, что шансов не понять материал у тебя нет (привет Серёге Болтрукевичу!), тут уж как повезет… Но что точно сделают наставники так это вытащат твою ленивую и даже в некоторых случаях глупую задницу голову на очередном дедлайне. Иногда, даже сразу, совершенно не парясь, скинут готовый код в личку Slack. В твоей голове, конечно, промелькнет мысль – «Как круто», но фишка тут вовсе не с том, что наставник к тебе очень хорошо относится, может даже чуть лучше, чем ко всем остальным, ну вы понимаете о чем я=)… нееет дело тут в другом, ведь чем дольше тянут твою жопу попу в потоке, тем больше с тебя списывают баблица, а уж за регулярностью платежей следят отлично. Ничего личного, бизнес есть бизнес, а собственные правил для того и нужны что бы их нарушать.

Но на этом полномочия наставников ещё не всё, раз в две недели тебе лично, дорогой друг, и всему потоку заодно, нет-нет не группе, а именно потоку, ну или когорте как они это называют (хрен редьки, то не слаще) проведут вебинар, и даже назовут его «Live-кодинг», только кодить будешь не ты, а кто-то из наставников, разбирать будут пример (чисто случайно конечно) один в один из практической работы. И при это, если наставник будет по типу №1, смотри описание выше, то ждет вас умопомрачительное зрелище как человек с умным видом тупит в заранее подготовленный код.

Единственный соратник, который помогает тебе на поприще становления тебя как программиста, это тот человек которого ты возненавидишь всей душой, о да это мать его — «Ревьювер», он покажет тебе всё, где ты неправильно списал из тренажера и заставит написать так как написано в тренажере, даже если ты проявишь немыслимые мысли и напишешь так как будут писать через 10 лет в Google, то всё равно тебе это придется переписывать точно так, как в тренажере, ибо как говориться: «Парламент не место для дискуссий!». Но в целом с этими ребятами проблем нет, они тебе помогут если ты хочешь, и заставят если не очень…

Ваша остановка следующая

Подведу итог выше изложенного и как обещал отвечу на твой вопрос – «стоит оно того?». Чудес как известно не бывает и «Яндекс.Практикум» это не панацея, если ты уже давно хотел перейти в ИТ и все как то, то тут не так то там не то, здесь почесал, то тут погладил — НЕ ТРАТЬ ДЕНЬГИ! Открою страшный секрет, только тссс… весь материал «Практикума» ГУГЛИТСЯ! И если тебя приспичит найти ответ на свой вопрос – ты его обязательно найдешь и последнее место где будешь его искать это лекции Яндекса. Проблема только в том что ты – ленивая жопа попа, не хочешь приложить усилия в своем развитии, ты хочешь что бы тебе ВСЁ дали на блюдечке с голубой каёмочкой, а так не бывает! История с раненым альпинистом почти всегда заканчивается его смертью, потому что сильный лидер найдет в себе силы оставить раненого, что бы спасти жизнь остальной группе, даже если их в этой группе двое. И если раненый альпинист не станет САМОСТОЯТЕЛЬНО сражаться за СВОЮ жизнь, он умрёт без вариантов… Всем рекомендую фильм «Касаясь пустоты».

А если ты не такой как я описал выше, ты не ленивая попа, а очень даже старательная попенция, которой просто не хватает немножко знаний и практики что бы вот-вот стать программистом, отвечу – НЕ ТРАТЬ ДЕНЬГИ! Начни свой проект, пусть он будет небольшой, но твой и бесплатный, а дока на React.JS и Google тебе в помощь и делай, делай, и делай… потом возьмись за маленький и дешёвый, а может и даже совсем бесплатный проект и делай, делай, и делай… только так и НИКАК иначе ты сможешь стать тем кем так хочешь! Все остальное от лукавого, как бы сказал Ленин=)!

И что же, грустно выдохнув, спросишь ты, «Яндекс.Практикум» совсем, совсем никому не подходит? Почему же, конечно подходит, и в первую очередь тем, у кого тяжело в кармане, ну да-да есть те для кого 200т.р. и 300т.р. и более, сумма в принципе не большая и можно разок другой в бар не сходить и заплатить за очередной сервис Яндекса. Спорить тут не о чем, Вам советую СМЕЛО! Еще если вы студен и можете «потянуть», ну либо ваши родители могут «потянуть» то может быть данный курс расширит Ваш кругозор, если конечно его ранее кто-то уже не расширил (привет Эдуард Суровый!), и даст дополнительную корочку, на которую не посмотрят или посмотрят мельком и перейдут к реальным кейсам из вашего портфолио.

Последний Скрип

В общем «Яндекс.Практикум», думаю как и другие подобные продукты, лишь продукт маркетологов. А уж клюнут или нет на эту удочку решать все-таки тебе, дорогой друг. Я вот попался, думаю что подсекли меня из-за былого доверия в целом к «Яндексу» или как сейчас принято говорить в среде гладко выбритых снизу — «экосистеме». Так что можно считать что за свои деньги я получил:

Курс «программирования» от Практикума». Не буду говорить хороший или плохой, так как не с чем сравнивать, а все познается в сравнении, в моём опыте он такой, как я описал выше.

Хорошую по качеству, но с хреновым принятом футболку. Эх Морфеус, Морфеус где же ты когда ты мне так нужен, сказал бы я, если бы Морфеус был бы дизайнером…

Опыт. Не встречал ещё ни одного человека, который бы учился только на чужом опыте, но встречал очень много тех кто, наступив в пятый раз на те же грабли радуется, что их еще не украли.

Источник

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

Уже очень скоро завершится набор в Школу мобильной разработки, которая традиционно пройдет в Москве. Упор в ней будет сделан на практические занятия — командные мини-хакатоны, в которых помимо написания кода нужно будет принимать решения, разбираться с возникшими спорными вопросами и заниматься долгосрочным планированием. Помогать студентам — каждой команде индивидуально — будут ребята из Яндекса. Более подробно о предстоящей школе можно почитать здесь. Мы закончим принимать заявки 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.

Источник