Dev Easy Notes

Чистые функции

Одна из основных проблем индустрии это сложность. Сложность систем делает изменения дорогими для компании, а разрабов делает несчастными. Никому не хочется чинить баги в запутанном коде, а охото быстрее писать новые фичи. Естественно решением этой проблемы это сделать код проще, но как это сделать? Я думал про совет который бы давал четкие рекомендации, по тому как это сделать. Существует такая штука, как функциональное программирование (ФП). Тема ФП довольно обширна, в вузе это выносят на целый семестр. Само по себе ФП это больше академическая история нежели промышленная. Однако, как и инженерия использует достижения физики, мы также можем стырить пару идей из ФП. Есть несколько довольно простых и четких понятий из ФП, которые легко понять и начать использовать. Они довольно неплохо улучшат ваш код: 👉 Чистые функции 👉 Иммутабельность 👉 Избегать исключений для бизнес логики Все 3 не поместятся в один пост, поэтому я сделаю по каждой из этих концепций отдельный пост.

Сначала разберем как может умереть Activity. Смерть Activity может произойти в двух случаях: 👉 Первый это когда что-то меняется в окружении, пользователь может заменить локаль, тему, ориентацию (телефона, а не свою), и т.д. В этом случае текущая Activity пересоздастся. Почему это сделано именно так? Так тупо проще, ведь нам нужно тянуть новые темы, ресурсы, картинки, а пересчитывать это все супер сложно. 👉 Второй, это когда наша Activity начинает кушать ну прям дофига ресурсов. Кейс достаточно редкий, и в основном появляется если вы делаете редактор фото или видео. В этом кейсе система берет кувалду и начинает рушить сначала все что вокруг нашего приложения, а после берется за наши Activity которые в фоне. Activity которые оказались в фоне просто умирают, у них даже onDestroy не вызывается, но вызываются методы onSavedInstantState. Когда мы возвращаемся назад в эти экраны, система их оживляет обратно. Все ViewModel продолжают жить, и все что мы сохранили в Bundle тоже. Со смертью Activity все довольно просто. Каких-то движений с вашей стороны не нужно, всякие мелкие Id сохраняем в Bundle, все остальное во ViewModel и не паримся. Однако есть случай когда и ViewModel не спасет. Есть такое понятие как процесс. Это некоторый объект системы, т.е штука которой система выдает ресурсы в виде времени процессора, памяти в оперативке и места на диске. Наше приложение работает в каком-то процессе (порой может даже в нескольких писал об этом тут). Процесс так же как и Activity может умереть. Как это обычно происходит. Мы отправляем наше приложение в фон (сворачиваем) система через какое-то время думает ага, пользователь вот про это приложение забыл, освобожу ка я память. Берет и выгружает процесс. Что значит выгружает процесс? Просто все что было связано с этим приложением в оперативной памяти затирает. Затирает статику, затирает все ViewModel, вообще все что не сохраняется в Bundle. В этот момент система говорит Activity, всем Activity которые сейчас есть в этом приложении. Причем неважно видны они пользователю или нет, система говорит, сохраняйте что-то важное в Bundle, все что не сохранено в Bundle будет забыто на веки. А после у нас два путя. 👉 Первый мы давно не заходим в приложение, и система окончательно все очищает, даже сохранённый Bundle, а когда пользователь возвращается в приложение оно запускается с самого начала, с первой Activity и т.д. 👉 Второй, это когда пользователь успевает вернуться в приложение до того, как система прибьет его окончательно. И когда пользователь вернется в приложение, угадайте какая Activity появится первой? Правильно, та которую он видел последней. А все остальные, ну их как бы нет, типо вообще нет, ни ViewModel ничего, только то, что сохранено в Bundle. Если пользователь начнет переходить назад они будут снова возвращаться с того света, но уже без ViewModel и т.д. Так почему нельзя сохранять что-то в статику? Причина в выгрузке процесса приложения из памяти. Представим что у вас есть Activity X и Y. В Activity X вы получаете какие-то данные с сети и сохраняете их в статику. Затем переходим в Activity Y которая уже использует эти данные. Дальше просто наш второй кейс. Пользователь сворачивает приложение, система выгружает его их памяти. Потом пользователь решает вернуться в приложение и у нас открывается Activity Y, которая пытается пойти в статику и получить данные. А данных там нет, так как вся статика которую сохраняла Activity X была очищена, и мы в лучшем случае просто падаем и быстро узнаем о проблеме.

В чем разница м/у смертью Activity и смертью процесса? Все мы знаем, что у Activity есть некоторый ЖЦ. Однако порой в статьях забывают сделать акцент на том, что умереть может не только Activity. Есть два понятия смерть Activity и смерть процесса. 👇

1️⃣ Хранение переменных в Activity Это касается всего что связано с UI. Почему это проблема? Да потому что Activity – компонент приложения Android фреймворка. Это значит, что мы вообще её не контролируем. Activity контролирует система, в любой момент Activity может просто перестать существовать и вы ничего с этим не сделаете. Всегда думайте о том, что будет если Activity пересоздастся! Это же касается и списков. Не нужно во ViewHolder делать какие-либо переменные, потому как Adapter это тоже фреймворк, который мы не контролируем. Да можно сохранять переменные в bundle, но не все туда можно сохранить, не говоря уже о том, что он ограничен по размеру (1kb это кстати популярный вопрос на собесах). Если можно избежать переменных в Activity, Fragment... лучше не делать. Хотите сохранить переменные сохраняйте их во ViewModel или что-то другое что не связано с компонентами приложения. Только не сохраняйте данные в статику, об этом я напишу в других постах. ❗️Важно это не относится к данным типа id которые мы можем передавать из одной Activity в другую, эти штуки мелкие и вот их мы передаем из через Bundle. 2️⃣ Обработка ошибок Часто можно заметить, что на исключение которые прилетают при запросе в сеть либо забивают, либо делают что-то вроде printStackTrace. 🙅‍♂️ Не делайте так, хотя бы в лог отправляйте исключение. Вот тут закон Мерфи работает вообще на максимум, все что может упасть упадет, но приложение должно продолжать работу. Продолжать работу это значит что не просто проглотить ошибку, а сообщить об этом пользователю и сказать что ему делать дальше. Удивительно, но на этом даже подрываются даже опытные разрабы. Всегда держите это в голове, особенно если у вас несколько запросов, которые идут подряд. Докапывайтесь до бизнес аналитиков и дизайнеров чтобы они описали что делать, если запрос упадет. 3️⃣ Переусложнение Вот это вообще боль. Кто-то однажды сказал, что лучший джун, это джун который выгорел, и это блин действительно так. Это уже больше относиться с soft скиллам, а не hard, но это супер важно. У всех у нас есть амбиции стать крутыми разрабами, показать что мы можем решить любую задачу и написать сложный код. Я понимаю, сам таким был, охото написать весь проект на вечер, прикрутить крутую анимацию даже если она не нужна, написать более оптимизированный код принеся в жертву читабельность. Совет один НЕ НУЖНО ЭТО ДЕЛАТЬ. Поверьте у вас в карьере еще будет возможность показать что вы крутые, не бегите впереди паровоза. Очень большая вероятность того, что вы наломаете дров и придется переделывать. Возникает вопрос "А как понять что переусложню?". Лучше всего руководствоваться логикой. Если для решения простой задачи, типа изменения элемента в списке или перекрашивания кнопки у вас получается прям дофига кода стоит задуматься. До вас уже решили все задачи, погуглите, смотрите код других проектов, чтение кода других очень сильно прокачивает. Суть – не нужно писать сложный код, нужно писать настолько простой код насколько это вообще возможно. Чем меньше кода нужно для решения задачи тем лучше. Есть даже такой принцип KISS. 4️⃣ Преждевременная оптимизация Это сильно связано с прошлым пунктом. Суть в том, что не нужно писать супер быстрый код. Если вы не пишете игру или операционную систему, то вам не нужно выжимать все из железа. Да конечно не нужно использовать заведомо дурацкие решения типа сортировки пузырьком, или ходить в базу данных на UI потоке. При этом не нужно на начально этапе париться о том, как сделать мега быструю отрисовку или как сделать параллельный алгоритм где достаточно однопоточного. Страуструп сказал "Преждевременная оптимизация корень всех зол", поэтому лучше парьтесь над читабельностью кода и его краткостью, оптимизацию будете делать позже, или никогда 😄.

Я решил написать пост про вещи на которых подрываются начинающие, и о которых забывают написать в книгах. Это 4 всадника апокалипсиса которые делают больно старшим разработчикам.🔽

Я давно ничего не постил в канал, сейчас решил прервать молчание, так как сейчас я менторю джунов и тех кто только начинает вливаться в профессию и у меня появились мысли которыми могу поделится. Когда только начинаешь вливаться в разработку часто источником информации являются книги или различные статьи. Беда книг по Android в том, что они быстро устаревают. Устаревают после каждого google IO, а статьи порой пишутся просто, чтобы написать. Поэтому я и создал этот канал где пишу про фундаментальные штуки, которые меняются оочень редко и стараюсь не писать про то, что можно и так легко найти в документации.