Сегодня мы начнём день с полезного роадмэпа для разработчика в 2020-ом году.

Он составлен для тех, кто ещё только на пути становления разработчиком и не до конца выбрал своё направление.
Ты поймёшь:
✅какими умениями стоит владеть
✅за какие инструменты браться
✅описание резюме при поиске открытых вакансий
✅куда идти дальше и т.п.

В этом роадмэпе ты найдешь “скелет” профессии разработчика в целом, на который сможешь опираться в процессе профессионального развития.

К роудмэпу прилагается видео-объяснение (конкретно про бэкенд смотреть с 18:40). Информация предоставлена на английском, однако мы уверены, что для тебя это не проблема! Любой хороший разработчик должен знать английский, а со всеми терминами и понятиями из роадмэпа тебе так или иначе в будущем придется взаимодействовать.

Мы не утверждаем, что этот путеводитель единственно правильный, однако многие уже состоявшиеся программисты признают, что им было бы намного проще, если бы кто-то в своё время предоставил им подобную информацию.
Держим тебя в курсе =)
#тематическаянеделя_backend
#лонгрид #обучение_в_IT

Кто уже вовсю пользуется Git для своей работы? В частности, журналом изменений?
Когда работаешь над проектом в команде, то без журнала изменений не обойтись, так как он ведет протокол любых модификаций в проекте.

Это довольно удобно, потому что: 
✅ каждый участник проекта может отследить кем, когда и какие изменения были внесены; 
✅ можно продолжить работу напарника, экономя при этом время на лишние объяснения;
✅ прививается навык писать подробные комментарии к коммитам.

Предлагаем прочесть техническую статью о том, как создать журнал изменений в Git. Там описаны два способа: 
▪️простой (путем копирования и вставки git-коммитов);
▪️сложный (путем преобразования списков git-коммитов в журналы изменений).

Спойлер: в работе над профессиональным продуктом следует использовать сложный способ. 😉
#тематическаянеделя_backend #коротко_о_главном #обучение_в_IT

Всем привет! 
Вчера мы писали о создании журнала изменений, а сегодня мы поговорим для чего он нам пригодится. Code review - процесс, когда рецензент (reviewer) анализирует код, оставляет комментарии с желаемым списком изменений и, в конце, решает когда этот код будет готов попасть в репозиторий проекта. 

Итак, зачем нужен code review? 

• проверка качества кода;
• метод обучения новых людей в команде;
• помогает избежать повторных ошибок;
• делать архитектурное review посредством code review;

Безусловно, делать code review надо, но это долгий и трудный процесс. Он может быть выполнен одним человеком за короткое время, а может затянуться на N-часов митинга, где вся команда будет разбирать код по каждой строчке. В идеальном мире, программисты бы воспринимали критику с радостью как инструмент для развития и улучшения навыков, но часто каждый комментарий воспринимается как личное оскорбление. 

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

Решение — автоматизация (что далеко не секрет). Стоит чаще напоминать, что прежде чем дать рецензенту код на проверку или прежде чем проверять код самостоятельно (если ты reviewer), надо пройти автоматическую валидацию кода. Для часто встречающихся задач: проверка билдов, стиля, идентификация неиспользуемых модулей и т.п., - уже есть автоматизированное решение.

Автоматизация — это залог быстрого, качественного и четко аргументированного code review.

Предлагаем тебе прочесть статью “Практики хорошего code review, или что такое code review за 15 минут”, в которой описаны частые проблемы code review, причины этих проблем и их решения.


Всем чистого, функционального и красивого кода!😌
#тематическаянеделя_backend
#лонгрид #карьера_в_IT