Привет. Меня зовут Кирилл Розов и вы если вы интересуетесь разработкой под Android, то скорее всего слышали о Telegram канале "Android Broadcast", с ежедневными новостями для Android разработчиков, и одноимённом YouTube канале. Этот пост является текстовой расшифровкой видео на канале
Не так давно на моём YouTube канале стартанула новая рубрика «Code Review кода подписчиков», где я разбираю код подписчиков канала и даю своё профессиональное мнение о нём, а также советы по улучшению.
Пока я разбирал проекты кандидатов на ревью кода, я заметил много общих ошибок, которые есть на проектах. Сразу же вспомнил, сколько такого же кода я видел, когда мне приходилось делать code review своих коллег из команды или изучать тестовые задания. Решил, что пора рассказать вам 10 лучших практик, которые вам позволят улучшить качество кода и создать крутое впечатление у ревьювера. Конечно, они не исправят ваши технические навыки, но отдельные советы смогут сделать и это.
Если вы хотите попасть на разбор кода Android проектов, то вы можете подать заявку здесь
1. README должен содержать полезную информацию о репозитории
Что самое первое видит человек, который должен посмотреть ваш код, открывая репозиторий? Список файлов? Да, конечно, он виден, потому что он находится вверху.
Самое первое, что читаю лично я, это README, т.к. он сразу автоматом рендерится в какую-то страничку, он сразу показывается на главной и по нему легко понять, про что проект, что в нем есть и что он из себя представляет.
Зачастую большинство людей просто выкладывают код в репозитории. Ты совсем не понимаешь, что это за проект и как он устроен. Если вы хотите, чтобы о вашем проекте дали отзыв, то пишите, что это за проект, что он делает.
Например, напишете, что это приложение о погоде, в котором можно посмотреть погоду по региону, а также там есть поиск. Опишите, какую архитектуру вы применяете и стек. Это позволит понять, о чем ваш проект. Обязательно добавьте пару скриншотов. Это сделать несложно. Это позволит создать визуальный ряд и представление о вашей работе
Чем больше вы выложите информации, тем легче понять о чем ваш проект. Когда тебе нужно рассмотреть кучу проектов и дать технический feedback, ты больше обращаешь на такие проекты внимание, потому что видишь, как кандидаты продумали различные мелкие детали. Это здорово увеличивает ваши шансы на прохождение этапа отбора кандидатов по коду.
2. Оформляете историю коммитов в GIT
Следующий важный совет, который позволит сложить хорошее впечатление о вашем коде и процессе разработки, если у вас будет хорошо оформлена история в GIT. Например, если у вас будет множество комитов, вы сложите там все довольно аккуратно, будет виден процесс и какие там ветки, мержи, т.е. если вы действительно воспользуетесь возможностями GITа.
Зачастую у проектов, которые кандидаты отправляют на review, написан весь код локально. Они делают один комит, в который складывают весь свой код и его так отправляют. Ты не знаешь, что там происходило, не можешь посмотреть историю. А когда ты видишь, как человек разрабатывал этот проект, как он к нему подходил, как он сливал какие-то части, а также какие комиты там были и что он делал, то это очень здорово позволяет понять историю жизни этого проекта. Видно, как человек его разрабатывал. Поэтому обязательно ведите хорошую Git-историю. Учитесь этому сразу. Вам в продакшене это всегда понадобится. А ревьюверы вашего кода это оценят.
3. Упростите ревьюверу работу. Собери сборку вашего приложения
Помимо того, что нужно посмотреть ваш код, я очень люблю посмотреть то, что вы сделали в конечном варианте, т. е. финальную сборку вашего приложения, запущенного сервера или утилиты. В общем, люблю проверить результат работы, т.е. не скомпилировать его самому, не смотреть, как его настраивать, как собрать и установить зависимости. Нет, я должен уже взять все это в готовом варианте, чтобы посмотреть как обычный пользователь.
Позаботьтесь о том, чтобы куда-то выложить собранную релизную версию вашего труда. Это можно очень эффективно сделать через GitHub в release notes. У вас там есть assets, которые вы можете прикреплять к релизам. Вы можете это положить прямо в репозиторий и иметь файлик, на который будет ссылка. Вы можете это опубликовать в магазине приложений. Возможно, у вас даже есть свой аккаунт и вы можете сделать просто закрытый доступ. Делайте это обязательно. Это очень здорово повысит то, каким образом можно пощупать ваш проект и посмотреть на то, какой конечный результат вы можете сделать помимо того, какой код вы пишите.
4. Отправляйте только код, который компилируется не только на вашем компе
Прежде чем отправлять код на review, обязательно убедитесь, что он полностью может компилироваться и не только на вашем копьютере. Проверьте сборку, собрав проект с нуля (включая копиравоние репозитория) и попробуйте его собрать из терминала, даже не заходя в IDE. Это очень упростит ваше понимание о том, что у вас всё хорошо. Также не забывайте про релизую сборку. В приложениях очень часто разработчики проверяют только debug, а попытаешься собрать релиз, всё крэшится, т. е. оно не может собраться, потому что там не хватает build-конфигов, которые только прописали в один build variant, а также чего-то еще.
Обязательно проверяйте все сборки, которые вы отдаете и которые потенциально ревьювер может посмотреть. Иначе складывается впечатление, что вы невнимательны и пропускаете детали, которые не позволят нормально работать. На этом можно потерять много времени, как вам, так и всей команде проекта.
Лучший подход - автоматизировать все варианты сборки, но об этом читайте ниже
5. Не используйте диковинные технологии/библиотеки
При разработке проекта не используйте какие-то диковинные технологии. Особенно не используйте те технологии, которые вы не знаете, просто решив поупражняться на реальном проекте, который будут оцениваться и у вас ограниченные сроки для выполнения задания. Ни в коем случае этого не делайте, если у вас нет явных требований от заказчика этого кода, чтобы использовать именно эти технологии. Это ведет к очень печальным последствиям. Например, если вы используете какие-то диковинные решения, допустим, непопулярный DI или что-то еще, то это может вызвать вопрос: «Умеете ли вообще работать с общепринятыми tools?».
Лучше явно спросить у заказчика, какой стек технологий предпочтительно использовать, чтобы показать ему знания в этих технологиях.
6. Продумайте организацию кода заранее
Прежде чем начинать, продумайте то, каким образом вы будете организовывать код в вашем проекте. Имеется в виду и Gradle модули или какие-то другие модули. Также это относится и к пакетам, наименованиям классов и ко всему, что связано с пониманием, как у вас организован код. Например, реализация одних и тех же экранов должна быть идентична: структура классов, пакетов, разеделние кода и пр.
Очень плохая практика, если у вас есть пакеты аля view-model, screens и репозиторий. Там три пакета, в которые скинуто абсолютно все. И если у вас количество экранов растет, то у вас эти пакеты безразмерно начинают расти.
Лучше раскидывать их по отдельному функционалу либо по модулям, чтобы вы заходили в какое-то место и там было четко понятно, что сюда относится. Тогда не нужно будет ходить по куче пакетов, чтобы понять, как ваш код работает.
7. Осмысленное именование переменных, методов и классов
Если мы уже заговорили о хорошей организации вашего кода, то, конечно, не стоит забывать, что переменные, название классов и прочее тоже должны быть понятно созданы и не именоваться автоматическими способами или буквами, например, a, b, c, d. Это снижает читабельность и приводит к тому, что ваш код даже не захотят разбирать. Учтите, что при написании реальных проектов, чтение – это половина от того, что приходится делать с кодом, а остальное написание. Даже бывает в соотношении 60 на 40, а то и 70 на 30, где в меньшую часть вмещается написание кода. Поэтому следите за читабельностью. Её высоко ценят в профессиональной среде!
8. Соблюдайте стиль кода
У любого художника есть фирменный стиль. А у нас, как у программистов, должен быть свой стиль кода. Конечно, необязательно он должен быть полностью свой. Можно легко взять стандартный и рекомендуемый для Java или Kotlin, причем они, скорее всего, уже сразу включены в вашу IDE, особенно это актуально для IDEA и Android Studio. И вы легко можете их придерживаться.
Я сразу вижу, когда вы выходите за границы, если нарушаете количество символов в сроке. Например, у меня лимит стоит в 120 символов в строке (у меня прямо черта проведена). Я сразу вижу, что выходит за границы и происходит что-то неприемлемое. Мне это сильно режет глаза, поэтому такой код я сразу считаю не очень приятным. Мне в нем труднее разбираться, особенно, когда у меня небольшой монитор в 13-15 дюймов, а строка очень длинная. Мне ее нужно скролить. Возможно, у автора ультраширокий монитор и для него это нормально. Уважайте тех людей, которым даете свой код, а также своих коллег по команде, которые будут этот код читать. Возможно, не у всех такие широкие мониторы как у вас.
Кстати, вам не нужно следить за этим самостоятельно, потому что есть много автоматических утилит, которые это делают за вас. Они могут даже форматировать код, когда вы будете делать комиты. Они будут упрощать вашу работу. Я как раз делал обзор на все такие tools. Вы можете его посмотреть и найти для себя много полезного. Такие утилиты могут исправлять не только стиль кода, они могут давать советы по производительности и как лучше писать, а также почему что-то не стоит делать и стоит делать иначе.
9. Документируйте код
Слышали про такое понятие, как самодокументированный код? Да, есть большие компании, которые говорят: «Нам не нужно писать документацию для нашего кода. У нас он настолько шикарен, что никому не нужно разбираться, все и так понятно без дополнительной документации». Да, этого можно достичь, например, в команде, которая пишет слаженно, хорошо и долго работает вместе. Но со временем, когда приходят новые люди, эта документация поможет понять, что вы тут написали, как что использовать и какие вещи есть.
Документация, которую можно написать в коде – идеальный вариант. Даже когда вы напишете ее над своим примером, она здорово поможет человеку, который ревьювит ваш код, понять, что вы уделяете время документации и помечаете, что-то важное. Особенно будет классно, если вы делаете какие-то костыли из-за багов. В библиотеках, в SDK обязательно помечайте комментарием, потому что это позволит понять, что это не какой-то странный код, а обход проблемы в библиотеке, на которую вы повлиять не можете. Также это позволит вашим коллегам не заменить этот код и не сломать все приложение, после чего приходится долго разбираться в чём же была причина.
10. Автоматизируйте ваш проект, настройте CI/CD
Если вы хотите показать крутое отношение к своему проекту ревьюверу, просто настройте CI/CD в вашем проекте. Сделать это в GitHub Actions, если у вас там находится проект, совсем не сложно. Есть готовые шаблоны и статьи, которые помогут вам это сделать. Это повысит мнение о вас в глазах ревьювера, да и вы автоматизируете поиск всяких мест, где у вас могут быть потенциальные ошибки, что не даст вам допустить их.
Заключение
Если вы будете придерживаться тех 10 советов, которые я описал выше, любой ревьювер от вашего кода придёт в восторг. Он сразу поставит вам апрув на всех ваших pull request-ы или возьмет вас на работу, что здорово вас порадует и вы будете жить прекрасно и счастливо.
Да, конечно, качество вашего кода я не увеличу, т. е. все равно нужно учиться использовать технологии и их лучшим практики!
10 советов, 10 советов, но на самом деле есть один простой и хороший совет - хотите показать крутое качество ревьюверу, относитесь к своему проекту как к боевому, даже в котором один экран. Делайте все так, как бы вы сделали в реальной фиче. И у вас всё будет топ!
