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

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

Очень частая ошибка — хранение данных в Activity. Почему это проблема? Мы работаем в рамках Android фреймворка, который нам предоставляет компоненты приложения. Это означает, что у нас практически нет контроля над этими компонентами. Основными компонентами приложения управляет система. В любой момент Activity может просто перестать существовать и вы ничего с этим не сделаете.

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

Это же касается и работы со списками. Очевидно что списки у нас так или иначе будут работать в рамках Activity. Не нужно во ViewHolder делать какие-либо переменные, потому как Adapter это тоже фреймворк, который мы не контролируем. Используйте подход с Adapter Delegate, этим вы сильно упростите себе жизнь.

Конечно можно сохранять переменные в Bundle, но не все туда можно сохранить, не говоря уже о том, что он ограничен по размеру (≈1Mb на процесс, популярный вопрос на собесах). Bundle лучше всего все таки использовать для передачи всяких Id и подобных мелких штук.

Подводя итоги по этому совету: если можно избежать переменных в Activity, Fragment… лучше не делать. Хотите сохранить переменные сохраняйте их во ViewModel или что-то другое что не связано с компонентами приложения. Однако не стоит сохранять данные в статику.

Кто-то однажды сказал: “лучший джун, это джун который выгорел, он не сделает лишнего, после чего придется переписывать”. У всех у нас есть амбиции стать крутыми разрабами, показать что мы можем решить любую задачу и написать сложный код. Я понимаю, сам таким был, охото написать весь проект на вечер, прикрутить крутую анимацию даже если она не нужна, написать более оптимизированный код принеся в жертву читабельность — НЕ НУЖНО ЭТО ДЕЛАТЬ!

Поверьте у всех в карьере еще будет возможность показать что вы крутые, не бегите впереди паровоза. Очень большая вероятность того, что вы наломаете дров и придется переделывать или выпиливать что-то лишнее. Если хотите просто поиграться с какой-то сложной технологией или крутыми анимациями лучше делайте это в рамках pet проекта. В таком случает, когда к вам прилетит такая задача от бизнеса вы будете знать что делать.

Переусложнение кода это бомба замедленного действия. Когда вы пишете код, всегда держите в голове, что вы пишете его для другого человека. Даже если вы один на проекте, через полгода вы уже другой человек, который ничего не будет помнить про этот участок кода. В некотором смысле вы становитесь автором книги, и мне не хотелось бы читать книгу, где действие размазано по времени и нужно делать заметки, чтобы понять сюжет (нетфликс сейчас этим грешит довольно часто). Старайтесь поставить себя на место читателя вашего кода, который не знает того, что знаете вы.

Возникает вопрос “А как понять что переусложню?”. Лучше всего руководствоваться логикой. Если для решения простой задачи, типа изменения элемента в списке или перекрашивания кнопки у вас получается прям дофига кода стоит задуматься. До вас уже решили все задачи, погуглите, смотрите код других проектов, чтение кода других очень сильно прокачивает.

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

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

Вот тут закон Мерфи работает вообще на максимум, все что может упасть упадет. Причем реально все, любой вызов сети, похода в базу и даже вызов системного API может упасть с исключением.

Приложение должно продолжать работу даже если нет сети, а на диске кончилась память. Продолжать работу это значит что не просто проглотить ошибку, а сообщить об этом пользователю и сказать что ему делать дальше.

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

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

Частая ошибка это делать мутабельный класс с целью экономии памяти. Лучше сделать иммутабельный класс и при изменении создавать новый экземпляр. Потому как вы точно будете уверены что ваш класс никто не изменит в другой части программы или другом потоке. JVM в Android умеет эффективно избавляться от таких объектов.

Дональд Кнут сказал “Преждевременная оптимизация корень всех зол”, поэтому лучше парьтесь над читабельностью кода и его краткостью. Хорошая архитектура позволяет в дальнейшем переписать те части программы, которые тормозят. Основная проблема в том, что вы не можете заранее знать что будет тормозить.

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

Если вам понравилась статья и всратые иллюстрации к ней, подписывайтесь на мой телеграмм канал. Я пишу про Android разработку и Computer Science, на канале есть больше интересных постов про разработку под Android.