​​#заметка дня

#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 должен поддерживать как регистрозависимые файловые системы, так и регистронезависимые. Поэтому постарайтесь придерживаться одного правила в именовании.

Делитесь вашими примерами, дополним заметку.

#фишка дня

Залогиньтесь на GitHub, проследуйте в любой репозиторий и нажмите точку — .. Желательно иметь браузер посвежее.

Просто сообщаю…

#github #feature

#тред дня

Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.

Сегодня поговорим о код-ревью в треде от Олега Климакова.

Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.

Поехали.

1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.

2. Для начала - зачем это всё?

Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.

3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.

4. Способы чтобы иметь хорошо поддерживаемый код:

✅Покрытие тестами
✅Ведение документации
✅Код ревью

И все эти способы нужно уметь готовить. Есть тесты которые только мешают, бесполезная документация и бессмысленный код ревью.

5. Что даёт код ревью:

➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои

6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью

Дальше советы из моей практики. На объективность не претендую.

7.

❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все

В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.

8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.

9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом

В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.

10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).

Ваша задача как ревьюера получить такой код, который в случае болезни разработчика вы завтра будете поддерживать и не потонете.

11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.

Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее

12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.

Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.

13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код

Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо

#работа #pr #github #twitter

#ссылка дня

Кому тут было надо различных эффектов по наведению мыши? Их есть у меня.

Целый репозиторий всяческих :hover-правил: https://github.com/IanLunn/Hover

Название оригинальное: Hover.css :)

Есть и демо-страница: http://ianlunn.github.io/Hover/

Не могу сказать, что вы найдёте какие-то откровения там, но чекнуть стоит. Эффект завёрнутого уголка довольно забавный. Да и общий подход.

#css #hover #github