Кто следит за нами в Youtube, наверное, уже оценили материал по технической грамотности для молодых и горячих руководителей digital-проектов. Мы решили сделать из него полезную шпаргалку, собрав все в одном месте. Итак — первая часть основ техническй грамотности от нашего техдира Ивана. Мы затронем базовые вещи: как работает интернет, из чего состоит сайт, что такое фреймворки, немного про серверы и деплой. Поехали.

У каждого устройства в сети есть IP-адрес. Это уникальный номер, который выглядит как группа из четырех цифр, разделенных точками. Каждая цифра от 0 до 255, то есть четыре байта информации. Например — 127.0.0.1 (это ваш личный IP-адрес, для того, чтобы постучаться самому себе).

Когда вы вводите в браузер домен (например www.sibirix.ru), жмете enter, — запрос не сразу идет на какой-то сервер. Вначале ему надо сопоставить домен с местом, куда идти, то есть — с IP-адресом. Сначала запрос уйдёт на корневые DNS-сервера (система DNS — Domain Name Services — отвечает за то, что к каждому домену может быть составлен определенный IP-адрес. Хотя, там все несколько сложнее — одному доменному имени может соответствовать несколько IP-адресов (используется как один из приемов для отказоустойчивости и балансировки нагрузки), и наоборот, но суть в том, чтобы найти по доменному имени — IP-адрес.

Если домен находится в зоне .RU, то за него отвечает конкретная группа серверов, и дальше запрос идет к регистратору зоны .RU. Регистратор смотрит, кто купил этот домен, и какие NS-сервера отвечают за него. И только NS-сервера знают уже адрес вводимого сайта.

Когда отправляется запрос на конкретный адрес, на сервере начинает выполняться программный код. Например PHP-код, который пишут программисты (хотя на серверах можно писать на очень многих языках, и об этом чуть ниже). Но помимо кода на сервере хранится база данных: сайту ведь нужно откуда-то брать информацию, чтобы отобразить её на странице браузера (новости, статьи и пр.). Когда к серверу приходит запрос, он отвечает сгенерированным HTML — Hypertext Markup Language (язык разметки гипертекста). Фактически это структура документа — например, шапка с конкретным текстом, статьи с конкретным текстом, футер.

Браузер принимает этот HTML, анализирует его, скачивает скрипты, делает дополнительные запросы (если нужно), скачивает картинки, стили CSS и JS.

HTML — это только структура страницы, без какой-либо визуальной составляющей, CSS — уже стили (например, что шапка определенной высоты и синего цвета, футер внизу, статьи сделаны карточками и т. д.). JS — это поведение элементов на странице, то есть обработка реакций на действия пользователя (при наведении на карточку вывести её в расширенном виде, при клике добавить что-то в корзину и так далее).

Всё, что работает на стороне сервера (выполняемый PHP при обращении к базе данных) — это бэкенд. Всё, что выполняется в браузере (HTML, CSS) — фронтенд.

Это самая простая схема, но для понимания общих принципов — пока достаточно.

Язык программирования — это то, как пишется программа, и состоит он из двух частей. Первая — синтаксис: то, что пишет программист. Вы сейчас представили циферки, как в фильме «Матрица», но нет. Программист пишет не в машинных кодах — он пишет более-менее понятный человеку код (с условиями и последующими действиями).

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

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

Помимо синтаксиса и интерпретатора есть еще стандартные методы языка. У Python много функций для работы с какими-то математическими операциями, и его часто используют математики. В PHP таких возможностей для работы с математикой меньше, и его куда реже используют для работы с математическими функциями. Зато в нём намного проще работать с текстами и обрабатывать запросы, пришедшие от браузера.

Есть несколько языков, которые удобно использовать на стороне сервера, — это PHP, Python, серверный JavaScript (Node.JS), Asp.net. Помимо возможностей самого языка, отличается количество уже написанного на нем кода под специальную задачу. Например, на PHP написана куча фреймворков и CMS, на Python их считанные единицы, а на С++ фреймворков для работы с сайтами вообще нет.

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

Общение с сервером идет по протоколу HTTP (Hypertext Transfer Protocol) — протоколу для передачи гипертекста. Он по умолчанию не содержит состояний, а значит, не помнит, какие вы страницы запрашивали до этого. То есть, если вы три часа ходили по сайту и запрашиваете какую-то следующую страницу, для сервера это выглядит, будто кто-то пришел и просит страницу в первый раз.

Для авторизаций, запоминания и сохранённые корзины придуман специальный механизм — сессии (период времени, в который сервер «помнит» про вас, что это именно вы). Обычно он реализован через cookies. Когда к серверу приходит первый запрос от браузера пользователя, то помимо HTML, приходит уникальный идентификатор (строка из 32 символов вперемешку буквы-цифры). Этот код будет только у вас, и при каждом последующем запросе браузер добавляет эту cookie в любой запрос — так сервер может понять, что это вы, это ваша авторизация, это ваша корзина и так далее.

Но если не сделано какой-то дополнительной обработки, протокол по умолчанию не помнит, какие страницы вы посещали до этого. И это одна из причин, почему когда в техническом задании сказано «сделать на детальной странице товара ссылку, которая переходит „назад“ с восстановлением страницы каталога и настроек фильтра», программистам это очень сильно не нравится. Потому что по умолчанию механизмов для этого нет — и приходится изощряться.

С cookie также связано понятие «сессия» — по умолчанию это визит длиной 30 минут. Если страница за это время не обновляется и с ней не происходит никаких действий, то сессия считается завершенной. Хорошая новость: длину сессии можно изменить вручную в настройках сервера.

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

Поэтому в любой адекватной разработке используется либо какой-то фреймворк, либо какая-то CMS. В чём их отличия:


Фреймворки

Фреймворк — это все-таки штука, созданная программистами для программистов. С ним проще разрабатывать, но чаще всего в фреймворках нет админки, в которой было бы удобно заполнять контент. Но это не проблема — есть сторонние админки, вроде Voyager для фреймворка Laravel или целые генераторы админок.

Большая часть фреймворков — модульные (набор необходимых модулей, отвечающих за разный функционал, которые можно устанавливать отдельно по мере необходимости) и практически все — бесплатные (open source). Часто используемые фреймворки — Laravel, Symfony, YII, Zend Framework. Они решают одни и те же задачи, но у них разный порог входа: некоторые написаны проще, некоторые сложнее, но в целом — близкий. Разобравшись в любом из перечисленных выше фреймворков, программист, как минимум, сможет с ходу понять код, написанный для другого (не считая внутренней сложности проекта — логики работы).


CMS (системы управления сайтами)

Сделаны программистами для НЕпрограммистов (контент-менеджеров, продажников и так далее). Их отличает юзерфрендли (тут все относительно): внутри, как правило, есть админки и базовые бизнесовые штуки типа продаж, интернет-магазинов, скидок и так далее. Минус — кодить в них не так удобно, поскольку есть ряд ограничений, диктуемых CMS-системой. Наиболее используемые CMS, кроме Битрикса, — Joomla, Wordpress, Drupal, NetCat, ModX, Magenta.

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

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

Кодить с CMS — это как построенное здание, но уже с перегородками, витринами, складами, которыми можно пользоваться для типовой задачи. Но для НЕтиповой придется мучиться и сносить всё внутри под свою задачу. Иногда при этом есть риск обвалить все здание.

Его очень сильно распиарили, и теперь на него высокий спрос. У Битрикса относительно-удобная админка (хотя к ней есть вопросы), у него более-менее удобные возможности для кастомизации — есть места, где можно самому что-то «докодить». Это так называемый «бизнес-фреймворк» — всё-таки не полноценный фреймворк, но попытка сделать более-менее кастомизируемый инструмент. Из других плюсов: хорошая интеграция, следование российскому законодательству (поддержка онлайн-касс).

Но не всё так безоблачно. По мнению 95% программистов, в код Битрикса лучше лишний раз не лезть:

Причина раз
Битрикс пишет компоненты (готовые страницы, которые можно настраивать — например, каталог) и старается сделать их максимально настраиваемыми и универсальными. А когда есть узкая задача, большая часть написанного Битриксом кода не нужна и только путает программистов и мешает им решать её.

Причина два
Битрикс пытался сделать код более простым, чтобы контент-менеджер с минимальным курсом обучения за плечами мог туда залезть и что-то поправить. Но для сложных структурных изменений и нестандартных вещей это усложнило разработку. Другими словами, они пишут «самый широко-используемый код», в котором сложно разобраться и который сложно модифицировать.

Но плюсов у Битрикса всё-таки больше. Ещё один весомый довод в его пользу при выборе CMS для проекта — широкая распространенность в России. Изменение CMS на какую-то другую — это очень трудозатратный (и дорогой) процесс.

Именно по этой причине, когда есть шанс договориться о работе на фреймворке, или клиент говорит «а можно не на Битриксе?!», мы можем предложить фреймворк. Они построены по сравнительно схожим принципам (вот, например, наш проект на Laravel или на Symphony).

Как правило, таким грешат студенты, пишущие «за еду». Самописный сайт — это код, в котором в 9 случаях из 10 программист не следует ни одному из принципов программирования, а пишет код так, как ему захочется.

Плюс фреймворков — жесткие правила: как идет обработка страниц, как идет работа с базой данных, как построены какие-то бизнес-кейсы, какие цепочки действий там происходят. И если ты разобрался с условным Laravel, то ты в любом сайте на Laravel за 30 минут понимаешь, что там и как работает.

Но если взять самописный сайт, понимания ноль: неизвестно, как идет обработка запроса, как идет работа с базой данных, где искать конфигурации… Приходится читать код «от» и «до» и разбираться. И даже если код написан хорошо и следует каким-то правилам, тебе все равно придется погружаться в него полностью. Самописный — это ещё и значит, что нет поддержки сообщества, нет доработки модулей, нет закрытия каких-то уязвимостей при обновлениях. Поэтому это один из самых худших вариантов, который только может быть.

У Битрикса есть свой гайдлайн о том, как писать код и как правильно его обрабатывать. Также у Битрикса есть куча курсов — порог входа для кодеров низкий. PHP — тоже довольной простой язык, также с достаточно низким порогом входа. Как результат, не совсем грамотные люди часто называют себя «битрикс-разработчиками» и «пишут» код для Битрикса.

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

Из-за низкого порога входа в Битрикс и из-за гибкости PHP как языка есть очень большая вероятность, что код не следует гайдлайнам, и у него есть подводные камни. А значит, на поддержку такого кода будут очень большие издержки.

Соблазн написать проект на фреймворке высок. Тем более, что код на фреймворке получается более красивым — зачем использовать Битрикс, когда можно сделать с точки зрения программиста почти идеальный код? Вариант имеет место быть для сложных задач, которые на Битриксе сделать было бы дольше и дороже. Но иногда подход «фреймворк ван лав» оборачивается сложной поддержкой и ограничениями в дальнейшем.

Критерий выбора фреймворка — тот, с которым вы имеете больше опыта. По большому счету их мало что отличает: нет разницы в простоте кода, производительности или скорости разработки (последняя зависит только от скилла кодеров). Мы часто используем связку Битрикса и ZendFramework либо Laravel.

Фреймворки бывают не только на бэкенде, но и на фронтенде (и бывают вообще в куче других языков, не связанных с вебом). Среди них — React, Angular, Vue. JS, которые облегчают написание кода для взаимодействий с пользователем. При этом такие фреймворки не слишком SEO-френдли, и у сайтов на них, скорее всего, будут проблемы с продвижением. Вместо передачи браузеру всей структуры HTML серверная часть (бэкенд) таких сайтов отдаёт специально подготовленные данные в формате JSON, чтобы на их основе фронтэндный JS-фреймворк мог вывести страницу. Вот только ни Гугл, ни Яндекс такие данные не понимают. Но это можно обойти, если специальным образом подготавливать эти данные — рендерить их сразу не сервере.

Twitter Bootstrap — UI-библиотека, набор отдельных элементов, хотя в целом её тоже можно назвать фреймворком для CSS, поскольку она помогает в разработке интерфейса.

Бутстраповская 12-ти колоночная сетка, которая используется для вёрстки сайтов и которая могла быть у вас на слуху, — это часть Twitter Bootstrap. Также внутри фреймворка есть стандартные виды элементов, кнопочек и всего-всего. Часто бывает, что фреймворки — не монолитные и состоят из нескольких частей, которые можно использовать отдельно. Как, например, бутстраповскую сетку :)

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

Фактически, чтобы создать структуру базы данных, программисту нужно прочитать всё ТЗ, понять, что там есть, прикинуть, какие там есть связи, задать менеджеру проекта дополнительные вопросы и только потом нарисовать и создать таблицы (В Битриксе — инфоблоки). Да, что-то можно доработать и дописать потом, но если что-то не учли, это придётся как минимум частично переделывать.

Для многих сайтов надо периодически выполнять какие-то задания: например, выполнить обмен с 1С-кой, увеличить какой-нибудь счетчик на главной странице, собрать еще откуда-то данные. Крон — в помощь. Это специальная программа, запущенная на стороне сервера, которая выполняет периодические задачи. У неё есть специальный файл, где написаны скрипты для запуска и периодичность этих запусков.

Этот файл правится вручную — для каждой задачи внутри крона создается отдельная строчка. При выкладке сайта на реальный рабочий сервер каждую строчку крона нужно также вручную переносить. Если в новом спринте что-то доработали, и добавилась новая периодическая задача, надо не забывать «сходить» на сервер и руками добавить её. Это муторно.

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

Плюс агентов в том, что задачами не нужно управлять по отдельности, такую структуру проще деплоить, и перенос сайта с одного сервера на другой (если вдруг понадобится) сделать проще, и при переносе ничего не потеряется. Если файл задач крона вдруг окажется поврежден — одну запись восстановить проще, чем 15.

Если на кроне ничего не настроено (например, нет возможности редактировать крон — так иногда бывает на shared-хостингах), Битрикс всё равно будет выполнять периодические задачи — с ограничениями и слегка косячно, но будет. Возможны два варианта выполнения: 1) на стороне сервера (агенты через крон) и 2) во время запроса страницы, на хитах (hit), когда открывается страница и Битрикс выполняет какой-нибудь агент. Второй вариант принципиально хуже, т. к. существует ограничение на время создания страницы для клиента (зачастую не более одной минуты и это определенный объем памяти). Но кто же хочет ждать, пока отработает какой-то агент (который к тому же может быть не оптимально написан), если нужно просто обновить страничку, например, новости?

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

Для интеграции с 1С в Битриксе есть написанный модуль — его далеко не всегда хватает (когда нужны дополнительные поля, например), но чаще мы его используем. В любом случае нужно определенное время на настройку, хотя мы и берем более-менее готовый код. Интеграция же со сторонними сервисами (с API или чем-то подобным) почти всегда пишется с нуля.

Для интеграции по API программист должен взять описание этой системы, посмотреть, как она работает: сайт к ней должен отправлять запрос или она сама должна первой «стучаться» на сторону сайта. Также нужно посмотреть, в каком формате она общается (в каком формате данных и по какому протоколу), какие данные у неё нужно брать и как она их будет сообщать (и в какие таблицы внутри Битрикса их нужно сложить). Всё это должно быть в документации — если её нет, работать с API практически невозможно.

Когда всё изучено, начинаем писать код: подключись вот сюда, возьми данные → проверь, что они пришли и они корректны. Всё пишется вручную для каждой отдельной интеграции по API. Но тут оговорочка: для API может быть боевой и тестовый режим (доступы, серверы) — это необходимо, чтобы вести разработку и тестирование, не влияя на боевой сайт/боевые данные. Не всегда обязательно, но часто зависит от сложности самого API. Необходимо строгое соответствие протоколов общения, то есть описания, на какой адрес обратиться, какой послать запрос, какие будут получены данные и т. д., чтобы программист мог приступить непосредственно к разработке, т. к. в противном случае придется согласовывать их в процессе, что никому не нравится. Разумеется, изменения могут присутствовать, но если они происходят день через день — ну, время-деньги :) Аналогично, если внезапно тестовый API не соответствует описанию (либо боевой отличается от тестового, и это не описано.)

Есть несколько стандартных протоколов (форматов данных — например, XML или JSON), но внутри них данные могут быть представлены как угодно. Поэтому нельзя написать что-то работающее с одного API, чтобы тот же код без каких-либо правок заработал на другом API: там и другие методы, и другие данные, и другая структура. Но при этом работу какого-то конкретного API с одного проекта можно перенести на другой.

Если мы интегрируемся с какими-то сторонними сервисами, то обычно делаем ТЗ на интеграцию — описание методов и какие именно из них мы будем использовать, как они соотносятся с сущностями сайта. Без этого описания непонятно, как писать код, и можно очень сильно «влететь».

Для типовых сервисов (типа доставок) в магазине Битрикса есть готовые модули интеграции, которые уже знают, куда «стучаться» и какие данные передавать, можно настроить их. Фактически модуль — это готовый кусочек кода для работы с чем-то.

Когда у сайта нет API, но с ним надо интегрироваться, приходится парсить данные сайта — загружать страницы сайта, изображая из себя браузер, брать с них какие-то нужные кусочки и складывать их в базу данных. Но это — уже совсем другая история :)

Крутые видео для ПМ-ов и не только, как всегда, на канале, а вторая часть технического ликбеза — уже скоро :)

А если хотите больше информации — вы найдете ее в книге Владимира Завертайлова «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий». Книга доступна на сайте издательской группы ЭКСМО.