Я работаю Android-инженером уже больше года, могу сказать, что многому научился за это время и пару раз меня повышали. Я хотел обновить свой профиль на Github проектом для сообщения в блоге, которое я писал в то время, и я наткнулся на свои старые студенческие проекты. Что я могу сказать, это беспорядок и очень неприятный код. Но в некотором роде это заставило меня оценить свое скромное начало и путь, который я прошел с тех пор.
Я закончил университет 2 года назад, и на тот момент у меня уже была стажировка по Android. Я знал, что хочу работать с Android, но так было не всегда.
В этой серии блогов я собираюсь поговорить конкретно о разработке для Android, но большинство этих советов можно применить к любой технологии.
Следуйте языковым рекомендациям и используйте переформатирование кода.
Я пришел из семестра, посвященного разработке C #, Windows Forms и UWP. В следующем семестре я начал свой курс мобильной разработки в университете, посвященный Android. Несмотря на то, что я уже прошел курс Java, мне понравился стиль открытия и закрытия фигурных скобок в C#.
Поэтому каждый раз, когда я начинал новый проект Android, переопределял функцию или писал новую функцию, я переходил к определению функции и помещал открывающую скобку в новую строку. Я не очень горжусь этим, и мой преподаватель курса не был доволен форматированием моих домашних заданий. К счастью, это не повлияло на мою итоговую оценку. Следуйте языковым рекомендациям языка, который вы используете, в Интернете есть много ресурсов и хороших примеров.
Еще одна важная вещь — всегда иметь очень структурированный код. Я не могу не подчеркнуть этого достаточно, но очень важно изучить ярлык переформатирования кода выбранной вами IDE и всегда переформатировать код перед фиксацией или публикацией вашего кода где-либо. Кроме того, еще один совет: не оставляйте много пустых строк между кодом. Я так делал, многие новички так делают. Я видел много подобных вопросов на Stackoverflow, это очень отвлекает, и люди могут из-за этого не отвечать.
Сделано лучше, чем идеально, но…
В нашем примитивном сознании вознаграждение за что-то новое больше, чем за постоянное улучшение уже существующего.
Я где-то читал эту цитату, и мой опыт снова и снова подтверждал ее правильность. Всегда есть но где-то, если вы думаете о чем-то достаточно долго. И утверждение, которое я процитировал, не должно иметь место. Завершение проекта или реализация библиотеки, которую вы хотели опробовать, заставляет вас чувствовать себя прекрасно, а затем вы переходите к следующему делу. Вот как я работал до сих пор, и это одно из моих сожалений. Я запустил или клонировал более 100 проектов Android Studio. Это была очень простая идея: опробовать новую библиотеку или закрыть и доработать исходный код Google codelab. У меня нет хорошего и солидного проекта, чуть более сложного, который я могу показать потенциальному клиенту или работодателю, чтобы доказать свои знания и навыки. Это то, что я пытался улучшить в последнее время, и я настоятельно рекомендую вам начать очень рано. Добавьте определенную функцию в старый проект, даже если это не имеет смысла, это ваш проект, и вы можете устанавливать правила. Вот несколько примеров, которые я мог бы придумать: добавить функцию погоды в приложение для создания заметок, которое вы создали ранее, или внедрить внедрение зависимостей Hilt. Это поможет вам улучшить свои навыки, и у вас всегда будет что-то готовое показать.
Еще одна хорошая вещь в том, что вы идете по этому пути, это то, что вы всегда будете проверять свой старый код, и у вас может быть особое ощущение вашего прогресса. Поэтому, если вы узнаете что-то новое или найдете лучший способ реализовать это, вы можете вернуться и провести рефакторинг этого кода. Благодаря этому ваш проект всегда будет в актуальном состоянии.
Если это работает, это не значит, что это правильно
Мы все счастливы, когда видим, что наше решение работает, но всегда полезно вернуться к коду и все проверить. Некоторые решения являются хакерскими и не поддерживаются в долгосрочной перспективе, потому что только вы понимаете решение. Через какое-то время никто не сможет это понять, даже ты. Поэтому всегда возвращайтесь и проверяйте, все ли правильно.
Я увидел что-то неловкое в одном из моих проектов. Это было классическое погодное приложение, когда вы впервые узнаете, как подключиться к API. Было 2 экрана. Первый представлял собой список названий городов, а второй — информацию о погоде для города, который вы выбираете на первом экране. Вы можете добавить город с помощью простого всплывающего окна, и когда вы щелкаете город в списке, открывается второй экран. На втором экране вызывался API и отображались подробности. На «счастливом» пути все работает нормально, но проблема начинается, когда вы тестируете пограничные случаи. Допустим, вы вводите какой-то одноразовый номер, например «kqwoeiqwe», тогда он добавляется как город и будет успешно добавлен. Когда вы нажимаете на него, открывается второй экран и появляется сообщение Toast о том, что произошла ошибка API. Было ли это решение рабочим — ДА, было ли оно правильным — я бы сказал НЕТ. Правильным подходом будет проверка города до его внесения в список городов. У вас не будет одноразового номера в списке, а позже вы окажетесь на экране сведений с ошибкой. Ошибка могла быть отображена при попытке ввести его в первую очередь.
Возможно, мой пример заставил вас задуматься о недавних проектах, над которыми вы работали, так что вам лучше взглянуть на них еще раз :)
Это мой первый блог, и мне нужно добавить еще пару разделов. Но я тянул с завершением статьи, поэтому решил сделать из нее серию блогов. Надеюсь, вы найдете это полезным, и я хотел бы услышать ваше мнение.
Первоначально опубликовано на https://davidbojkovski.hashnode.dev.
