#тред дня
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.
2. Для начала - зачем это всё?
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.
3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
4. Способы чтобы иметь хорошо поддерживаемый код:
✅Покрытие тестами
✅Ведение документации
✅Код ревью
И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.
5. Что даёт код ревью:
➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои
6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью
Дальше советы из моей практики. На объективность не претендую.
7.
❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все
В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.
8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.
9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.
10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).
Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.
11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее
12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.
Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.
13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код
Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо
#работа #pr #github #twitter
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.
2. Для начала - зачем это всё?
Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.
3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.
4. Способы чтобы иметь хорошо поддерживаемый код:
✅Покрытие тестами
✅Ведение документации
✅Код ревью
И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.
5. Что даёт код ревью:
➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои
6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью
Дальше советы из моей практики. На объективность не претендую.
7.
❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все
В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.
8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.
9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом
В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.
10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).
Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.
11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.
Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее
12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.
Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.
13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код
Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо
#работа #pr #github #twitter
#шпаргалка дня
Уникальное предложение в рамках недели визуализации!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work
Уникальное предложение в рамках недели визуализации!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work
👍6
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work
🔥11👍3😁1
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
👍15❤3
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
👍14🤩2
#библиотека дня
Стандартный метод fetch, даром, что встроенный, представляет собой крайне удручающее зрелище, требующее огромное количество бойлерплейта — настроек — вокруг себя.
Поэтому многие до сих пор предпочитают axios, просто чтоб не связываться.
Мой друг и, какое совпадение, подписчик решил эти вопросы реализовав библиотеку extended-fetch, о которой я даже писал, с этим же введением: https://yangx.top/htmlshit/1290
Слово автору:
А теперь у него нашлось немного времени, так что он обновил библиотеку чтобы можно было в дженерике передавать свой тип возвращаемых запросом данных
https://github.com/glebcha/extended-fetch/tree/master#custom-response-type
то есть чтобы можно было делать так
Если не передавать ничего в дженерике и выполнять
По-моему, хорошая альтернатива axios-у, если неохота тянуть лишнего.
Камон, котаны, как ещё опенсорсу пиариться?
#fetch #axios #pr
Стандартный метод fetch, даром, что встроенный, представляет собой крайне удручающее зрелище, требующее огромное количество бойлерплейта — настроек — вокруг себя.
Поэтому многие до сих пор предпочитают axios, просто чтоб не связываться.
Мой друг и, какое совпадение, подписчик решил эти вопросы реализовав библиотеку extended-fetch, о которой я даже писал, с этим же введением: https://yangx.top/htmlshit/1290
Слово автору:
если очень обобщенно - это попытка вынести в абстракцию над fetch наиболее востребованный функционал axios
цели просты - максимально возможное следование спецификации, "сквозная" типизация, ноль зависимостей, изоморфный код (да, в nodejs сейчас undici как имплементация fetch)
А теперь у него нашлось немного времени, так что он обновил библиотеку чтобы можно было в дженерике передавать свой тип возвращаемых запросом данных
https://github.com/glebcha/extended-fetch/tree/master#custom-response-type
то есть чтобы можно было делать так
const api = createHttpClient();
interface Book {
id: string,
description?: string,
}
api.get<Book>('/api/books/12’)
Если не передавать ничего в дженерике и выполнять
api.get('/api/books/12'), то вернется объединение типов
Promise<string | Record<string, unknown> | RequestInit | Blob | ArrayBuffer | FormData>
По-моему, хорошая альтернатива axios-у, если неохота тянуть лишнего.
Камон, котаны, как ещё опенсорсу пиариться?
#fetch #axios #pr
👍24🤡7
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
👍7
#шпаргалка дня
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
Уникальное предложение!
Берёте короче эту пирамиду код-ревью и ваши пулл-реквесты станут не только вкусными, но и полезными: https://www.morling.dev/images/code_review_pyramid.svg
Такая себе пирамида Маслоу, но для обсуждения качества кода. От базовых вещей (но не опускаясь до того, что можно сделать автоматически) до того, что сделает ваш код действительно красивым.
#pr #process #work #бородач
👍11🤩3❤2🫡2