Среды разработки: какие они бывают и чем отличаются друг от друга. Рассказывает Кирилл Мокевнин.

В любом производственном процессе, к которому относится и разработка программ, есть несколько этапов:

1. Производство
2. Сборка
3. Контроль и испытания
4. Доставка

Давайте рассмотрим каждый из них более подробно.

Производство

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

Место, где происходит этот процесс, называется средой разработки. Всегда есть как минимум две среды:

1. Среда разработки, ее часто называют development environment
2. Среда эксплуатации, обычно ее называют боевая среда или production.

В зависимости от среды код должен вести себя по-разному. Например:

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

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

Сборка

После того как вы реализовали свою задачу (фичу) и она была протестирована, ее код вливается в основную ветку. Возможно, параллельно с разработкой вашей фичи еще один разработчик программировал вторую в другой ветке. Теперь в основной ветке они встретились — это называется интеграция. А работают они вместе или нет — еще предстоит выяснить. Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде.

Контроль и испытания

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

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

Стейджинг — это такая среда, в которой происходит проверка перед боем. Она максимально приближает к условиям боевой среды, что дает возможность полнее протестировать то, что происходит. Обычно это то место, куда идут менеджеры, тестировщики, заказчики. Часто стейджинг выполняет сразу две задачи — проверку конкретных фич от разработчиков и окончательный прогон приложения перед релизом.

Тут появляется еще одно новое слово — релиз, или по-другому выпуск. С одной стороны, это процесс выкатки в бой новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.

Читайте продолжение в комментариях 👇

Давайте вспомним наших учителей по информатике. Какие они были? Повлияли ли они на ваш выбор профессии?

Мы в партнерстве с образовательной платформой Инфоурок проводим короткий опрос о том, какое влияние учителя информатики оказали на вас при выборе профессии после окончания школы. Будет здорово, если вы поучаствуете🔥

Опрос анонимный и займет не больше 3 минут: https://forms.gle/asntncCA5ckumj3L6

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

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

Все это стало возможным благодаря концепции открытых проектов. Компании и отдельные программисты выкладывают на GitHub исходный код, который можно использовать и в других местах. Это позволяет подключаться к разработке таких компонентов программистам из любых других компаний. Так все остаются в выигрыше — компании сосредотачиваются на своих бизнес-задачах, а код общего назначения поддерживается сообществом. Поэтому цена его создания и сопровождения значительно падает для всех участников.

Например, у Хекслета есть проект Code Basics, который специально выложен в открытый доступ. Это помогает тратить меньше времени на его сопровождение, так как наши студенты и другие люди участвуют в его доработке. Даже курсы, выложенные на этом сервисе, являются открытыми. Любой человек может пойти и поправить их. Или даже может написать целиком новый курс, что иногда случается.

Самое интересное в открытых проектах — это какую ценность они дают для разработчиков, которые их развивают. Дело в том, что открытые проекты — это невероятный опыт. Вот лишь некоторые плюсы:

- Командная работа. Нужно договариваться, обсуждать, предлагать решения, участвовать в код ревью;

- Открытые проекты используются большим числом людей. Вам придется учитывать множество вариантов использования и возникающие риски при изменениях. Это очень быстрый путь в сторону сеньорности;

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

- Бывает, что открытые проекты технически более сложные, чем проекты на работе. Там получается бесценный и новый опыт.

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

А представьте, как это звучит: «Я контрибьютор в React». И кстати, один из студентов Хекслета действительно стал контрибьютором React.