Традиционно у вас есть несколько шагов для создания веб-приложений. Просто подумайте о Нетфликсе. У вас есть дизайнер, который делает дизайн приложения. Этот дизайн должен быть интегрирован дизайнером пользовательского интерфейса или разработчиком внешнего интерфейса. Интеграция дизайна означает, что вы превращаете красивый дизайн, который вы сделали, в код (или что-то, что может понять компьютер). На картинке ниже вы можете увидеть знаменитый дизайн Netflix.
Теперь следующий шаг. Когда вы наводите курсор на изображения, они должны начать двигаться, и вы сможете воспроизвести фильм. Здесь вступают в действие фронтенд и бэкэнд разработка. Фронтенд попросит бэкэнд загрузить основные данные о фильмах из базы данных, а фронтенд позаботится о том, чтобы была интерактивность (изображение «Друзья» начинает воспроизводить небольшой ролик, когда вы наводите курсор на Это).
При нажатии на изображение друзей открывается новое окно. В этот момент серверная часть Netflix запрашивает фильм в базе данных. Этот момент действительно важен, потому что вы не хотите слишком долго ждать, пока ваш фильм загрузится. Пока фильм загружается, фронтэнд уже покажет вам картинку с красным загрузчиком, чтобы уведомить вас о том, что идет ваш фильм.
Когда серверная часть готова, извлечение данных из базы данных. Интерфейс может воспроизводить фильм.
Теперь, конечно, реальность намного сложнее, особенно в случае с Netflix, но это общая идея.
Все интеграторы дизайна, разработчики интерфейса и разработчики бэкенда пишут свой код в кодовой базе. Эта кодовая база содержит весь код, написанный разработчиками и интеграторами для создания этого приложения. Вы можете сравнить эту кодовую базу с гигантским Google Диском с разными папками и Google Docs. Папки описывают различные части приложения, а документы Google содержат фактический код.
Как и в Google Docs, над одной и той же частью кода работают вместе разные люди. Когда разработчики что-то вносят в код (добавляют новые функции, исправляют ошибки), они должны убедиться, что:
- В коде, который они добавили, нет ошибок.
- Их код, который они добавили, не повредит существующему коду. Например, часто бывает так, что когда ошибка исправлена, из-за исправления возникает новая.
- Изменения в их коде не пересекаются с изменениями, внесенными другими разработчиками.
Именно здесь вступают в игру такие инструменты, как Github, Bitbucket и Gitlab. Используя эти платформы для разработки программного обеспечения, разработчики могут совместно работать над проектами, видеть, какие изменения были внесены в код, и принимать или отклонять эти изменения.
Поэтому, когда изменения приняты, остается сделать еще один шаг. Тот факт, что изменения были приняты в кодовой базе, не означает, что они автоматически отражаются на реальном веб-сайте. Вот тут-то и появляются DevOps, непрерывная интеграция и облако. В следующем посте блога вы узнаете, как они обеспечивают быстрое отражение работы разработчиков в реальном приложении.
Этот пост в блоге является частью миссии Texidi, направленной на то, чтобы сделать технологии понятными для нетехнических профилей. Ознакомьтесь с другими сообщениями в блогах, объясняющими технические термины простым и интересным способом.
Подпишитесь на нас в LinkedIn и Instagram, чтобы первыми узнавать последние новости о нашем новом подкасте Recs & Devs, наших сообщениях в блогах и многом другом!
Посетите наш веб-сайт, чтобы узнать больше о Texidi.
