Так. Я в Казахстане.
Какие карты посоветуете открыть и что сделать для защиты от блокировок
Каспий тут на каком-то космическом уровне по отзывам. Будто цифровая революция в мире финансов
Какие карты посоветуете открыть и что сделать для защиты от блокировок
Каспий тут на каком-то космическом уровне по отзывам. Будто цифровая революция в мире финансов
Салам алейкум, братья и сестры
Побуду немного тревел блогером. В Казахстан я приехал не только за картой, но и познакомить свою жену с матерью. Я не видел мать 5 лет.
В Астане я жил с 2010 до 2016. Учился в политехническом колледже на прогера. Период поступления я вспоминаю как самый важный выбор в своей жизни. Тогда я выбирал либо поехать направо — пойти за друзьями и поступить как они в Кокшетау на ремонтника машин. Либо сломать систему и уйти учиться на тогда еще престижную профессию — программист. Со страхом вспоминаю что было бы, если выбрал другой путь.
Всем тем, кто критикует образование скажу, что вы не понимаете какой это мощный социальный лифт. Пусть даже есть и другие лифты, непорядочные и спорные, но образовательный дает самый крепкий путь. Да и чем жестче условия, тем лучше ты понимаешь, что кроме твоих развития навыков ничто другое не заслуживает времени. Его просто опасно напрасно тратить.
Спустя почти десять лет я смотрю на того себя. Город мощной энергии. Не смотря на вычурную архитектуру в нем всегда было что-то первобытное, в хорошем смысле. Конечно, после Москвы все выглядит миниатюрно, хотя в детстве казалось огромным. Но в каждом городе есть своя уникальная атмосфера.
Этот город стал для меня крепкой школой жизнь, где долгое время я жил в полной самостоятельности. Стараясь пережить трудности, найти и не потерять себя.
Круто, что сейчас есть куча инструментов образования и как же интернет облегчает нам всем жизнь.
Побуду немного тревел блогером. В Казахстан я приехал не только за картой, но и познакомить свою жену с матерью. Я не видел мать 5 лет.
В Астане я жил с 2010 до 2016. Учился в политехническом колледже на прогера. Период поступления я вспоминаю как самый важный выбор в своей жизни. Тогда я выбирал либо поехать направо — пойти за друзьями и поступить как они в Кокшетау на ремонтника машин. Либо сломать систему и уйти учиться на тогда еще престижную профессию — программист. Со страхом вспоминаю что было бы, если выбрал другой путь.
Всем тем, кто критикует образование скажу, что вы не понимаете какой это мощный социальный лифт. Пусть даже есть и другие лифты, непорядочные и спорные, но образовательный дает самый крепкий путь. Да и чем жестче условия, тем лучше ты понимаешь, что кроме твоих развития навыков ничто другое не заслуживает времени. Его просто опасно напрасно тратить.
Спустя почти десять лет я смотрю на того себя. Город мощной энергии. Не смотря на вычурную архитектуру в нем всегда было что-то первобытное, в хорошем смысле. Конечно, после Москвы все выглядит миниатюрно, хотя в детстве казалось огромным. Но в каждом городе есть своя уникальная атмосфера.
Этот город стал для меня крепкой школой жизнь, где долгое время я жил в полной самостоятельности. Стараясь пережить трудности, найти и не потерять себя.
Круто, что сейчас есть куча инструментов образования и как же интернет облегчает нам всем жизнь.
Кстати, мы днях записали тестовое моковое собеседование. Я создал новый закрытый телеграм канал. Туда заливать только записи мок-собесов по рефакторингу и платформе.
В нем затронули 6 задач по темам:
Доступ только старичков с подпиской больше 3 месяца, а остальных только по подписчике мидл+.
Кому нужен доступ пишите в лс @lvbond
А также ищу добровольцев пройти или провести собес на любую тему. Участие и доступ к новому каналу бесплатные
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Карьера в FAANG
Повышение уровня в FAANG транслируется в повышение материального достатка, но более сложную рабочую жизнь из за повышения ответственности. Но мало кто знает, что, одновременно с этим, повышение уровня еще и облегчает инженеру работу. Поговорим о том, почему так получается.
Многие люди на интуитивном уровне думают, что повышение уровня -- это вознаграждение за хорошую работу. Это заблуждение. Вознаграждение -- это нечто одностороннее. А повышение уровня -- это двусторонний "контракт" между работником и компанией. И я не имею в виду буквальный переподписанный контракт на новую ЗП. Я говорю о неформальном контракте. Все понимают, что при повышении сотрудник обязуется выполнять работу на следующем уровне. Но мало кто знает, что этот контракт двусторонний -- компания обязуется дать сотруднику свободу работать на этом следующем уровне.
Что это значит -- дать свободу работать? У этого обязательства есть две части: формальная и неформальная. Формальная часть заключается буквально в том, что с вами нельзя работать, как с сотрудником предыдущего уровня. Разберем на примере: главная разница между Junior и Middle уровнями -- способность самостоятельно выполнять задачи. Когда сотрудник на Junior уровне доказывает эту свою способность, ему предлагают повышение до Middle позиции, где он уже обязуется продолжать консистентно выполнять сложные задачи самостоятельно. Но одновременно с этим компания (в лице менеджера, техлида, коллег) так же обязуется уважать эту способность сотрудника и не лезть к нему с попытками смотреть на его работу из за спины, требовать частых чек-инов, пытаться вести его за руку через сложности. Вся та помощь, которая была очень полезна Junior инженеру, чтобы быстро учиться, превращается в препятствие, только мешающее работе Middle инженера. И компания обязуется устранить это препятствие, что повышает его эффективность, и сильно упрощает его жизнь.
Помимо формальной части, есть и неформальная: коллеги, узнавая ваш уровень, автоматически доверяют вам делать работу на этом уровне. Доверие -- это очень мощный ресурс, который умножает ваши усилия. Вы познакомились с коллегой из другой команды и предложили ему интеграцию систем? Если вы уже Senior инженер, то коллега автоматически знает, что вы способны достигать поставленных целей и уверен, что вести с вами дела надежно. Вам значительно проще убедить его работать с вами в команде. Делать работу в атмосфере доверия гораздо проще и приятнее. Этот эффект дает мощный буст в качестве жизни.
И формальное и неформальное обещание компании дать вам свободу работать на вашем уровне -- это серьезная проблема для компании в целом, а так же для вашего руководителя и команды, в том случае, если эту свободу дали вам по ошибке. Это еще один фактор, почему повышения в FAANG так сложны. Нужно серьезно доказать, что когда кандидат получит новую свободу, он не растеряется и не провалит новые задачи.
#promo
Многие люди на интуитивном уровне думают, что повышение уровня -- это вознаграждение за хорошую работу. Это заблуждение. Вознаграждение -- это нечто одностороннее. А повышение уровня -- это двусторонний "контракт" между работником и компанией. И я не имею в виду буквальный переподписанный контракт на новую ЗП. Я говорю о неформальном контракте. Все понимают, что при повышении сотрудник обязуется выполнять работу на следующем уровне. Но мало кто знает, что этот контракт двусторонний -- компания обязуется дать сотруднику свободу работать на этом следующем уровне.
Что это значит -- дать свободу работать? У этого обязательства есть две части: формальная и неформальная. Формальная часть заключается буквально в том, что с вами нельзя работать, как с сотрудником предыдущего уровня. Разберем на примере: главная разница между Junior и Middle уровнями -- способность самостоятельно выполнять задачи. Когда сотрудник на Junior уровне доказывает эту свою способность, ему предлагают повышение до Middle позиции, где он уже обязуется продолжать консистентно выполнять сложные задачи самостоятельно. Но одновременно с этим компания (в лице менеджера, техлида, коллег) так же обязуется уважать эту способность сотрудника и не лезть к нему с попытками смотреть на его работу из за спины, требовать частых чек-инов, пытаться вести его за руку через сложности. Вся та помощь, которая была очень полезна Junior инженеру, чтобы быстро учиться, превращается в препятствие, только мешающее работе Middle инженера. И компания обязуется устранить это препятствие, что повышает его эффективность, и сильно упрощает его жизнь.
Помимо формальной части, есть и неформальная: коллеги, узнавая ваш уровень, автоматически доверяют вам делать работу на этом уровне. Доверие -- это очень мощный ресурс, который умножает ваши усилия. Вы познакомились с коллегой из другой команды и предложили ему интеграцию систем? Если вы уже Senior инженер, то коллега автоматически знает, что вы способны достигать поставленных целей и уверен, что вести с вами дела надежно. Вам значительно проще убедить его работать с вами в команде. Делать работу в атмосфере доверия гораздо проще и приятнее. Этот эффект дает мощный буст в качестве жизни.
И формальное и неформальное обещание компании дать вам свободу работать на вашем уровне -- это серьезная проблема для компании в целом, а так же для вашего руководителя и команды, в том случае, если эту свободу дали вам по ошибке. Это еще один фактор, почему повышения в FAANG так сложны. Нужно серьезно доказать, что когда кандидат получит новую свободу, он не растеряется и не провалит новые задачи.
#promo
Ищу доклады на конференцию
Пока у меня небольшой отпуск и в канале будет меньше постов.
Тут я вписался в небольшую активность и стал членом программного комитета конференции от Сколково.
В ближайший год я сам хочу начать выступать, но для этого сначала изучить кухню изнутри.
Эта конференция мне нравится тем, что выглядит все экспертно и профессионально. А ребята, что организуют, проверены опытом и имеют уважение.
Если вы хотите начать развиваться как спикер и доносить свои идеи, экспертизу и мысли до аудитории, то пишите мне @lvbond
Мы поможем с докладом, подготовкой и всем остальным.
Пока у меня небольшой отпуск и в канале будет меньше постов.
Тут я вписался в небольшую активность и стал членом программного комитета конференции от Сколково.
В ближайший год я сам хочу начать выступать, но для этого сначала изучить кухню изнутри.
Эта конференция мне нравится тем, что выглядит все экспертно и профессионально. А ребята, что организуют, проверены опытом и имеют уважение.
Если вы хотите начать развиваться как спикер и доносить свои идеи, экспертизу и мысли до аудитории, то пишите мне @lvbond
Мы поможем с докладом, подготовкой и всем остальным.
skolkovo2024.mergeconf.ru
IT-конференция Merge в Сколково
Профессиональная межрегиональная IT-конференция | 15-16 ноября 2024, Технопарк Сколково
Inversion of Control in Swift: A Path to Cleaner Code
В мобильной разработке солиды и дизайн паттеры — это главный стандарт писать свой код чище и понятней. Я считаю, что избыточная уникальность и авторские подходы к коду, это лишнее усложнение.
Код пишут, чтобы был понятен другим разработчикам. Очень много крутых идей дохнут когда их адоптят умные, но несоциализированные интроверты. Они не пишут доки (или пишут так, что понятны только им). Не собирают обратную связь от коллег (или собирают для вида).
Все эти ваши паттерны, архитектуры, принципы — это все, чтобы сформулировать принципы разработки и сделать коммуникацию понятной.
Вообще без разницы кто там что сказал когда-то и какой автор был более прав. Важнее что лучше помогает решить проблему, а не как правильно изучил чужую догму
В мобильной разработке солиды и дизайн паттеры — это главный стандарт писать свой код чище и понятней. Я считаю, что избыточная уникальность и авторские подходы к коду, это лишнее усложнение.
Код пишут, чтобы был понятен другим разработчикам. Очень много крутых идей дохнут когда их адоптят умные, но несоциализированные интроверты. Они не пишут доки (или пишут так, что понятны только им). Не собирают обратную связь от коллег (или собирают для вида).
Все эти ваши паттерны, архитектуры, принципы — это все, чтобы сформулировать принципы разработки и сделать коммуникацию понятной.
Вообще без разницы кто там что сказал когда-то и какой автор был более прав. Важнее что лучше помогает решить проблему, а не как правильно изучил чужую догму
Medium
Inversion of Control in Swift: A Path to Cleaner Code
In app development, as applications grow in complexity, the tight coupling of classes and components can become a significant bottleneck…
Очередной секрет успеха
Нам очень долго пихают инфу, что главный секрет богатства — уметь продавать свой час дороже. Мне кажется, эта установка пришла из аутсорсов и бодишопов. Я не переношу эту установку, которая продает мою жопу. Будто не имея за нее власть.
Галера продает гребцов другим работодателям и получает за тебя процент. Чем дороже твой час, тем больше денег у галеры, но не всегда у тебя.
Для меня такое мышление неправильное и разочаровывающее. Пока ты продаешь свои часы, то чаще упускаешь возможности и время.
Для себя я вывел другую формулу, по которой мне нужно двигаться — приносить ценность. Твоя ценность прямо пропорциональна количеству и качеству принесенной тебе ценности, а не накрученной и проданной.
В ней я вижу боевой клич, который сжимает в кулак множество идей. От экономических основ, до подходящей этической модели.
Основная идея моих действий — приносить пользу. Уверен, что это главный актив социума. Иначе ты паразит.
Как же найти эту ценность? Еще одна цель — это быть экспертом в своей области и стараться обрести уникальную экспертизу и навыки, которые ее дают. Пока мне работается —работать усердно. Докопать до золота.
Это очень простая мысль, но которую часто мне сложно донести.
Нам очень долго пихают инфу, что главный секрет богатства — уметь продавать свой час дороже. Мне кажется, эта установка пришла из аутсорсов и бодишопов. Я не переношу эту установку, которая продает мою жопу. Будто не имея за нее власть.
Галера продает гребцов другим работодателям и получает за тебя процент. Чем дороже твой час, тем больше денег у галеры, но не всегда у тебя.
Для меня такое мышление неправильное и разочаровывающее. Пока ты продаешь свои часы, то чаще упускаешь возможности и время.
Для себя я вывел другую формулу, по которой мне нужно двигаться — приносить ценность. Твоя ценность прямо пропорциональна количеству и качеству принесенной тебе ценности, а не накрученной и проданной.
В ней я вижу боевой клич, который сжимает в кулак множество идей. От экономических основ, до подходящей этической модели.
Основная идея моих действий — приносить пользу. Уверен, что это главный актив социума. Иначе ты паразит.
Как же найти эту ценность? Еще одна цель — это быть экспертом в своей области и стараться обрести уникальную экспертизу и навыки, которые ее дают. Пока мне работается —работать усердно. Докопать до золота.
Это очень простая мысль, но которую часто мне сложно донести.
Продолжаю делиться контентом и на очереди мок собес по алгосам.
В закрытом голосовании, среди платных подписчиков, выиграл систем дизайн, а алгосы заняли последнее место. Но я посчитал, что к алго-собесу сложней всего подготовиться и поэтому нужен пробник. Потому что он требует самых практичных навыков — уметь писать код
Вопреки всеобщему заблуждению, во всех алгособесах нет расчета на то, что вы знаете сложные и редкие алгоритмы.
Мы решили показать что оценивают на примере простейших задач:
Please open Telegram to view this post
VIEW IN TELEGRAM
Что выведется в консоли?
Anonymous Quiz
40%
Будет всегда одно число
38%
Числа будут разные
7%
Произойдет ошибка компиляции
10%
Ничего не вызовется
4%
Другое
Что вызовется в консоли №2?
Anonymous Quiz
59%
Будет всегда одно число
27%
Числа будут разные
7%
Будет ошибка компиляции
5%
Ничего не вызовется
2%
Другое
Масштабирование приложений на iOS
Как говорится, old, but gold. Хороший доклад на тему недели — как правильно масштабировать приложение.
Рано или поздно многие разработчики сталкиваются с необходимостью правильной организации апки и все не знают с чего начать.
В этом докладе разбирают:
🟣 модуляризацию
🟣 версионированность
🟣 правильное управление зависимостями
🟣 какие предстоят челенджи
Как говорится, old, but gold. Хороший доклад на тему недели — как правильно масштабировать приложение.
Рано или поздно многие разработчики сталкиваются с необходимостью правильной организации апки и все не знают с чего начать.
В этом докладе разбирают:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Scaling up an iOS Codebase • Tjeerd In't Veen • GOTO 2019
This presentation was recorded at GOTO Copenhagen 2019. #GOTOcon #GOTOcph
https://gotocph.com
Tjeerd In't Veen - Author of Swift in Depth
ABSTRACT
We’ll cover the challenges that arise when we start working with frameworks and versioning. We’ll cover…
https://gotocph.com
Tjeerd In't Veen - Author of Swift in Depth
ABSTRACT
We’ll cover the challenges that arise when we start working with frameworks and versioning. We’ll cover…
Практики кодревью в гугле
Для меня процесс кодревью очень важен. Я даже когда-то ливнул из одной компании, потому что его толком не было и на споры в комментах или экстрасенсорику требовалось больше сил, чем на всю работу вместе взятую.
Подсмотрел в черновиках одного бывшего руководителя Никиты Хромушкина пост про кодревью (потом репостну). В нем он расскажет про хорошие практики, где качество и скорость должны быть в балансе.
В нем он много ссылается на этот гайд. Вот пара интересных мыслей:
🟣 кодревью должно быть быстрым.
Я сам сторонники быстрых кодревью, если они буксуют и идут медленно, то значит проблемы в процессах онбординга и технической культуре команды.
До написания реквеста разраб должен минимизировать все возможные комментарии и подготовить код по общим правилам.
Множество комментариев же говорит о несогласованности и несформулированности критериев качества в команде.
🟣 делайте атомарные реквесты
База. Огромный реквест сложно ревьюить и нередко бывает, что многое упускается
Лучше делать множество маленьких, чем один большой. Стандартный закон «разделяй и властвуй»
🟣 код не должен быть идеален.
Это одно из главных правил, когда тебе попадается душнила, который пишет в один день одни комменты, а на следующий другие. Часто, противоречащие друг другу.
Главное правило «код должен немного улучшать текущую кодовую базу». Не нужно искать идеала
🟣 критикуешь — предлагай
Это еще один из самых бесячих процессов, когда тот же душнила пишет тебе абстрактно или без деталей «это не подходит». Такие комментарии не несут пользы и чаще тратят время. Ведь ты пытаешься угадать логику ревьюера (которая может быть ошибочна). вместо того, чтобы он сам предложил свое решение. Так легче проревьють обоих.
💎 Ну а я напоминаю про новый раздел кодревью, где уже есть и скоро будут новые крутые материалы
Для меня процесс кодревью очень важен. Я даже когда-то ливнул из одной компании, потому что его толком не было и на споры в комментах или экстрасенсорику требовалось больше сил, чем на всю работу вместе взятую.
Подсмотрел в черновиках одного бывшего руководителя Никиты Хромушкина пост про кодревью (потом репостну). В нем он расскажет про хорошие практики, где качество и скорость должны быть в балансе.
В нем он много ссылается на этот гайд. Вот пара интересных мыслей:
Я сам сторонники быстрых кодревью, если они буксуют и идут медленно, то значит проблемы в процессах онбординга и технической культуре команды.
До написания реквеста разраб должен минимизировать все возможные комментарии и подготовить код по общим правилам.
Множество комментариев же говорит о несогласованности и несформулированности критериев качества в команде.
База. Огромный реквест сложно ревьюить и нередко бывает, что многое упускается
Лучше делать множество маленьких, чем один большой. Стандартный закон «разделяй и властвуй»
Это одно из главных правил, когда тебе попадается душнила, который пишет в один день одни комменты, а на следующий другие. Часто, противоречащие друг другу.
Главное правило «код должен немного улучшать текущую кодовую базу». Не нужно искать идеала
Это еще один из самых бесячих процессов, когда тот же душнила пишет тебе абстрактно или без деталей «это не подходит». Такие комментарии не несут пользы и чаще тратят время. Ведь ты пытаешься угадать логику ревьюера (которая может быть ошибочна). вместо того, чтобы он сам предложил свое решение. Так легче проревьють обоих.
Please open Telegram to view this post
VIEW IN TELEGRAM
eng-practices
Introduction {#intro}
Google’s Engineering Practices documentation
Зачем тогда нужен кодревью?
У нас в чате подняли справедливый вопрос «вот я хочу понять что сделал автор в своем реквесте. Оценить риски, понять как интегрироваться с системой. Где мне это делать?»
Точно не на этапе, когда код был написан и сдан на проверку.
Знакомство с фичей должно быть раньше. Задолго до того, когда код начнут писать. Должно быть знакомство с будущей технологией, ее интеграцией и процессом раскатки.
В авито это решается через TDR (tech design review). Именно там происходят все жаркие беседы и спор куда и зачем что пихнуть.
В мобилке они не так сильно развиты, но мне кажется, потому что пока мы не сильно знакомы с этим.
Подробнее о них можно почитать тут и тут
У нас в чате подняли справедливый вопрос «вот я хочу понять что сделал автор в своем реквесте. Оценить риски, понять как интегрироваться с системой. Где мне это делать?»
Точно не на этапе, когда код был написан и сдан на проверку.
Знакомство с фичей должно быть раньше. Задолго до того, когда код начнут писать. Должно быть знакомство с будущей технологией, ее интеграцией и процессом раскатки.
В авито это решается через TDR (tech design review). Именно там происходят все жаркие беседы и спор куда и зачем что пихнуть.
В мобилке они не так сильно развиты, но мне кажется, потому что пока мы не сильно знакомы с этим.
Подробнее о них можно почитать тут и тут
Telegram
Product Developer
Technical Design Review (TDR)
Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.
Но у кодревью есть…
Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.
Но у кодревью есть…
Forwarded from Product Developer (Nikita Khromushkin)
Культура код-ревью: приоритеты и скорость
Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект
Альтернативы есть: парное программирование или TDR. Но они подходят не всем.
Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.
Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.
👨💻 Удовлетворение на этапе открытия PR
Speed of Code Reviews
Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?
Так происходит, если написание нового кода поощряется больше, чем ревью.
Команда отличается от рабочей группы наличием общей цели. Для команды должно быть важнее дотолкать цель до прода, чем написать как можно больше кода.
А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»
🤌 Огромные PR
Why Write Small CLs
Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.
- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения
Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.
🏓 Ревью-пинг-понг
Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?
1️⃣ — Новые комменты к нетронутому коду
Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.
Так может происходить, если ревьювер цепляется то за одно, то за другое.
Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».
Могут помочь статьи What to look for in a code review и Navigating in ChangeList.
2️⃣ — Комменты к исправлениям
Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.
- Стоит объяснять, почему просишь изменений.
- Стоит разделять обязательные к исправлению пункты и опциональные.
- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».
How to write Review Comments
===
Итог
Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.
Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?
Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект
Альтернативы есть: парное программирование или TDR. Но они подходят не всем.
Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.
Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.
👨💻 Удовлетворение на этапе открытия PR
Speed of Code Reviews
Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?
Так происходит, если написание нового кода поощряется больше, чем ревью.
Команда отличается от рабочей группы наличием общей цели. Для команды должно быть важнее дотолкать цель до прода, чем написать как можно больше кода.
А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»
🤌 Огромные PR
Why Write Small CLs
Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.
- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения
Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.
🏓 Ревью-пинг-понг
Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?
1️⃣ — Новые комменты к нетронутому коду
Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.
Так может происходить, если ревьювер цепляется то за одно, то за другое.
Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».
Могут помочь статьи What to look for in a code review и Navigating in ChangeList.
2️⃣ — Комменты к исправлениям
Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.
- Стоит объяснять, почему просишь изменений.
- Стоит разделять обязательные к исправлению пункты и опциональные.
- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».
How to write Review Comments
===
Итог
Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.
Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?
Forwarded from Кодируем
Как написать чистый код?
⭐️ Угадываем, что хотел ввести юзер. Немного говорим про low coupling & high cohesion.
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть, чтобы получалось писать чистый и читаемый код даже там, где есть алгоритмы. Какие есть способы? Как начать разрабатывать и писать код? Как приступить? Декомпозируем задачу на каждом уровне абстракции, спускаемся ниже и ниже и решаем проблемы по мере поступления.
🚀 Сделаем программу, которая угадывает, какую команду хотел вызвать пользователь, но ошибся при написании. Мы подскажем ему, какие похожие варианты есть в нашей системе.
🚀 Мы сделаем максимально легковесно без фреймворков и баз данных и полнотекстовых поисковых систем. Просто возьмем и добавим маленькую и полезную фичу.
🚀 Также сделаем так, чтобы наш код был максимально понятный и читаемый. Чтобы мы могли понять все структуру программы, прочитав пару первых функций на самом высоком уровне.
🚀 Нарисуем все основные части нашей программы.
Ньюансы (чтобы экономить время):
❗️ Я не стал покрывать все типами, но это обязательно нужно делать
❗️ Я не стал покрывать тестами, но это очень сильно помогает для понимания кода, его надежности и поддержки
❓ Соберем вместе фреймворк по чистому коду? Как использовать паттерны, принципы. В чем плюсы и минусы. Сложно или нет это делать? Какие принципы знаете уже или хотите услышать? Чтобы "берешь и используешь" его. Чтобы не спорить "А вот смотри наглядно - это не вкусовщина, а у тебя переплетается логика или потекли абстракции - это плохо и тд". Если будут мысли - пишите. Это было бы очень круто. И это совсем иное, нежели бестолковые часто style guides и code reviews
Video:
https://www.youtube.com/watch?v=GsGyrrSC8Rw
Links:
https://en.wikipedia.org/wiki/Levenshtein_distance
#Algorithms #Clean_Code
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть, чтобы получалось писать чистый и читаемый код даже там, где есть алгоритмы. Какие есть способы? Как начать разрабатывать и писать код? Как приступить? Декомпозируем задачу на каждом уровне абстракции, спускаемся ниже и ниже и решаем проблемы по мере поступления.
Ньюансы (чтобы экономить время):
Video:
https://www.youtube.com/watch?v=GsGyrrSC8Rw
Links:
https://en.wikipedia.org/wiki/Levenshtein_distance
#Algorithms #Clean_Code
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как написать чистый код? Угадываем что ввел юзер и дизайним с нуля(общий подход) Clean Code Approach
Telegram post: https://t.iss.one/koduryem/38
Как написать чистый код? Угадываем, что хотел ввести юзер. Немного говорим про low coupling & high cohesion.
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть,…
Как написать чистый код? Угадываем, что хотел ввести юзер. Немного говорим про low coupling & high cohesion.
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть,…
Я, хз. Но за Пашу болеешь как за своего кента которого участковый забрал по ошибке.
Французы те еще борцы за свободу. Абсурдность ситуации такая же, как если накрутчики опыта спорили с рекрутерами и обвиняли сторонние силы в своих проблемах.
Хотя, подождите…
Французы те еще борцы за свободу. Абсурдность ситуации такая же, как если накрутчики опыта спорили с рекрутерами и обвиняли сторонние силы в своих проблемах.
Хотя, подождите…
Советы по выгоранию для ит специалистов
Выгорание — серьезная вещь. Когда ты молодой и неопытный ты думаешь, что эта проблема касается только тех, кто ноет. Ее не существует и ее выдумали.
Иногда об этом любят говорить «эффективные менеджеры», которые бьют кнутом по спине. А потом все удивляются когда человек уходит из компании.
Мой отпуск заканчивается и я был рад, что почти не думал о работе. Уметь восстановить ресурсы очень важная вещь и наконец, мой отпуск принёс желание делать еще больше дел. Решать задачки 🙂
Я задумываюсь о ресурс менеджменте все чаще. Вот интересная статья для инженеров. Наша специфика работы и задачи могут не всегда дать понять, что нам нужен отпуск.
Мониторинг нашего здоровья и правильные привычки — залог успеха.
Выгорание — серьезная вещь. Когда ты молодой и неопытный ты думаешь, что эта проблема касается только тех, кто ноет. Ее не существует и ее выдумали.
Иногда об этом любят говорить «эффективные менеджеры», которые бьют кнутом по спине. А потом все удивляются когда человек уходит из компании.
Мой отпуск заканчивается и я был рад, что почти не думал о работе. Уметь восстановить ресурсы очень важная вещь и наконец, мой отпуск принёс желание делать еще больше дел. Решать задачки 🙂
Я задумываюсь о ресурс менеджменте все чаще. Вот интересная статья для инженеров. Наша специфика работы и задачи могут не всегда дать понять, что нам нужен отпуск.
Мониторинг нашего здоровья и правильные привычки — залог успеха.