Программисты vs. ИИ 1:0
Чтобы ИИ полностью заменил программистов, нужно, чтобы клиенты в точности объясняли чего хотят.
Мы в безопасности.
Чтобы ИИ полностью заменил программистов, нужно, чтобы клиенты в точности объясняли чего хотят.
Мы в безопасности.
Всем привет.
Сегодня продолжим погружаться в системный анализ, в его техническую часть.
Перед тем как начать изучать REST, API и все что с этим связано - нужно изучить, хотя бы верхнеуровнево, архитектуру, на базе которой строятся все современные приложения. Для этого рассмотрим клиент-серверную архитектуру.
Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций.
В клиент-серверной архитектуре одним из основных вопросов является вопрос о том, как разделить клиентов и серверы. Так, приложения типа клиент-сервер разделяют на три уровня:
уровень представления - на уровне представления обеспечивается взаимодействие с пользователем приложения с помощью пользовательского интерфейса. Его основное предназначение состоит в отображении информации (все формочки, кнопочки и т.д.) и получении информации от пользователя. Этот уровень может работать в веб-браузере или как графический пользовательский интерфейс компьютерного или мобильного приложения.
уровень бизнес-логики - центральное звено приложения, на котором реализованы все основные функции системы. Обрабатывается вся информация, собранная на уровне представления согласно бизнес-правилам для выполнения конкретных бизнес-целей системы. Кроме того, уровень приложения может добавлять, изменять и удалять данные, расположенные на уровне данных;
уровень данных - функции управления ресурсами. На данный момент в современных приложениях его роль зачастую выполняет реляционная (или нереляционная) система управления базами данных.
Т.е. система реализована таким образом, что собирает всю ту информацию, которую пользователь ввел на интерфейсном уровне, затем передает ее на уровень бизнес-логики, каким-то образом обрабатывает с учетом всех бизнес-правил и затем либо возвращает обогащенную информацию обратно, либо сохраняет ее в базу.
Клиент-серверная архитектура делится на двухзвенную и трехзвенную.
Двухзвенная архитектура
Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером). Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т.е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса.
В двухзвенной клиент-серверной архитектуре используется так называемый «толстый» клиент, который выполняет отображение информации и обработку всех данных (порядка 80 % всех работ). Сервер осуществляет только хранение и предоставление данных (порядка 20 % работ).
Толстый клиент - это когда приложение напрямую запущено через условный .exe файл на вашем компьютере и работает в отдельном окне (всякие ERP\WMS системы, те же клиенты 1С и пр. не облачные штуки). Собственно их основной минус в том, что т.к. нет выделенного сервера - все функции реализуются на уровне клиента, который потребляет только те ресурсы, которые доступны компьютеру, на котором это приложение установлено.
А большинство офисных компьютеров, как известно, не отличаются большой производительностью, поэтому необходимость сформировать условный отчет даже из относительно небольшого количества данных заставляет их сильно задуматься. Это если не говорить о необходимость формировать или отображать какие-нибудь таблицы, состоящие из нескольких миллионов строк.
Трехзвенная архитектура
Собственно именно эти недостатки в большей степени послужили толчком к появлению трёхзвенной клиент-серверной архитектуры с отдельно выделенным сервером приложений.
Выглядит это всё схематично следующим образом:
Также в этой архитектуре мы уже можем позволить себе использовать "тонкий клиент", т.е. просто страницу в вашем веб-браузере или мобильное приложение. И с учетом этого, мы просто обязаны вынести из него всю логику (даже простейшую валидацию желательно перенести на уровень бизнес-логики, либо, как минимум, дублировать), потому что у него не остается почти никаких ресурсов для ее выполнения.
Всё, на что способен тонкий клиент - это отображать интерфейс, взаимодействовать с пользователем, посылать запросы на сервер по любому чиху и обрабатывать ответы от него. Ну и иногда, по мере какой-то острой необходимости, горящих сроков или чего-то в этом духе можно запихнуть в него какую-то логику, но стараемся этого избежать.
Но при этом мы получаем монструозный (в плане его мощностей) сервер, который способ обслуживать огромное количество клиентов одновременно, в многопоточном режиме обработки данных и выполнять необходимую бизнес-логику за какие-то доли секунд, даже при большом объем данных.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Утром едем с внуком на машине по неширокой улице типа «2 машины разъедутся, три уже с трудом». Останавливаюсь на перекрестке на левый поворот. Оставляю справа место для проезда прямо, смотрю в зеркало – вижу ассенизаторская машина подъезжает.
Лирическое отступление (если кого-то заинтересует, на смысл поста не влияет):
В городе действует система центрального водоотведения. Но в частных домах еще очень много выгребных ям и септиков, которые надо периодически откачивать с помощью ассенизаторских машин. Но они не централизованы, и когда необходимо, приходится их разыскивать, а в объявлениях дают номера сотовых телефонов, и «ни явок, ни паролей», никаких адресов. Звонишь, а там: мы в этом районе не работаем, а то и вовсе находятся в совершенно другом городе за сотни километров. И списать номер телефона с машины, работающей в твоем районе - большая удача.
На бочке крупно написан телефонный номер. Прошу внука сфотографировать номер на ассенизаторской машине. Открываю боковое окно. Моё внимание поглощено выполнением маневра. Внук фотографирует.
На следующем светофоре стоим на красный, прошу показать, что получилось. Внук, с гордостью, показывает фотографии: «смотри, как четко получилось!». И действительно, на всех фотографиях очень хорошо, четко виден номер – номерной знак автомобиля. А на мой вопрос: «это что?», внук вполне резонно удивился моему удивлению: «Ты сказал номер, я сфотографировал номер. Что не так-то?»
Пришлось объяснить, что я имел в виду. На что внук заметил, что о телефонном номере на цистерне он даже и не подумал.
Очередное подтверждение – хочешь получить хороший результат, правильно и полностью формулируй задание.
Telegram - Mem's_Bakery
Взять с собой побольше вкусняшек, запасное колесо и знак аварийной остановки. А что сделать еще — посмотрите в нашем чек-листе. Бонусом — маршруты для отдыха, которые можно проехать даже в плохую погоду.