Я потихоньку выхожу из летней рутины. Почему-то, летом стало гораздо больше работы. К тому же, это тот период, который хочется больше проводить за границами четерых стен. Но этот период нужен, так как взяв паузу ты можешь сделать ретроспективу, посмотреть назад, вынести экшен айтемы и улучшить себя.
Так я формирую крепче свой контент и, не побоюсь этого слова, творчество. Оно строится на мнениях, фактах, сообществе и реальном опыте.
Отпуска заканчиваются. Начинаю приносить больше контента. На этот раз принес новый уникальный раздел, который почему-то аккуратно обходят другие. А я хочу делать на нем акценты.
Я нахожу себя. Мой контент становится более авторским. Я перестаю делать этот канал как десятки других — тупо выкладывать чужие статьи под сделанную за пять минут обложку в фигме. С развитием чатгпт качество и ценность такого контента падает. Я не хочу гордо называть это композицию "своим постом". Забавная такая приватизация.
Для этого нужно ревью. Умение адекватно прислушаться к фидбэку коллеги и внести фиксы. Да, из-за этого может показаться, что регулярность становится меньше, но качество только выигрывает. Так как имеет свойство настраиваться и концентрироваться.
Любое авторство не имеет место быть без публики и тонны фидбэка. Поэтому мне и нужен был чат. Он пишет комменты в моих реквестах. Не всегда комменты моих коллег понятны или приняты, но без них нельзя формировать свой стиль.
Пока остальные фокусируются на пересказе чужих статей или форме, то мы фокусируемся на контенте и личном уникальном опыте. Стараемся поднимать то, что поднимается только на реальной практике. В этом и различие авторского канала от новостного. Как говорится, чужой опыт ты не скопируешь просто прочитав книжку или статью. Личный уникальный опыт не может быть без кодревью. Без механизма валидации всех тех идей, которые ты собрал в очередной статье по чатгпт.
Честно признаюсь, Для меня кодревью — это одновременно самая важная и неважная вещь. С одной стороны, этот процесс помогает писать поддерживаемый код. С другой стороны, этот процесс не нужен, если были бы другие инструменты развития.
Но а пока таких процессов нет, то мы развиваем этот.
В любом бигтехе на код ревью часто уходит время больше, чем на само написания. Ведь читабельность кода часто превыше всего. Написанный код останется надолго и к нему нужно возвращаться спустя годы. Плохой процесс или его отсутствие может быть не только причиной плохого технического состояния проекта, но и даже причиной стресса или увольнения разработчиков.
Этот вопрос занимает много времени. Этому скиллу не научишься не пройдя реальный опыт в 10к комментов твоих реквестов.
Я собрал лучшие практики, книги, стайлгайды и советы, которые помогут писать код чище, улучшить процессы в команде и проходить ревью быстрее.
В этом блоке я собрал и буду собирать:
Я ценю всех, кто поддерживает. Качество моего контента зависит от адекватного фидбэка, моих интересов и ваших ожиданий.
Не нужно формировать мышление и знания на пересказах чужих статей. Только на реальном окружении и практических вещах. Через дискуссии и критическое мышление.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кодируем
Зачем нужны алгоритмы?
Получается, ты изучаешь инструмент ради интрумента, а не для полевых условий.
Много людей продолжают думать, что алгосики - это баловство, ненужная трата времени и нигде не применяются.
Я уже писал про это в постах про рекурсию.
Тажке общался с вами в видео про методы решения задач.
🧠 https://t.iss.one/koduryem/26
В двух последних видео много говорили про дп, ход мышления и подходы к проблемам.
Также у меня есть видео про другие темы, такие как Heap, BinarySearch, LRU, LFU и др.
Please open Telegram to view this post
VIEW IN TELEGRAM
Подборка статей про рефакторинг кода
Я буду много раз тут писать, что рынок меняется и становится сознательным. Навык рефакторинга кода становится более важным в современной разработке. Период активного роста, когда нужно было делать много фич, закончился. Сейчас время поддержки.
Где нужно лезть в чужой код разного качества, уметь его читать и интегрировать свои фичи. Это отдельный навык, к которому не все готовы.
Для знакомства я собрал пару базовых статей:
🟣 Refactoring Swift: Best Practices to succeed
🟣 How to Refactor Your Swift Code Like a Pro
🟣 Refactor Legacy Code with Swift
🟣 Refactoring iOS Apps – A Pragmatic Guide
Я буду много раз тут писать, что рынок меняется и становится сознательным. Навык рефакторинга кода становится более важным в современной разработке. Период активного роста, когда нужно было делать много фич, закончился. Сейчас время поддержки.
Где нужно лезть в чужой код разного качества, уметь его читать и интегрировать свои фичи. Это отдельный навык, к которому не все готовы.
Для знакомства я собрал пару базовых статей:
Please open Telegram to view this post
VIEW IN TELEGRAM
SwiftLee
Refactoring Swift: Best Practices to succeed
Refactoring code is essential to maintain quality and readability. Using best practices you'll become better at succeeding a big code change.
Хорошего программиста от теорика консультанта определяет только код.
Задачи на рефакторинг кода становятся все более популярные. Интервьюеры и компании уходят от формата вопрос/ответ и идут к более практическим вещам. Эрудицией никого не удивишь, загуглить ответ на вопрос не составит труда. Теория себя изжила и уже недостаточно просто заучить ответы, прочитать статью. Важно применять свои знания на практике.
Такие задачи хороши тем, что сразу помогают оценить знания и навыки разработчика по множеству тем: от знания языка, памяти и многопоточности, до запахов кода и архитектур. А также лучше помогают найти кандидатов с реальным практическим опытом, а не хорошим скиллом прохождения собесов. В нем сразу можно оценить сколько комментариев разной критичности придется писать коллеге на кодревью
В рамках нового блока кодревью я буду поднимать вопросы, задачи и темы по поводу написания кода и работе в командах. Ведь программист и отличается от консультанта, что много пишет код. А значит умеет легко должен давать оценку коду.
Здесь будет минимум теории и максимум кода. В текущем блоке я собрал задачи:
Также мы придумали новый тренажер в чате — рефакторить код известных либ или опенсоурсов: от телеграма до alamofire
Please open Telegram to view this post
VIEW IN TELEGRAM
Swift Regex Online
Как-то я делился туториалом как писать регулярные выражения, но нашел онлайн билдер регулярок для Swift. Тут даже есть парсер для нового DSL
Это очень полезно, когда вы не хотите запускать проект много раз и сразу хотите проверить свою регулярку на множестве кейсов.
Подробнее о Swift Regex можно узнать на одном из WWDC
А также есть хорошая обзорная статья для поверхностного ознакомления
Как-то я делился туториалом как писать регулярные выражения, но нашел онлайн билдер регулярок для Swift. Тут даже есть парсер для нового DSL
Это очень полезно, когда вы не хотите запускать проект много раз и сразу хотите проверить свою регулярку на множестве кейсов.
Подробнее о Swift Regex можно узнать на одном из WWDC
А также есть хорошая обзорная статья для поверхностного ознакомления
Swift Regex: Learn, build and test Swift Regex and Regex Builder.
Swift Regex: Learn, build and test Swift Regex
Regular Expression Tester with highlighting for Swift Regex. Quickly test and debug your regex and Regex Builder.
Так. Я в Казахстане.
Какие карты посоветуете открыть и что сделать для защиты от блокировок
Каспий тут на каком-то космическом уровне по отзывам. Будто цифровая революция в мире финансов
Какие карты посоветуете открыть и что сделать для защиты от блокировок
Каспий тут на каком-то космическом уровне по отзывам. Будто цифровая революция в мире финансов
Салам алейкум, братья и сестры
Побуду немного тревел блогером. В Казахстан я приехал не только за картой, но и познакомить свою жену с матерью. Я не видел мать 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