#заметка дня
#github #ghpages #tips
При работе с Github Pages мало кто заглядывает дальше раздела quick start. И вот очень зря.
Не претендую на полный список, но есть пара вещей, которые следует понимать всем.
1. Не начинайте названия каталогов и файлов с
2. URL — регистрозависимы. image.jpg и image.JPG — разные файлы. Это нарушает правила обработки URL, но у GH Pages есть право считать по-своему. Причина проста: GitHub должен поддерживать как регистрозависимые файловые системы, так и регистронезависимые. Поэтому постарайтесь придерживаться одного правила в именовании.
Делитесь вашими примерами, дополним заметку.
#github #ghpages #tips
При работе с Github Pages мало кто заглядывает дальше раздела quick start. И вот очень зря.
Не претендую на полный список, но есть пара вещей, которые следует понимать всем.
1. Не начинайте названия каталогов и файлов с
_ (подчёркивание), . (точка), # (октоторп) и не заканчивайте их ~ (тильда). С тильды, впрочем, начинать тоже не надо. Почему? Потому что гладиолус. Точнее, Jekyll. Именно его используют GH Pages для генерации ваших страниц: https://jekyllrb.com/docs/structure/ Пример с подчёркиванием — наиболее частый, не знаю, откуда взялась мода называть каталоги так. Для сортировки, видимо. Починить это, впрочем, легко — добавьте файл .nojekyll в ваш репозиторий.2. URL — регистрозависимы. image.jpg и image.JPG — разные файлы. Это нарушает правила обработки URL, но у GH Pages есть право считать по-своему. Причина проста: GitHub должен поддерживать как регистрозависимые файловые системы, так и регистронезависимые. Поэтому постарайтесь придерживаться одного правила в именовании.
Делитесь вашими примерами, дополним заметку.
This media is not supported in your browser
VIEW IN TELEGRAM
#тред дня
Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.
Сегодня поговорим о код-ревью в треде от Олега Климакова.
Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.
Поехали.
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