Привет, дружище !) Сегодня хочу с тобой поделиться наиболее запоминающимися уроками, которые я успел усвоить за время карьеры. Важный момент: всё, что будет изложено ниже — это моё субъективное мнение и оно может оспариваться в комментах.

1. Нужно всегда копать проблему до самого корня и решать её системно

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

И самое интересно, что такого обрезания не происходило, если элемент шёл первым по списку. Ну, собственно, вот ведь оно и решение — просто попросить маркетинг поставить двухстрочный элемент первым в списке!)

Но нет, это далеко не лучшее решение. Правильно будет понять суть проблемы — почему ресайклер высчитывает свою высоту некорректно (а может корректно, и это просто я неправильно его использую). Достаем layout inspector (благо сейчас он довольно удобный). Также не забываем про дебагер. И вперед к погружению.

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

Есть у меня еще одна тема, давай взглянем на два скриншота ниже:

Где же здесь проблема? На первый взгляд все выглядит довольно стандартно. Но с определенной версии GSON, такая модель начала выдавать DuplicateKeyException при десериализации. Причем этот exception вылетал на старых версиях приложения. Пришлось вооружиться дебагером и погружаться в недра GSON :) Причина сей проблемы оказалась довольно занятной. А вот о ней я уже расскажу в отдельной статье.

2. Иногда опыт может сыграть злую шутку

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

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

Давай представим прекрасный солнечный день, открываю я экран своей фичи и вижу вот такое:

Текстинпуты слиплись.

— Да что же такое! — воскликнул я в сердцах.

Здесь стоит отметить, что у нас на проекте есть дизайн система, которая подключается как библиотека в основной проект, и этот инпут — компонент нашей дизайн системы. У меня сразу возникла мысль, что кто-то делал доработки в компоненте и всё поломал.

И действительно, совсем недавно в компонент вносились правки. Я, не разбираясь, отправил проблему разработчику, который вносил изменения. В итоге оказалось, что его изменение ничего не ломало. И в этот момент я перестал что-либо понимать. Мой опыт меня обманул, а по итогу все оказалось гораздо запутаннее, чем я думал. Прикладываю скриншот с сумбурным объяснением того, что произошло.

Взрыв мозга, согласись? Поэтому не имеет смысла слепо доверяться своему опыту. Всегда надо челленджить самого себя.

3. Выступления на конференциях — очень полезная практика

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

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

А вот самостоятельное выступление с докладом умножает все выше описанные плюсы в несколько раз. Я выступал оффлайн на последнем Mobius — и могу сказать, что все трудности, связанные с долгой подготовкой, окупились полностью. На данный момент это самое приятное воспоминание за всю мою карьеру.

Интересен тот факт, что в начале пути это казалось чем-то недосягаемым. Я всегда думал «На конфах выступают такие крутые ребята, вряд ли я когда-нибудь до этого дойду». Но как оказалось на практике ничего сложного в выступлениях нет, наоборот это даже весело :)

4. В компромиссах нет ничего плохого

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

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

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

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

Пример:
- Какой контракт подобрать, чтобы быстрее выпустить фичу на андроид? — не очень.
- Какой контракт подобрать, чтобы выпустить фичу на всех целевых для продукта
платформах ? — уже получше.

Для получения ответа на второй вопрос уже не будет достаточно просто тянуть одеяло в сторону своей платформы.

5. Часто проблема бывает не в инструменте, а в том, как мы им пользуемся

К этому я тоже пришел через полученный опыт. На самом деле в этом пункте почти нечего написать. Не бывает плохих инструментов, у каждого инструмента есть свои плюсы и свои минусы, и каждый инструмент решает свои задачи. А может все таки есть плохие инструменты? Напиши в комментариях :)

6. Ребята, которые пилят Android тоже ошибаются, а иногда делают странные вещи.

О том какие странности в андроид бывают, я расписывал в этой статье, прочитай если тебе интересно.

Думаю, что у каждого андроид-разработчика найдётся несколько историй о том, как он сталкивался со странным поведением в андроиде. Но этот пункт скорее не об этом, а о том, что с первого раза идеальный продукт получается далеко не у каждого. (Если это конечно не приложение, цель которого показать надпись «Hello World»).

Путь к хорошему продукту/коду/сервису лежит через постоянный процесс улучшения. В погоне за идеалом можно провести всю жизнь и так и не выпустить ничего. Лучшее — враг хорошего.

Тут вопрос к тебе мой читатель, был бы андроид так востребован, если бы его сделали идеально, но выпустили сильно позже? У меня нет точного ответа на этот вопрос, возможно у тебя найдется, что сказать в комментариях. У андроида и Android SDK много недостатков. Но при этом они справляются со своими основными целями. А проблемы решаются итеративно. В нашей повседневной работе также стоит быть готовым к тому, что хороший продукт получается итеративно, как и хороший код.

7. Ты не научишься попадать в оценки, если не будешь их делать

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

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

Я бы вообще делал записи с описанием проблемы и того, что нужно изменить, чтобы её в будущем не допустить. И вот так итеративно ты научишься давать оценки. Про это я также писал статью «Как дать максимально хреновую оценку задаче».

8. Это не спринт, это марафон, люби то чем ты занимаешься, чтобы тебя не расплющило

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

И, как мне кажется, это возможно сделать, только если тебе по-настоящему нравится то, чем ты занимаешься. То что ты делаешь приносит тебе фан. Я нахожу фан в общении с коллегами, решении сложных инженерных задач, добрым троллингом друг друга на ревью, приколюхах в коде. Я никогда не просыпаюсь с мыслью о том, что мне не хочется на работу.

Кстати о приколюхах в коде андроида:

Если подводить черту под этим пунктом — долго бежать получится только в том темпе, который тебе комфортен. Если ты чувствуешь, что тебя начинает, что-то напрягать немедленно исправляй эту ситуацию. Напиши в комментариях, что ты делаешь, чтобы не терять интерес к работе :)