Установка рабочей станции разработчика с нуля

Фото Люка Питерса на Unsplash

Представьте себе этот сценарий:

После изнурительного собеседования, увольнения с предыдущей должности и небольшого отпуска вы начинаете работать в новой компании. Это супер интересно! Знакомство с новой командой, новой продуктовой линейкой, различными функциями внутри компании, онбординг-сессиями...

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

За многие годы работы в индустрии программного обеспечения я много раз выполнял эти установки — при переезде в другое место или в той же компании, заменяющей мою предыдущую машину (не спрашивайте меня об этом 😱). Это громоздкая и длительная задача. Чтение руководств и переживание мертвого времени во время самих установок всегда кажется пустой тратой времени.

Чего мы хотим добиться?

Я твердо верю, что разработчики должны взять на себя первое обязательство по совершенствованию в первый день работы. Это способствует быстрому ощущению выполненного долга, которое снимает напряжение и стресс, связанные с началом работы на новой должности, и дает уверенность в остальной части адаптации. Крайне важно пройти стадию начальной загрузки рабочей станции как можно быстрее, чтобы разработчик мог получить код, немного ознакомиться с ним и приступить к его освоению в тот же день.

С другой стороны, разработчики хотят знать, что установлено на их машинах. Знание приложения — это не просто знание кода, но и понимание экосистемы, среды выполнения, зависимостей и конфигураций. Начальная загрузка рабочей станции позволяет разработчикам делать это. Быстрое продвижение по процессу установки может оказаться контрпродуктивным для достижения такой цели и может увеличить кривую обучения.

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

Подводя итог, у нас есть три цели:

1. Быстрая установка

2. Сокращение кривой обучения экосистемы

3. Техническое обслуживание с течением времени

За прошедшие годы я видел много попыток решить проблему установки рабочей станции разработчика. От руководств до сценариев установки до ИТ-инструментов. К сожалению, ни один из этих инструментов не имел правильного баланса для достижения упомянутых целей.

Например:

• Обращение к ИТ-специалистам с проблемой обычно приводит к установке в виде черного ящика, который не позволяет им понять, какие инструменты установлены. Кроме того, его сложно поддерживать с течением времени, поскольку его обновляют не разработчики, а ИТ-персонал. Такой виртуальный барьер может препятствовать обновлению инструмента установки, что со временем устаревает.

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

Предложенное решение

Я хотел бы представить сценарий установки рабочей станции:

https://github.com/ysa23/workstation

Это простой bash-скрипт, который автоматизирует развертывание рабочей станции разработчика (или любой другой) — с нуля до героя 💪 менее чем за час!

Быстрая установка

устанавливает и настраивает все, что нужно разработчику для запуска приложения. Это автоматически занимает около часа, в зависимости от количества установленных приложений.

Кривая обучения

сам сценарий открыт для всех и очень прост. Это позволяет всем желающим легко просматривать все установленные приложения и понимать все применяемые автоматические конфигурации. Настоятельно рекомендуется сделать это до или даже во время запуска скрипта. Его также можно использовать в качестве справочного материала, когда необходимо понять некоторые конфигурации.

Обслуживание

Поскольку это сценарий с контролируемым исходным кодом и доступный для всех в команде, любой может внести изменения и предложить запрос на извлечение. Кроме того, если кто-то хочет выполнить определенную конфигурацию, он может легко либо разветвить ее, либо создать ветку и добавить свою настройку. Например, их любимая тема zsh или конфигурация ярлыков, которые они предпочитают командам git.

:::Информация

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

Моя рекомендация и то, как я применяла ее до сих пор в компаниях, с которыми я работал, заключается в том, чтобы разветвить и внести коррективы, которые подходят команде, с соответствующими инструментами и соответствующими конфигурациями.

Сам сценарий предназначен для компьютеров Mac, но, как говорят, его можно использовать в качестве источника вдохновения для аналогичных машин для разработки под Windows и Linux.

Репозиторий имеет открытый исходный код с лицензией MIT, и мы принимаем PR и проблемы с распростертыми объятиями 😉

Надеюсь, вы найдете в ней хорошее вдохновение и сделаете ее полезной для себя.

Первоначально опубликовано [здесь] (https://blog.house-of-code.com/installing-a-developer-workstation/)