tgoop.com/dev_easy_notes/67
Last Update:
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 потоке.
При этом не нужно на начально этапе париться о том, как сделать мега быструю отрисовку или как сделать параллельный алгоритм где достаточно однопоточного. Страуструп сказал "Преждевременная оптимизация корень всех зол", поэтому лучше парьтесь над читабельностью кода и его краткостью, оптимизацию будете делать позже, или никогда 😄.
BY Dev Easy Notes
Share with your friend now:
tgoop.com/dev_easy_notes/67