Полтора года назад я решил, что готов к карьерной смене. Я много слышал о школе Тьюринга и решил попробовать один из их Try Coding выходных. Я посещал занятия весь день в субботу и воскресенье, изучая основы моей оболочки, Ruby и JavaScript. Я был подключен. Я посещал программу Back End Engineering с января по август 2018 года. В основном мы сосредоточились на Ruby on Rails с небольшим количеством JavaScript и других технологий.
Я окончил учебный лагерь в августе 2018 года и начал работать в Viget в следующем месяце. Я нервничал, ожидая, что мои знания Rails будут намного хуже, чем у других разработчиков, которые работают в этой среде уже много лет. Конечно, было еще много Rails для освоения, но я был удивлен всем другим вещам, которые можно было изучить. В школе все остальное было ошеломляющим отвлечением от того, на чем я думал, что я должен был сосредоточиться — на Rails.
Я был так сосредоточен на изучении деталей этой магической структуры, что игнорировал множество других вещей. Мне часто приходилось запускать sudo перед командами, когда другим это не нужно. Я запутался в управлении различными версиями Ruby и просто изменил .ruby-version и обновил все, чтобы сделать мою жизнь проще. Моя философия заключалась в том, зачем тратить время на решение проблем такого типа, когда я могу выполнять НАСТОЯЩУЮ работу по написанию кода? TL; DR: Это не великая философия.
Эти типы задач являются основной частью работы разработчика. Я сказал себе, что изучу эти другие детали после того, как я полностью понял Rails, что кажется комичным в ретроспективе. Вы никогда не будете знать все, что нужно знать о конкретной структуре. Эти «лишние» задачи были бы чрезвычайно ценными, чтобы расставить приоритеты во время учебы в школе.
Из многих задач, связанных с программированием, я больше всего сожалею о том, что не трачу больше времени на изучение Git, прежде чем начать здесь. Итак, без лишних слов, вот несколько моих любимых команд Git.
Гит
В школе я научился достаточно, чтобы мерзавец (извините …). Я мог бы нажать и вытащить из репозитория на GitHub, проверить ветку и объединить ее с мастером. Проекты, как правило, были достаточно небольшими, чтобы вы могли координировать свои действия с партнером, чтобы не касаться одних и тех же частей кодовой базы. Конфликты слияний редко были большой проблемой, с несколькими запоминающимися исключениями.
Вот несколько вещей, которые я застеклил и которые стали очень ценными.
Шиповая ветвь
Это кажется незначительным в ретроспективе, но это было действительно полезно для ускорения моего рабочего процесса на начальном этапе. Ветвь с шипами — это ветка, которую вы создаете, над которой вы планируете экспериментировать и в конечном итоге удалять. При запуске потенциально грубого перебазирования в ветке my-cool-feature или, возможно, при желании вернуться к нескольким коммитам и попробовать другую реализацию, я мог бы разветвляться из этой ветки в дубликат let-try эта шиповая ветвь. Таким образом, если бы я что-то испортил, я мог бы вернуться к исходной ветке my-cool-feature . Это позволило мне пойти на больший риск при изучении, потому что я знал, что даже если я по-королевски испорчу код или историю Git, я могу удалить ветвь шипа и начать заново. Теперь, когда я лучше знаю инструменты (особенно git reflog … см. Ниже), я использую это реже, но это все же отличный инструмент для использования в наборе инструментов.
Загрузка...
