Скорость сборки проекта
#разработка
Каждый раз, когда собираю основной рабочий проект, то берет грусть от времени сборки.
И вот, когда время сборки проекта стало приближаться к 5 минутам, то решил найти варианты решения этой проблемы.
На последнем Mobius был доклад, в котором автор рассказывал про уменьшение времени сборки проекта. Главным аргументом для этого было разбиение проекта на модули.
Думаю, что проблемы долгой сборки у большинства крупных проектов одинаковые:
• Annotation processing;
• переплетенность модулей между собой;
• Data binding и Dagger в каждом модуле;
• огромный модуль и Application модуль.
Первые шаги, которые помогут уменьшить время сборки проекта:
1) Использование
2) Ядро приложения должно быть максимально тонким. Сюда лучше всего добавлять только интерфейсы, а все реализации описываются в конкретной фиче.
3) Код приложения нельзя шарить между модулями.
4) Модули не должны взаимодействать друг с другом.
Также стоит помнить про инструмент
Чтобы лучше разобраться с модульностью рекомендую ознакомиться с проектом.
#разработка
Каждый раз, когда собираю основной рабочий проект, то берет грусть от времени сборки.
И вот, когда время сборки проекта стало приближаться к 5 минутам, то решил найти варианты решения этой проблемы.
На последнем Mobius был доклад, в котором автор рассказывал про уменьшение времени сборки проекта. Главным аргументом для этого было разбиение проекта на модули.
Думаю, что проблемы долгой сборки у большинства крупных проектов одинаковые:
• Annotation processing;
• переплетенность модулей между собой;
• Data binding и Dagger в каждом модуле;
• огромный модуль и Application модуль.
Первые шаги, которые помогут уменьшить время сборки проекта:
1) Использование
implementation вместо api в gradle.2) Ядро приложения должно быть максимально тонким. Сюда лучше всего добавлять только интерфейсы, а все реализации описываются в конкретной фиче.
3) Код приложения нельзя шарить между модулями.
4) Модули не должны взаимодействать друг с другом.
Также стоит помнить про инструмент
gradlew clean assembleDebug --scan. Он покажет интерактивную диаграмму с этапами сборки проект.Чтобы лучше разобраться с модульностью рекомендую ознакомиться с проектом.
Бывают ситуации, когда необходимо создать фон для изображения, но не в виде цвета, а в виде повторяющегося изображения.
Многие, особенно в начале своего пути, используют просто повторяющиеся фоновое изображение. Однако, такой подход не самый лучший, так как нужно хранить полное изображение, что ведет к увеличению размеров apk-файла. Предлагаю использовать данный #совет, чтобы уйти от этой проблемы.
В Android можно очень просто создать повторяющийся фон:
1) Вырежьте небольшой кусок того фрагмента, который будет повторяться
2) Добавьте новый
Подробнее можно прочитать тут
Многие, особенно в начале своего пути, используют просто повторяющиеся фоновое изображение. Однако, такой подход не самый лучший, так как нужно хранить полное изображение, что ведет к увеличению размеров apk-файла. Предлагаю использовать данный #совет, чтобы уйти от этой проблемы.
В Android можно очень просто создать повторяющийся фон:
1) Вырежьте небольшой кусок того фрагмента, который будет повторяться
2) Добавьте новый
drawable, где создайте <bitmap>, указав src и android:tileMode="repeat"Подробнее можно прочитать тут
Найм
#мысли
Около недели назад послушал свежий выпуск подкаста Про найм. А тут вторая часть. Я, например, нашёл там несколько интересных пунктов:
1) Не стоит указывать среди первых своих навыков кроссплатформенные фреймворки, типа Xamarin. Если собеседуетесь на вакансию Android разработчика, то лучше сосредоточиться на его навыках и используемых библиотеках. Из своего опыта собеседований могу сказать, что о таком человеке складывается мнение, что он не знаком ни с чем, а попробовал все на уровне тестовых и документации. Если же вы чувствуете свою мощь, то составьте несколько резюме для каждой из вакансий.
2) Пробуйте приложение и сервис той компании, куда собираетесь пойти. Конечно, если это не какой-то закрытый проект. Если вы предложите интересные идеи для улучшения проекта, то это увеличит ваши шансы на оффер.
3) Прокачивайте теоретическую и алгоритмическую базу. Поэтому заходите на HackerRank, чтобы решить пару задач.
Ну и еще много всего интересного про найм в этом выпуске. Кстати, всегда заглядывайте в ссылки, которые опубликованы в выпуске. Там можно найти и список вопросов для собеседования и много полезных сервисов. Ну и слушайте этот подкаст, если еще не делаете этого. Группа для обсуждения подкаста тут.
Например увидел несколько отличных сайтов для составления резюме онлайн. Это не простая задача, как может показаться на первый взгляд.
#мысли
Около недели назад послушал свежий выпуск подкаста Про найм. А тут вторая часть. Я, например, нашёл там несколько интересных пунктов:
1) Не стоит указывать среди первых своих навыков кроссплатформенные фреймворки, типа Xamarin. Если собеседуетесь на вакансию Android разработчика, то лучше сосредоточиться на его навыках и используемых библиотеках. Из своего опыта собеседований могу сказать, что о таком человеке складывается мнение, что он не знаком ни с чем, а попробовал все на уровне тестовых и документации. Если же вы чувствуете свою мощь, то составьте несколько резюме для каждой из вакансий.
2) Пробуйте приложение и сервис той компании, куда собираетесь пойти. Конечно, если это не какой-то закрытый проект. Если вы предложите интересные идеи для улучшения проекта, то это увеличит ваши шансы на оффер.
3) Прокачивайте теоретическую и алгоритмическую базу. Поэтому заходите на HackerRank, чтобы решить пару задач.
Ну и еще много всего интересного про найм в этом выпуске. Кстати, всегда заглядывайте в ссылки, которые опубликованы в выпуске. Там можно найти и список вопросов для собеседования и много полезных сервисов. Ну и слушайте этот подкаст, если еще не делаете этого. Группа для обсуждения подкаста тут.
Например увидел несколько отличных сайтов для составления резюме онлайн. Это не простая задача, как может показаться на первый взгляд.
RxJava: flatMap, switchMap и concatMap
#разработка
Это достаточно распространные операторы, и между ними есть существенная разница, о которой стоит помнить. В качестве примера для списка элементов "a", "b", "c", "d", "e", "f" применяется фукнция конкатенации x. Вот краткое объяснение:
• flatMap — применяет функцию к каждому элементу, соединяет элементы вместе и после чего возвращает Observable. Следует помнить, что элементы могут чередоваться, поэтому функция не заботится о порядке возвращения. В примере увидим cx, ex, fx, bx, dx, ax.
• switchMap — в отличии от flatMap, при получении нового элемента отписывается и перестает отображать предыдущие элементы, и наблюдает только за текущим. В примере увидим fx.
• concatMap — в отличии от flatMap, заботится о порядке элементов. При этом ему необходимо дождаться, пока каждый из элементов завершит свою работу перед получением нового. Поэтому, этот оператор нужно использовать осторожно. В примере увидим ax, bx, cx, dx, ex, fx.
Больше объяснений и примеров использования операторов тут.
#разработка
Это достаточно распространные операторы, и между ними есть существенная разница, о которой стоит помнить. В качестве примера для списка элементов "a", "b", "c", "d", "e", "f" применяется фукнция конкатенации x. Вот краткое объяснение:
• flatMap — применяет функцию к каждому элементу, соединяет элементы вместе и после чего возвращает Observable. Следует помнить, что элементы могут чередоваться, поэтому функция не заботится о порядке возвращения. В примере увидим cx, ex, fx, bx, dx, ax.
• switchMap — в отличии от flatMap, при получении нового элемента отписывается и перестает отображать предыдущие элементы, и наблюдает только за текущим. В примере увидим fx.
• concatMap — в отличии от flatMap, заботится о порядке элементов. При этом ему необходимо дождаться, пока каждый из элементов завершит свою работу перед получением нового. Поэтому, этот оператор нужно использовать осторожно. В примере увидим ax, bx, cx, dx, ex, fx.
Больше объяснений и примеров использования операторов тут.
👍1
На канале был пост о том, где лучше работать, в большой компании или в стартапе.
Я сменил свое место работы, и теперь работаю удаленно в стартапе. Это интересный опыт. Сейчас вливаюсь в рабочий процесс и вникаю в проект.
Что я понял за неделю работы удаленно?
1) Важно, чтобы дома было рабочее место. Ни в коем случае нельзя работать на кровати. Это значительно уменьшает производительность.
2) Необходимо контролировать рабочие часы. Для себя я решил работать по технике Pomodoro. Не стоит перерабатывать, иначе есть шанс просто перегореть.
3) Нужно делать перерывы и отвлекаться от компьютера. Хотя бы иногда стоит разминаться, пить воду и не забывать про обед.
Для меня это новый опыт, дальше обязательно напишу о плюсах и минусах удаленной работы.
Я сменил свое место работы, и теперь работаю удаленно в стартапе. Это интересный опыт. Сейчас вливаюсь в рабочий процесс и вникаю в проект.
Что я понял за неделю работы удаленно?
1) Важно, чтобы дома было рабочее место. Ни в коем случае нельзя работать на кровати. Это значительно уменьшает производительность.
2) Необходимо контролировать рабочие часы. Для себя я решил работать по технике Pomodoro. Не стоит перерабатывать, иначе есть шанс просто перегореть.
3) Нужно делать перерывы и отвлекаться от компьютера. Хотя бы иногда стоит разминаться, пить воду и не забывать про обед.
Для меня это новый опыт, дальше обязательно напишу о плюсах и минусах удаленной работы.
Live Templates
#разработка #совет
При длительном написании кода, усталость разработчика накапливается, поэтому он может совершить простые ошибки в коде, которые никогда бы не совершил при ее отсутствии.
Уверен, что каждый совершал описку в этом коде:
Чтобы уменьшить количество таких простых ошибок и сократить количество повторяющегося кода, созданы Live Templates. Есть большое количество шаблонов, встроенных в студию. Посмотреть их можно в настройках File > Settings > Editor > Live Templates.
В нашем случае достаточно было написать Toast, чтобы получить шаблон для всплывающего сообщения.
Подробнее о написании своих Live Templates можно почитать тут.
#разработка #совет
При длительном написании кода, усталость разработчика накапливается, поэтому он может совершить простые ошибки в коде, которые никогда бы не совершил при ее отсутствии.
Уверен, что каждый совершал описку в этом коде:
Toast.makeText(this, "Text to show»);Toast не покажется, потому что мы забыли написать в конце .show(). Среда подскажет об ошибке, однако в других случаях этого может не произойти.Чтобы уменьшить количество таких простых ошибок и сократить количество повторяющегося кода, созданы Live Templates. Есть большое количество шаблонов, встроенных в студию. Посмотреть их можно в настройках File > Settings > Editor > Live Templates.
В нашем случае достаточно было написать Toast, чтобы получить шаблон для всплывающего сообщения.
Подробнее о написании своих Live Templates можно почитать тут.
В сообщения пришел #вопрос: сколько необходимо опыта и что еще нужно соблюдать для перехода на удаленку? Все, что написано ниже — только мое мнение.
Считаю, что не нужно выбирать удаленную работу в качестве первой работы.
Во-первых, достаточно сложно будет найти подобную работу. Если на офисную работу часто требуются люди с хоть каким-то опытом, то на удаленную работу эти требования растут еще выше.
Во-вторых, обучаться и получать опыт на первоначальном этапе комфортнее в офисе. Говорю это по своему опыту, возможно у кого-то иначе: моя первая работа была в офисе, и не уверен, что получил бы те навыки, находясь дома.
Поэтому, рассматривать удаленную работу стоит после хотя бы одного года работы в офисе с командой.
На что еще обратить внимание, если рассматриваете удаленную работу? Думаю, что это личные качества. Поймите, интроверт вы или экстраверт. Если экстраверт, то будет тяжелее, чем в офисе. Вам будет не хватать живого общения с коллегами. Ну и корпоративные вещи, например поздравление с днем рождения и поедание пиццы, также уйдут. Кроме этого решите для себя, какая у вас мера ответственности. Если сложно заставить себя не смотреть очередную серию любимого сериала, то удаленка точно не для вас.
Некоторых людей останавливает общение с коллегами. Для многих комфортно подойти к коллеге и поговорить с ним лично. К сожалению, для связи чаще всего будет чат. Но, как по мне, это не особо критичный пункт.
Всегда рад ответить на ваши сообщения тут.
Считаю, что не нужно выбирать удаленную работу в качестве первой работы.
Во-первых, достаточно сложно будет найти подобную работу. Если на офисную работу часто требуются люди с хоть каким-то опытом, то на удаленную работу эти требования растут еще выше.
Во-вторых, обучаться и получать опыт на первоначальном этапе комфортнее в офисе. Говорю это по своему опыту, возможно у кого-то иначе: моя первая работа была в офисе, и не уверен, что получил бы те навыки, находясь дома.
Поэтому, рассматривать удаленную работу стоит после хотя бы одного года работы в офисе с командой.
На что еще обратить внимание, если рассматриваете удаленную работу? Думаю, что это личные качества. Поймите, интроверт вы или экстраверт. Если экстраверт, то будет тяжелее, чем в офисе. Вам будет не хватать живого общения с коллегами. Ну и корпоративные вещи, например поздравление с днем рождения и поедание пиццы, также уйдут. Кроме этого решите для себя, какая у вас мера ответственности. Если сложно заставить себя не смотреть очередную серию любимого сериала, то удаленка точно не для вас.
Некоторых людей останавливает общение с коллегами. Для многих комфортно подойти к коллеге и поговорить с ним лично. К сожалению, для связи чаще всего будет чат. Но, как по мне, это не особо критичный пункт.
Всегда рад ответить на ваши сообщения тут.
Как подтянуть английский?
#совет
Думаю, в жизни каждого современного человека наступает момент, когда ему хочется подтянуть свой английский до хорошего уровня. Подобные мысли возникают чаще перед Новым годом, с понедельника или других дат.
Для разработчика английский язык необходим. Без умения читать статьи, документацию, писать вопросы в stackoverflow — сложно представить современную разработку. Кроме этого, у каждого открываются куча новых возможностей, таких как:
• просмотр сериалов и фильмов в оригинале;
• общение с иностранцами;
• свободное общение в путешествиях;
• карьера.
Хотя уверен, что вы и без меня знаете о всех плюсах языка.
Сегодня хочу поделиться некоторыми советами, которые помогают мне в изучении и улучшении навыков английского языка:
1) Просмотр сериалов.
Это помогает понимать настоящую речь иностранцев. Рекомендую смотреть именно сериалы, а не фильмы. Хотя в самом начале легче смотреть мультфильмы. В них проще речь для понимания.
Для просмотра рекомендую сервис PopcornTime. Это большой онлайн-кинотеатр с выбором субтитров. Еще слышал положительные отзывы о сервисе OroroTV, но не использовал его.
Рекомендую смотреть на английском языке с английскими субтитрами. Русские субтитры используйте, если ничего не поняли и уже при повторном просмотре с перемоткой назад.
2) Просмотр видео.
Помогает и вносит разнообразие просмотр лекций TED. Поищите интересные каналы на YouTube. Их гораздо больше, чем в русском сегменте. Выбирайте по своим интересам.
3) Прослушивание подкастов. Это помогает понимать английскую речь не видя собеседника. На самом деле, это гораздо сложнее, чем живое общение или просмотр видео.
Из темы Android рекомендую слушать FragmentedPodcast.
4) Чтение статей. Понятно, что это прокачивает навык чтения.
Из сайтов рекомендую Inc, ну и множество статей на различные технические темы — #medium.
5) Занятие с преподавателем. Вот тут немного подробнее.
Не так давно открыл для себя школу английского языка SkyEng. Слышал много отзывов и решил попробовать. Суть школы в том, что вы получаете индивидуальные занятия с подобранным для вас преподавателем. Цель заключается в том, чтобы вы разговаривали в течении занятия не меньше 65% времени.
Первое занятие — вводное. Там оценят ваш уровень языка, спросят цели изучения английского и постараются подобрать преподавателя.
Дальше вы будете учить язык с учителем. Есть вариант выбрать носителя или русскоговорящего преподавателя. Я не рекомендую брать занятия с носителем, если ваш уровень ниже B2. Носитель нужен при очень хорошем знании языка, чтобы немного отшлейфовать навыки и акцент. Ну и это стоит гораздо дороже, чем русскоязычный преподаватель.
Я пробовал занятия с носитетелем, однако через пару занятий поменял преподавателя на русскоговорящего.
Далее вы выбираете то, как хотите заниматься. Сейчас я занимаюсь по стандартной схеме: мы делаем урок, если я что-то не понимаю, то спрашиваю и получаю домашнее задание. Коллега рассказывал, что у него другая схема: они просто общаются «за жизнь» по-английски, преподаватель делает акценты на ошибках и дает по ним задания. Возможно, я тоже приду к похожей схеме.
Впечатления от школы отличные, и крайне рекомендую вам заниматься там. Вы получаете хорошую мотивацию, кучу материалов для изучения и опытного преподавателя. Делюсь своей ссылкой для регистрации. И вам, и мне достанется по 2 бесплатных урока, что выгодно.
6) Языковые клубы
Еще одна возможность для практики языка — языковые клубы. Это сервис, который организовывает Skyeng. Вы можете бесплатно присоединиться к группе из 6 человек, где с вами будет учитель, направляющий общение. Это также здорово прокачивает навыки общения и выражения мыслей на языке.
Надеюсь, что этот пост поможет вам в прокачке всех навыков английского языка.
А вы изучаете английский язык?
#совет
Думаю, в жизни каждого современного человека наступает момент, когда ему хочется подтянуть свой английский до хорошего уровня. Подобные мысли возникают чаще перед Новым годом, с понедельника или других дат.
Для разработчика английский язык необходим. Без умения читать статьи, документацию, писать вопросы в stackoverflow — сложно представить современную разработку. Кроме этого, у каждого открываются куча новых возможностей, таких как:
• просмотр сериалов и фильмов в оригинале;
• общение с иностранцами;
• свободное общение в путешествиях;
• карьера.
Хотя уверен, что вы и без меня знаете о всех плюсах языка.
Сегодня хочу поделиться некоторыми советами, которые помогают мне в изучении и улучшении навыков английского языка:
1) Просмотр сериалов.
Это помогает понимать настоящую речь иностранцев. Рекомендую смотреть именно сериалы, а не фильмы. Хотя в самом начале легче смотреть мультфильмы. В них проще речь для понимания.
Для просмотра рекомендую сервис PopcornTime. Это большой онлайн-кинотеатр с выбором субтитров. Еще слышал положительные отзывы о сервисе OroroTV, но не использовал его.
Рекомендую смотреть на английском языке с английскими субтитрами. Русские субтитры используйте, если ничего не поняли и уже при повторном просмотре с перемоткой назад.
2) Просмотр видео.
Помогает и вносит разнообразие просмотр лекций TED. Поищите интересные каналы на YouTube. Их гораздо больше, чем в русском сегменте. Выбирайте по своим интересам.
3) Прослушивание подкастов. Это помогает понимать английскую речь не видя собеседника. На самом деле, это гораздо сложнее, чем живое общение или просмотр видео.
Из темы Android рекомендую слушать FragmentedPodcast.
4) Чтение статей. Понятно, что это прокачивает навык чтения.
Из сайтов рекомендую Inc, ну и множество статей на различные технические темы — #medium.
5) Занятие с преподавателем. Вот тут немного подробнее.
Не так давно открыл для себя школу английского языка SkyEng. Слышал много отзывов и решил попробовать. Суть школы в том, что вы получаете индивидуальные занятия с подобранным для вас преподавателем. Цель заключается в том, чтобы вы разговаривали в течении занятия не меньше 65% времени.
Первое занятие — вводное. Там оценят ваш уровень языка, спросят цели изучения английского и постараются подобрать преподавателя.
Дальше вы будете учить язык с учителем. Есть вариант выбрать носителя или русскоговорящего преподавателя. Я не рекомендую брать занятия с носителем, если ваш уровень ниже B2. Носитель нужен при очень хорошем знании языка, чтобы немного отшлейфовать навыки и акцент. Ну и это стоит гораздо дороже, чем русскоязычный преподаватель.
Я пробовал занятия с носитетелем, однако через пару занятий поменял преподавателя на русскоговорящего.
Далее вы выбираете то, как хотите заниматься. Сейчас я занимаюсь по стандартной схеме: мы делаем урок, если я что-то не понимаю, то спрашиваю и получаю домашнее задание. Коллега рассказывал, что у него другая схема: они просто общаются «за жизнь» по-английски, преподаватель делает акценты на ошибках и дает по ним задания. Возможно, я тоже приду к похожей схеме.
Впечатления от школы отличные, и крайне рекомендую вам заниматься там. Вы получаете хорошую мотивацию, кучу материалов для изучения и опытного преподавателя. Делюсь своей ссылкой для регистрации. И вам, и мне достанется по 2 бесплатных урока, что выгодно.
6) Языковые клубы
Еще одна возможность для практики языка — языковые клубы. Это сервис, который организовывает Skyeng. Вы можете бесплатно присоединиться к группе из 6 человек, где с вами будет учитель, направляющий общение. Это также здорово прокачивает навыки общения и выражения мыслей на языке.
Надеюсь, что этот пост поможет вам в прокачке всех навыков английского языка.
А вы изучаете английский язык?
Цветовая схема logcat
#совет
Скорость и качество работы разработчика зависит от многих вещей: мощность компьютера, удобство рабочего места, знание горячих клавиш, время компиляции приложения, отвлекающие факторы и другое. Одной из неочевидных, но очень важных вещей, улучшающих качество работы является цветовая схема logcat.
После установки Android Studio logcat выглядит как сплошное белое полотно текста, где красным цветом показываются ошибки. На мой взгляд, ошибки — это самое важное, что нужно мониторить в логах. Однако, другие параметры также важны. Для удобства их можно отделить разными цветами.
Чтобы изменить цветовую схему логов, необходимо перейти:
Settings → Editor → Colors & Fonts → Android Logcat.
Я использую следующую цветовую схему:
• Assert BA68C8;
• Debug 2196F3;
• Error F44336;
• Info 4CAF50;
• Verbose BBBBBB;
• Warning FF9800.
После этой настройки вы врядли захотите продолжать использовать стандартный, белый logcat, а скорость работы увеличится.
#совет
Скорость и качество работы разработчика зависит от многих вещей: мощность компьютера, удобство рабочего места, знание горячих клавиш, время компиляции приложения, отвлекающие факторы и другое. Одной из неочевидных, но очень важных вещей, улучшающих качество работы является цветовая схема logcat.
После установки Android Studio logcat выглядит как сплошное белое полотно текста, где красным цветом показываются ошибки. На мой взгляд, ошибки — это самое важное, что нужно мониторить в логах. Однако, другие параметры также важны. Для удобства их можно отделить разными цветами.
Чтобы изменить цветовую схему логов, необходимо перейти:
Settings → Editor → Colors & Fonts → Android Logcat.
Я использую следующую цветовую схему:
• Assert BA68C8;
• Debug 2196F3;
• Error F44336;
• Info 4CAF50;
• Verbose BBBBBB;
• Warning FF9800.
После этой настройки вы врядли захотите продолжать использовать стандартный, белый logcat, а скорость работы увеличится.
CrunchyCalendar
#разработка #библиотека
Не так давно ко мне обратились с просьбой изучить небольшую библиотеку и рассказать о ней на канале. Это библиотека для работы с календарем — CrunchyCalendar.
На самом деле, работа с календарем — распространенная задача. Основной кейс состоит в том, чтобы получить выбранную дату, показав при этом пользователю календарь.
Сразу в голове всплывает стандартный компонент — DatePickerDialog. Но он справляется только с тем, чтобы выбрать одну дату. А что если необходим диапазон дат? Или хочется большей кастомизации? И что делать, если выбор нужно сделать на текущем экране? Тогда приходится искать кастомные библиотеки для работы с календарем.
Что мне понравилось в CrunchyCalendar:
1) Нет лишней фукнциональности. Часто бывает, что из всей библиотеки необходима только одна ее часть. Остальная при этом висит мертвым грузом в проекте. Тут только календарь и больше ничего, что здорово.
2) Малый размер. В ней нет никаких ресурсов и других библиотек, кроме RecyclerView (который уже и так у вас в проекте).
3) Кастомизация. Можно настроить цвета и задать тему для View. Кроме того, библиотека сделана в виде адаптера для RecyclerView, поэтому если не хватает стандартных возможностей, то их всегда можно добавить.
4) Простой и лаконичный дизайн.
5) Библиотека написана на Kotlin.
Из минусов могу отметить то, что нельзя выделить диапазон дат при помощи жеста, а также то, что нельзя ограничить количество выделяемых дней в диапазоне. В остальном — отличная библиотека, которую буду использовать, если захочу работать с календарем в проекте.
#разработка #библиотека
Не так давно ко мне обратились с просьбой изучить небольшую библиотеку и рассказать о ней на канале. Это библиотека для работы с календарем — CrunchyCalendar.
На самом деле, работа с календарем — распространенная задача. Основной кейс состоит в том, чтобы получить выбранную дату, показав при этом пользователю календарь.
Сразу в голове всплывает стандартный компонент — DatePickerDialog. Но он справляется только с тем, чтобы выбрать одну дату. А что если необходим диапазон дат? Или хочется большей кастомизации? И что делать, если выбор нужно сделать на текущем экране? Тогда приходится искать кастомные библиотеки для работы с календарем.
Что мне понравилось в CrunchyCalendar:
1) Нет лишней фукнциональности. Часто бывает, что из всей библиотеки необходима только одна ее часть. Остальная при этом висит мертвым грузом в проекте. Тут только календарь и больше ничего, что здорово.
2) Малый размер. В ней нет никаких ресурсов и других библиотек, кроме RecyclerView (который уже и так у вас в проекте).
3) Кастомизация. Можно настроить цвета и задать тему для View. Кроме того, библиотека сделана в виде адаптера для RecyclerView, поэтому если не хватает стандартных возможностей, то их всегда можно добавить.
4) Простой и лаконичный дизайн.
5) Библиотека написана на Kotlin.
Из минусов могу отметить то, что нельзя выделить диапазон дат при помощи жеста, а также то, что нельзя ограничить количество выделяемых дней в диапазоне. В остальном — отличная библиотека, которую буду использовать, если захочу работать с календарем в проекте.
CatchUp
#библиотека #разработка #совет
Мне очень приятно получать от вас обратную реакцию и вопросы. Сегодня получил вопрос о том, что можно написать начинающим разработчикам, чтобы изучить как можно больше тем, библиотек и попробовать применить архитектурные паттерны.
Есть одно приложение, которое позволяет изучить много библиотек и паттернов — CatchUp. Его пишет Zac Sweers — Android-разработчик из Uber.
По сути, это приложение большой аггрегатор новостей из разных источников, например Reddit, Medium, Dribbble. Главным отличием является то, что вы можете изучить благодаря ему множество технологий и библиотек. Лучше почитать о них на странице проекта.
Если хотите потренироваться и у вас есть некоторые знания по Android-разработке, то попробуйте написать простой аггрегатор новостей. В подобном приложении вы сможете применить архитектурные паттерны, библиотеки для работы с базой данных, сервером, dependency injection, загрузкой картинок, тестирования и многое другое. CatchUp будет для вас ориентиром, к которому стоит стремиться.
А если вы опытный разработчик, то это приложение восполнит пробелы о некоторых незнакомых библиотеках и даст понимание, как их лучше использовать в настоящем приложении.
#библиотека #разработка #совет
Мне очень приятно получать от вас обратную реакцию и вопросы. Сегодня получил вопрос о том, что можно написать начинающим разработчикам, чтобы изучить как можно больше тем, библиотек и попробовать применить архитектурные паттерны.
Есть одно приложение, которое позволяет изучить много библиотек и паттернов — CatchUp. Его пишет Zac Sweers — Android-разработчик из Uber.
По сути, это приложение большой аггрегатор новостей из разных источников, например Reddit, Medium, Dribbble. Главным отличием является то, что вы можете изучить благодаря ему множество технологий и библиотек. Лучше почитать о них на странице проекта.
Если хотите потренироваться и у вас есть некоторые знания по Android-разработке, то попробуйте написать простой аггрегатор новостей. В подобном приложении вы сможете применить архитектурные паттерны, библиотеки для работы с базой данных, сервером, dependency injection, загрузкой картинок, тестирования и многое другое. CatchUp будет для вас ориентиром, к которому стоит стремиться.
А если вы опытный разработчик, то это приложение восполнит пробелы о некоторых незнакомых библиотеках и даст понимание, как их лучше использовать в настоящем приложении.
Горячие клавиши
#совет
На эффективность разработки влияет множество факторов: настройки среды программирования, компьютер или рабочее место вокруг. Также немаловажным является знание горячих клавиш в Android Studio.
Мне кажется, что нет ни одного разработчика, который бы знал все горячие клавиши. Но для постоянных действий, которые мы совершаем, используя меню, просто необходимо знать альтернативные горячие клавиши. Это сильно ускоряет процесс написания кода. Как-то я уже упоминал Multicursor, поэтому если вы еще не используете этот замечательный инструмент, то скорее начинайте.
Чтобы помочь в изучении горячих клавиш, нашел пару решений, которые будут полезны.
1) Списки горячих клавиш. Можно иногда пролистывать, пытаясь найти те действия, которые делаешь не используя горячие клавиши. Например, подобный список можно взять тут. Но если поискать, то найдете кучу статей на эту тему.
2) KeyPromoter. Плагин, который анализирует действия разработчика в среде программирования и подсказывает, какие из них эффективнее сделать с помощью клавиш. Рекомендую на начальном этапе разработки.
3) Mouseless Driven Development. Доклад, который посвящен работе в Android Studio без использования мыши.
Была одна проблема, которая возникла у меня при использовании горячих клавиш — переход с Windows на MacOS. К сожалению, не все кнопки совпадают и поначалу это дико раздражало.
А вы изучаете горячие клавиши в Android Studio?
#совет
На эффективность разработки влияет множество факторов: настройки среды программирования, компьютер или рабочее место вокруг. Также немаловажным является знание горячих клавиш в Android Studio.
Мне кажется, что нет ни одного разработчика, который бы знал все горячие клавиши. Но для постоянных действий, которые мы совершаем, используя меню, просто необходимо знать альтернативные горячие клавиши. Это сильно ускоряет процесс написания кода. Как-то я уже упоминал Multicursor, поэтому если вы еще не используете этот замечательный инструмент, то скорее начинайте.
Чтобы помочь в изучении горячих клавиш, нашел пару решений, которые будут полезны.
1) Списки горячих клавиш. Можно иногда пролистывать, пытаясь найти те действия, которые делаешь не используя горячие клавиши. Например, подобный список можно взять тут. Но если поискать, то найдете кучу статей на эту тему.
2) KeyPromoter. Плагин, который анализирует действия разработчика в среде программирования и подсказывает, какие из них эффективнее сделать с помощью клавиш. Рекомендую на начальном этапе разработки.
3) Mouseless Driven Development. Доклад, который посвящен работе в Android Studio без использования мыши.
Была одна проблема, которая возникла у меня при использовании горячих клавиш — переход с Windows на MacOS. К сожалению, не все кнопки совпадают и поначалу это дико раздражало.
А вы изучаете горячие клавиши в Android Studio?
MBLT DEV 2018
Обычно я писал вам о профессиональных конференциях во время ее проведения или уже после ее завершения. Однако сейчас расскажу о предстоящей конференции MBLT DEV 2018, которую также посещу.
В прошлом году я присутствовал на MBLT DEV 2017. Это было первое посещение конференций мобильных разработчиков, и я был под впечатлением после ее завершения. Много докладов, профессиональные знакомства, общение с разработчиками — все это сильно прокачивает и дает возможность применять опыт других людей к собственным проектам. Кстати, вот ссылка на один из лучших докладов, где Zac Sweers из Uber рассказал об автоматизации и кодогенерации.
Уже есть предварительное расписание.
Интересно послушать про Firebase ML Kit, так как это новый и нестандартный инструмент, который имеет большое применение. Также любопытен опыт применения Firebase + Flutter. Этот фреимворк наслуху, и понимать на что он способен важно.
Список докладов пополняется. Например, будет доклад о применении и нюансах работы с Google Assistant и Actions on Google. Если вам интересна эта тема, то вы можете прислать свои вопросы спикеру, и он учтет их при подготовке доклада.
Конференция пройдет 28 сентября. Сегодня билет стоит 10 000 рублей. 28 июля цена увеличится, поэтому имеет смысл сэкономить и преобрести его сейчас. До встречи на MBLT DEV!
Обычно я писал вам о профессиональных конференциях во время ее проведения или уже после ее завершения. Однако сейчас расскажу о предстоящей конференции MBLT DEV 2018, которую также посещу.
В прошлом году я присутствовал на MBLT DEV 2017. Это было первое посещение конференций мобильных разработчиков, и я был под впечатлением после ее завершения. Много докладов, профессиональные знакомства, общение с разработчиками — все это сильно прокачивает и дает возможность применять опыт других людей к собственным проектам. Кстати, вот ссылка на один из лучших докладов, где Zac Sweers из Uber рассказал об автоматизации и кодогенерации.
Уже есть предварительное расписание.
Интересно послушать про Firebase ML Kit, так как это новый и нестандартный инструмент, который имеет большое применение. Также любопытен опыт применения Firebase + Flutter. Этот фреимворк наслуху, и понимать на что он способен важно.
Список докладов пополняется. Например, будет доклад о применении и нюансах работы с Google Assistant и Actions on Google. Если вам интересна эта тема, то вы можете прислать свои вопросы спикеру, и он учтет их при подготовке доклада.
Конференция пройдет 28 сентября. Сегодня билет стоит 10 000 рублей. 28 июля цена увеличится, поэтому имеет смысл сэкономить и преобрести его сейчас. До встречи на MBLT DEV!
Сабрепозиторий
#разработка #совет
Одной из задач, с которой сталкивается разработчик при создании приложений — переиспользование кода. Помогают решить эту задачу сабрепозитории.
По сути, такие репозитории являются полноценными репозиториями, которые располагаются внутри репозитория вашего приложения. Его необходимо подключить в качестве модуля к основному проекту, и дальше код из этого репозитория будет попадать в остальные проекты, где также подключен этот сабрепозиторий.
Для подключения репозитория в Android Studio необходимо:
1) Создать модуль в основном проекте.
2) Перенести этот модуль в отдельный каталог
3) Создать новый git-репозиторий из каталога и запушить изменения на сервер
4) Подключить репозиторий при помощи команды
5) Добавить подключенный модуль в качестве библиотеки, прописав каталог в настройках и build.gradle.
Далее, при изменении сабрепозитория необходимо использовать команды
#разработка #совет
Одной из задач, с которой сталкивается разработчик при создании приложений — переиспользование кода. Помогают решить эту задачу сабрепозитории.
По сути, такие репозитории являются полноценными репозиториями, которые располагаются внутри репозитория вашего приложения. Его необходимо подключить в качестве модуля к основному проекту, и дальше код из этого репозитория будет попадать в остальные проекты, где также подключен этот сабрепозиторий.
Для подключения репозитория в Android Studio необходимо:
1) Создать модуль в основном проекте.
2) Перенести этот модуль в отдельный каталог
3) Создать новый git-репозиторий из каталога и запушить изменения на сервер
4) Подключить репозиторий при помощи команды
git submodule add _repo_url_. Можно также указать ветку, которая является основной.5) Добавить подключенный модуль в качестве библиотеки, прописав каталог в настройках и build.gradle.
Далее, при изменении сабрепозитория необходимо использовать команды
git submodule init и git submodule update. Это крайне удобный инструмент, который легко поможет разделять код на модули и использовать его во многих приложениях.MotionLayout
#разработка
На последней конференции Google IO был анонсирован новый класс — MotionLayout. Он входит в ConstraintLayout 2.0 и помогает в анимации приложений. Особенностью является то, что при помощи него можно легко создавать сложный анимации переходов между различными View. По сути, это смесь стандартных анимаций,
Поведение MotionLayout описывается при помощи xml-файла. На мой взгляд, это также упрощает создание анимаций. Так как MotionLayout входит в support library, то поддержка устройств идет с 18 версии API.
Сейчас layout в alpha, поэтому использовать его в реальных продуктах не стоит. Но попробовать в своих проектах или просто ознакомиться настоятельно рекомендую. Можно посмотреть доклад с Google IO о возможностях нового ConstraintLayout (примерно с 29 минуты идет разговор о MotionLayout). Но удобнее почитать серию статей о начале работы с этим layout. Особенно понравилась третья часть, где описывается взаимодействие MotionLayout с другими библиотеками и компонентами: ViewPager, DrawerLayout, LottieAnimationView. Серия пополняется, поэтому дальше будет только интереснее.
#разработка
На последней конференции Google IO был анонсирован новый класс — MotionLayout. Он входит в ConstraintLayout 2.0 и помогает в анимации приложений. Особенностью является то, что при помощи него можно легко создавать сложный анимации переходов между различными View. По сути, это смесь стандартных анимаций,
TransitionManager и CoordinatorLayout. Поведение MotionLayout описывается при помощи xml-файла. На мой взгляд, это также упрощает создание анимаций. Так как MotionLayout входит в support library, то поддержка устройств идет с 18 версии API.
Сейчас layout в alpha, поэтому использовать его в реальных продуктах не стоит. Но попробовать в своих проектах или просто ознакомиться настоятельно рекомендую. Можно посмотреть доклад с Google IO о возможностях нового ConstraintLayout (примерно с 29 минуты идет разговор о MotionLayout). Но удобнее почитать серию статей о начале работы с этим layout. Особенно понравилась третья часть, где описывается взаимодействие MotionLayout с другими библиотеками и компонентами: ViewPager, DrawerLayout, LottieAnimationView. Серия пополняется, поэтому дальше будет только интереснее.
Рефакторить или переписать с нуля?
#мысли
На глаза попалась статья Джоэля Спольски (основателя stackoverflow) о той ошибке, которую совершают часто многие программисты, приходящие в команду на новый проект — переписывание кода с нуля. Описывается пример браузера, о котором уже никто не знает — Netscape.
Уверен, что каждый из разработчиков слышал о том, что код, написанный предыдущей командой, ужасен, его нужно выкинуть и написать красиво: с продуманной архитектурой, с последними технологиями и подходами, с новыми библиотеками. Программисты в душе архитекторы, и их первое желание — пройтись бульдозером и построить что-то крутое. Однако, причина того, что разработчики хотят выбросить старый код и написать новый кроется в том, что читать код сложнее, чем его писать.
Например, получив огромную базу легаси кода, в которой функции по несколько страниц в длину, разработчик думает, что половина из этого кода лишняя, а вторая — вообще непонятно для чего и как работает. Но в чем причина такого огромного куска кода? Причина в том, что тут содержатся фиксы багов.
Старый код работает, он протестирован и исправлен. Многие баги сложно воспроизвести, другие же воспроизводятся только на определенных устройствах. Удалив весь код, разработчик удаляет и все труды, связанные с этим кодом.
Что же делать со старым кодом, который поддерживать не доставляет удовольствие? Думаю, что тут можно применить только одну стратегию: постепенный рефакторинг. Постепенное переписывание фич и экранов, а не удаление старой базы кода. Каким бы красивым ни был ваш код, совсем не факт, что он будет работать лучше. Думаю, что в будущих статьях напишу о том, как рефакторили код в тех командах, где я работал. А для нового кода не забывайте писать комментарии, когда происходит что-то странное.
#мысли
На глаза попалась статья Джоэля Спольски (основателя stackoverflow) о той ошибке, которую совершают часто многие программисты, приходящие в команду на новый проект — переписывание кода с нуля. Описывается пример браузера, о котором уже никто не знает — Netscape.
Уверен, что каждый из разработчиков слышал о том, что код, написанный предыдущей командой, ужасен, его нужно выкинуть и написать красиво: с продуманной архитектурой, с последними технологиями и подходами, с новыми библиотеками. Программисты в душе архитекторы, и их первое желание — пройтись бульдозером и построить что-то крутое. Однако, причина того, что разработчики хотят выбросить старый код и написать новый кроется в том, что читать код сложнее, чем его писать.
Например, получив огромную базу легаси кода, в которой функции по несколько страниц в длину, разработчик думает, что половина из этого кода лишняя, а вторая — вообще непонятно для чего и как работает. Но в чем причина такого огромного куска кода? Причина в том, что тут содержатся фиксы багов.
Старый код работает, он протестирован и исправлен. Многие баги сложно воспроизвести, другие же воспроизводятся только на определенных устройствах. Удалив весь код, разработчик удаляет и все труды, связанные с этим кодом.
Что же делать со старым кодом, который поддерживать не доставляет удовольствие? Думаю, что тут можно применить только одну стратегию: постепенный рефакторинг. Постепенное переписывание фич и экранов, а не удаление старой базы кода. Каким бы красивым ни был ваш код, совсем не факт, что он будет работать лучше. Думаю, что в будущих статьях напишу о том, как рефакторили код в тех командах, где я работал. А для нового кода не забывайте писать комментарии, когда происходит что-то странное.
Формы для ввода
#дизайн
Сегодня попалась крутая статья про правильный дизайн форм для ввода. Мне кажется, что мало какое приложение обходится без подобных экранов. Но даже экран с двумя полями для ввода логина и пароля, можно сделать или привлекательным, или отталкивающим.
Например, показ ошибки. При авторизации пользователь может ввести некорректный e-mail. Можно показать ошибку сразу после окончания ввода email, что даст возможность сразу исправить ошибку. Некорректным поведением является показ ошибок после нажания на кнопку логина.
Второй кейс — блокировка кнопки входа. Для входа в приложение необходимыми полями является e-mail и пароль, поэтому если у пользователя эти два поля пустые или некорректные, то кнопку следует блокировать.
В статье с примерам показываются распространенные ошибки дизайна. Рекомендую отправить эту статью знакомым дизайнерам, а также не допускать эти ошибки при создании форм.
#дизайн
Сегодня попалась крутая статья про правильный дизайн форм для ввода. Мне кажется, что мало какое приложение обходится без подобных экранов. Но даже экран с двумя полями для ввода логина и пароля, можно сделать или привлекательным, или отталкивающим.
Например, показ ошибки. При авторизации пользователь может ввести некорректный e-mail. Можно показать ошибку сразу после окончания ввода email, что даст возможность сразу исправить ошибку. Некорректным поведением является показ ошибок после нажания на кнопку логина.
Второй кейс — блокировка кнопки входа. Для входа в приложение необходимыми полями является e-mail и пароль, поэтому если у пользователя эти два поля пустые или некорректные, то кнопку следует блокировать.
В статье с примерам показываются распространенные ошибки дизайна. Рекомендую отправить эту статью знакомым дизайнерам, а также не допускать эти ошибки при создании форм.
Фокус группы
#мысли #продукт
Разработать мобильное приложение дорого и энергозатратно. И самое ужасное, что может случиться после запуска то, что оно никому не нужно. Ещё несколько неприятных итогов: такая идея уже реализована, приложение работает с багами, и прочее.
Чтобы уменьшить риски не только при старте, то и во время разработки существуют фокус-группы.
Фокус-группа — это несколько человек, которые являются потенциальными пользователями приложения. Для тестирования идеи создается прототип приложения. Прототип должен отражать главную идею приложения, и не должен иметь вылизанный дизайн или полностью реализованную функциональность.
Замечаю то, что если пользователям нравится продукт, то они будут плеваться, ненавидеть, но все равно использовать приложение. До тех пор, пока на рынке не появится продукт более высокого качества.
На прошедшей неделе наша команда создавала несколько прототипов и тестировала идеи, которые хотели реализовать. Классное чувство, когда ты здесь и сейчас видишь пользователя, который использует твое приложение, замечаешь его эмоции и понимаешь косяки, которые требуется исправить. Ведь пользователи — не какие-то идентификаторы в Firebase или Crashlytics, а реальные люди, которые пользуются приложением ежедневно.
Разработка прототипа достаточно дешева. Для старта приложения стоит задуматься про MVP, однако не пытайтесь сделать сразу все идеально. Объясняйте людям, что это только первая версия, а также смотрите за той реакцией, которая идет от пользователей.
#мысли #продукт
Разработать мобильное приложение дорого и энергозатратно. И самое ужасное, что может случиться после запуска то, что оно никому не нужно. Ещё несколько неприятных итогов: такая идея уже реализована, приложение работает с багами, и прочее.
Чтобы уменьшить риски не только при старте, то и во время разработки существуют фокус-группы.
Фокус-группа — это несколько человек, которые являются потенциальными пользователями приложения. Для тестирования идеи создается прототип приложения. Прототип должен отражать главную идею приложения, и не должен иметь вылизанный дизайн или полностью реализованную функциональность.
Замечаю то, что если пользователям нравится продукт, то они будут плеваться, ненавидеть, но все равно использовать приложение. До тех пор, пока на рынке не появится продукт более высокого качества.
На прошедшей неделе наша команда создавала несколько прототипов и тестировала идеи, которые хотели реализовать. Классное чувство, когда ты здесь и сейчас видишь пользователя, который использует твое приложение, замечаешь его эмоции и понимаешь косяки, которые требуется исправить. Ведь пользователи — не какие-то идентификаторы в Firebase или Crashlytics, а реальные люди, которые пользуются приложением ежедневно.
Разработка прототипа достаточно дешева. Для старта приложения стоит задуматься про MVP, однако не пытайтесь сделать сразу все идеально. Объясняйте людям, что это только первая версия, а также смотрите за той реакцией, которая идет от пользователей.
Собеседования
#мысли #совет
Решил составить пост о собеседованиях вместе с админом канала @java_developer. Хотя сейчас и тренд перехода на Kotlin, но знания Java никто не отменял, особенно при приеме на работу. Сам с удовольствием читаю этот канал и получаю новые знания. Крайне рекомендую и новичкам, и опытным разработчикам.
Уверен, что каждый разработчик приходит к мысли о том, что нужно менять работу. Бывает много причин, однако самые распространенные — это деньги и отсутствие роста. Этот пост поможет подготовиться к собеседованиям.
Первое на что стоит обратить внимание — теоретическая база. Написание кода — то, что вы делаете большую часть времени. Однако, без должной алгоритмической подготовки писать качественный код не получится. Разница между человеком, который знает алгоритмы, и между тем, который просто учился писать код очень заметна. Для подготовки рекомендую этот ресурс. Стоит знать базу про сортировки, структуры данных, сложности алгоритмов. Для прокачки себя в изучении алгоритмов рекомендую этот сайт, хотя есть и альтернативы.
Второе — вопросы, связанные с Android. Тут многое зависит от того, на какой уровень вы претендуете. Если junior, то это базовые вопросы: Activity, Fragment, верстка и другие. Если middle и seniour, то вопросы чаще связаны с архитектурой и применением специфических для проекта библиотек. Хороший список вопросов и ответов тут.
Нормальной практикой является тестовое задание, на основе которого идет принятие решения. Сложность задания также зависит от позиции, на которую претендуете.
#мысли #совет
Решил составить пост о собеседованиях вместе с админом канала @java_developer. Хотя сейчас и тренд перехода на Kotlin, но знания Java никто не отменял, особенно при приеме на работу. Сам с удовольствием читаю этот канал и получаю новые знания. Крайне рекомендую и новичкам, и опытным разработчикам.
Уверен, что каждый разработчик приходит к мысли о том, что нужно менять работу. Бывает много причин, однако самые распространенные — это деньги и отсутствие роста. Этот пост поможет подготовиться к собеседованиям.
Первое на что стоит обратить внимание — теоретическая база. Написание кода — то, что вы делаете большую часть времени. Однако, без должной алгоритмической подготовки писать качественный код не получится. Разница между человеком, который знает алгоритмы, и между тем, который просто учился писать код очень заметна. Для подготовки рекомендую этот ресурс. Стоит знать базу про сортировки, структуры данных, сложности алгоритмов. Для прокачки себя в изучении алгоритмов рекомендую этот сайт, хотя есть и альтернативы.
Второе — вопросы, связанные с Android. Тут многое зависит от того, на какой уровень вы претендуете. Если junior, то это базовые вопросы: Activity, Fragment, верстка и другие. Если middle и seniour, то вопросы чаще связаны с архитектурой и применением специфических для проекта библиотек. Хороший список вопросов и ответов тут.
Нормальной практикой является тестовое задание, на основе которого идет принятие решения. Сложность задания также зависит от позиции, на которую претендуете.
Code review
#разработка
Одним из процессов, который повышает качество кода в команде является code review.
В этом процессе принимают участие две стороны: автор кода и рецензент. Собственно, рецензент и принимает участие о добавлении кода в общую базу проекта.
На практике я сталкивался с двумя типами ревью:
• ревью проводит один человек (чаще всего тимлид)
• ревью проводят все члены команды, а решение в спорных ситуациях принимает тимлид.
Мне больше нравится второй вариант. Основным плюсом является то, что в процессе чтения кода принимают участие все члены команды, поэтому все понимают большую часть кодовой базы. Ну и тимлид может заняться другими делами, а не только ревьювить код.
Однако есть и недостатки ревью. Например психологическая сторона: по сути, ты указываешь на косяки в коде другому человеку. Мало кто из людей любит, когда им указывают на их ошибки, поэтому общение при ревью требует определенной деликатности. Каждой стороне необходимо отноститься к ревью как к способу обмена знаниями и способ улучшения кода. Ну и формулировки никогда не должны быть грубыми, какая бы глупая ошибка не была совершена.
А вы поводите ревью кода в своей команде?
#разработка
Одним из процессов, который повышает качество кода в команде является code review.
В этом процессе принимают участие две стороны: автор кода и рецензент. Собственно, рецензент и принимает участие о добавлении кода в общую базу проекта.
На практике я сталкивался с двумя типами ревью:
• ревью проводит один человек (чаще всего тимлид)
• ревью проводят все члены команды, а решение в спорных ситуациях принимает тимлид.
Мне больше нравится второй вариант. Основным плюсом является то, что в процессе чтения кода принимают участие все члены команды, поэтому все понимают большую часть кодовой базы. Ну и тимлид может заняться другими делами, а не только ревьювить код.
Однако есть и недостатки ревью. Например психологическая сторона: по сути, ты указываешь на косяки в коде другому человеку. Мало кто из людей любит, когда им указывают на их ошибки, поэтому общение при ревью требует определенной деликатности. Каждой стороне необходимо отноститься к ревью как к способу обмена знаниями и способ улучшения кода. Ну и формулировки никогда не должны быть грубыми, какая бы глупая ошибка не была совершена.
А вы поводите ревью кода в своей команде?
По последнему посту, связанному с ревью, подписчик прислал дополнения, которыми с радостью делюсь.
Есть еще такое ревью, которое проводят члены команды и решение принимается без тимлида.
Недостатки, помимо психологического фактора:
• время. Пулл реквесты могут накапливаться и есть риск не влезть в релиз из-за накопившегося ревью.
• зависимости. Если пуллреквест один, то терпимо, но если надо работать только после того, как будут смерджены чужие изменения (один код или PR в общую библиотеку), то ты будешь заблокирован до тех пор, пока не закончится кодревью.
• возможность удобной работы с инструментами CI: можно еще на уровне пулл реквеста прогнать все тесты, собрать целиком приложение, пройтись всеми линтами до того, как изменение попадет в мастер.
Также теоретически возможно инспекционное тестирование: когда инженер QA после ревью и прохождения СI-тестов сначала тестирует изменение, забирая его и собирая приложение с новым изменением, а потом уже позволяют мерджить, если тестирование прошло успешно.
P.S. Приятно, когда вы даете обратную связь по постам и присылаете #вопросы. Всегда на связи тут.
Есть еще такое ревью, которое проводят члены команды и решение принимается без тимлида.
Недостатки, помимо психологического фактора:
• время. Пулл реквесты могут накапливаться и есть риск не влезть в релиз из-за накопившегося ревью.
• зависимости. Если пуллреквест один, то терпимо, но если надо работать только после того, как будут смерджены чужие изменения (один код или PR в общую библиотеку), то ты будешь заблокирован до тех пор, пока не закончится кодревью.
• возможность удобной работы с инструментами CI: можно еще на уровне пулл реквеста прогнать все тесты, собрать целиком приложение, пройтись всеми линтами до того, как изменение попадет в мастер.
Также теоретически возможно инспекционное тестирование: когда инженер QA после ревью и прохождения СI-тестов сначала тестирует изменение, забирая его и собирая приложение с новым изменением, а потом уже позволяют мерджить, если тестирование прошло успешно.
P.S. Приятно, когда вы даете обратную связь по постам и присылаете #вопросы. Всегда на связи тут.