Программистам нравится то удовольствие, которое они получают от разработки исходного кода, и способ превратить его в реальную ценность, затрагивающую потребности людей.
Способ программирования кода со временем эволюционировал от ассемблера, языков программирования высокого уровня, объектно-ориентированного, шаблонов проектирования, гибкой разработки, а затем машинного обучения. Одни и те же основные компоненты используются на каждой фазе эволюции, но с разными подходами и методами.
Мы находимся на пороге новой эры разработки программного обеспечения с появлением машинного обучения и острой необходимостью автоматизации человеческого труда.
давайте будем более реалистичными, мы ищем машины, которые могут сэкономить время, силы и дать нам силу господства. Это потрясающе, когда мы думаем о мире людей, обслуживаемых неэлегантными машинами, которые могут усердно работать 24x7 в сельском хозяйстве, производстве, транспорте, здравоохранении и т. д.
Мы создатели этого интеллектуального мира (используя код в качестве основной единицы разработки), поэтому нам нужно знать движущие силы этой революции:
- Переносимость — создайте переносимый блок кода (систему, модуль, пакеты или даже фрагмент кода). Это максимизирует возможность повторного использования кода, чтобы его можно было переносить из одной среды в другую с минимально возможной конфигурацией. Основная идея портативности заключается в создании портативных строительных блоков. GitOps и Linux CMake — яркий пример переносимости кода, а пакеты и контейнеры — пример переносимости бинарных файлов.
- Автоматизация — более высокий уровень программирования, снижающий вмешательство человека в программные процессы. Инструменты с низким кодом являются примером автоматизации процесса разработки программного обеспечения. Но следует учитывать, что исходный код по-прежнему является основной единицей в процессе автоматизации, который к тому времени компилируется в двоичный компонент, который используется «на лету».
- Искусственный интеллект — основной игрок и нынешний переломный момент в качестве следующего высокоуровневого метода системного программирования. Традиционный алгоритм кода программирования заменяется неэлегантным алгоритмом, который зависит от данных и математики. для получения более подробной информации, пожалуйста, ознакомьтесь с этой статьей Пейзаж машинного обучения
Эхо-система между ИИ, мобильностью и автоматизацией играет большую роль в развитии каждого из них. Все зависят друг от друга, и все влияют друг на друга.
Исходный код останется основной единицей разработки программного обеспечения независимо от технологии или методологии программирования (традиционной или ML). Это означает, что нам все еще нужно позаботиться о структуре кода и принять новые принципы разработки, которые больше соответствуют изменениям и прогрессу в информационных технологиях. Например, принятие принципов облачных сервисов во время кодирования заставит нас сосредоточиться на бизнес-требованиях (во время разработки) и перенести реализацию небизнес-требований на среду (платформу хостинга) и общие сервисы, такие как конфигурация, кэширование, сервис. обнаружение, обмен сообщениями, потоковая передача данных и т. д. Это делает код простым и переносимым.
Термин «программная служба» используется здесь для обозначения «бизнес-службы» на стороне сервера, размещенной в облаке или локально.
Анатомия программного обеспечения
Проще говоря, любая программная система состоит из трех основных частей:
- Пользовательский интерфейс (GUI, консоль и т. д.)
2. Бизнес-логика — реализация вариантов использования и объектов бизнес-домена, чтобы их можно было представить более чем одним компонентом.
3. Данные — хранилища данных, такие как база данных, память или файлы на диске.
В то время как другие части программного обеспечения должны поддерживать некоммерческие функции, такие как:
- Библиотеки — многоразовый системный компонент, предоставляющий сквозные функции (ведение журнала, обработка ошибок, кэширование и безопасность) или повторно используемые технические функции (повторно используемый код или пакеты).
- Интеграция — шлюзы, используемые системой для взаимодействия с другими системами посредством входящей интеграции или внешней интеграции. И это то, что отражено в архитектуре с coms matrix. Эта часть (или компонент) инкапсулирует необходимую логику, необходимую компоненту приложения, как мы увидим в модели DDD.
Интеграция и библиотеки представляют собой инфраструктуру программного приложения.
Структура кода важна для управления разработкой приложений с течением времени, чтобы соответствовать бизнес-изменениям. Таким образом, шаблоны проектирования используются для обеспечения унифицированного шаблона работы и стандартных повторно используемых решений для повторяющихся проблем. Одним из известных шаблонов проектирования, используемых при разработке корпоративных приложений, является проектирование, управляемое предметной областью (DDD), которое фокусируется на основном предметном бизнесе как центральной части системы. Идея DDD заключалась в том, чтобы сократить разрыв между бизнесом и техникой, работая вместе, используя общий язык, также известный как вездесущий язык. Это произошло одновременно с появлением гибкой разработки и появлением новых принципов создания независимых слоев системы, известных как инверсия управления (IoC). Итак, инженеры-программисты разработали различные шаблоны проектирования, которые применяют DDD и IoC с общей концепцией, но с разными вариантами, такими как чистая архитектура, гексагональная архитектура, луковая архитектура и т. д.
На самом деле DDD — это естественная концепция, поэтому она широко используется с различными архитектурными шаблонами, такими как монолитная архитектура, модульная монолитная архитектура, микросервисная архитектура и продуманная сервисная архитектура.
Термин мудрый сервис используется для обозначения системы с бизнес-границами, которые отражают реальный бизнес-кейс и избегают предвзятости к стилю технической архитектуры (например, монолит или микросервис).
Я использую упрощенную модель DDD со следующими концепциями для применения переносимости кода (или мобильности):
- Простая структура системы за счет максимально возможного уменьшения количества слоев/компонентов. Например, у нас может быть структура кода как Entities в ядре, Application, Northbound для общедоступной интеграции и Southbound для внутренней интеграции.
- Сосредоточьтесь на бизнес-требованиях. Таким образом, для некоммерческих требований полагайтесь на технологическую структуру и среду хостинга, насколько это возможно. Например, используйте возможности платформы для междисциплинарных функций (кэширование, ведение журнала, обработка ошибок и т. д.) и используйте возможности среды для межсервисных функций (конфигурация, обнаружение служб, работа в сети и т. д.). Просто следуйте облачным принципам.
- IoC — секрет переносимости компонентов. Таким образом, абстрагируйте связь между уровнями, используя классы интерфейса, и позвольте среде выполнения решить, какой конкретный компонент будет использоваться во время выполнения, используя конфигурацию системы.
Это расширяет возможности создания системы с портативными компонентами, чтобы их можно было заменять без прерывания работы и с минимальными затратами. Кроме того, это поддерживает нашу цель иметь высокий уровень автоматизации и искусственного интеллекта.
Кто первый, приложение или данные?
На самом деле, это две стороны одной медали. первая сторона отражает экономическое обоснование, а вторая сторона отражает данные, лежащие в основе экономического обоснования.
Существует взаимная индукция между приложением и данными. Таким образом, начиная с приложения или данных не имеет значения. Используйте приложение для проверки модели данных и используйте модель данных для проверки логики приложения.
Многоразовые детали в системе
На скорость разработки напрямую влияет количество строк кода, которые необходимо написать и протестировать. Высокая скорость означает скорость предоставления новой бизнес-функции или изменения существующей функции. Это означает, что повторно используемый код увеличивает скорость и качество разработки новых бизнес-функций.
На следующей диаграмме показан примерный процент повторно используемого кода. Идея состоит в том, чтобы дать намек на многоразовые детали с высоким потенциалом, которые необходимо учитывать на этапах проектирования и разработки.
Компоненты интеграции и библиотеки имеют самый высокий процент повторного использования. Компонент приложения имеет самый низкий процент, так как это наиболее индивидуализированная часть системы. В то время как компонент основной бизнес имеет высокий процент с точки зрения возможности его повторного использования из одного приложения в другое, например веб-, мобильные и другие типы приложений.
переносимый код — это повторно используемый код из одной системы в другую.
Портативная система — это система, которую можно переносить из одной среды в другую без необходимости специальной настройки (не зависящей от среды), как в контейнерных приложениях.
Системный ландшафт
Давайте взглянем с точки зрения верхнего уровня, чтобы получить общее представление о цели этой статьи и о том, как использовать мобильность, автоматизацию и искусственный интеллект для создания быстрых и интеллектуальных систем.
Система может быть развернута в среде хостинга с использованием различных подходов, которые необходимо определить во время разработки. У нас может быть одна система с одним уровнем, развернутая на одном гигантском сервере. Или у нас может быть масштабируемая и распределенная система со специализированными службами (каждая из которых имеет определенную роль).
Идея здесь в том, чтобы создать стандартную, адаптируемую и изменчивую систему, независимо от ее топологии. Но давайте воспользуемся передовой практикой, приняв облачные системы, которые поддерживают наше стремление к быстрой и умной системе.
Хороший дизайн должен быть как семя, начинать с простого и постепенно расти.
Среда хостинга такая же, как почва для растения, поэтому система может расти и поддерживать свою жизнь, используя ресурсы среды.
Бизнес-ориентированная система
Как и в DDD, бизнес является центральной частью, поэтому бизнес-система/сервис по-прежнему является центральной системой в среде хостинга. Это означает, что понимание среды хостинга — особенно облачных сред — и использование зрелой среды разработки помогает нам создавать гибкие системы, которые заботятся о бизнесе. Облачная среда предоставляет готовые службы, которые могут использоваться основной системой, такие как настройка и обнаружение служб, а также она предназначена для размещения одноразовых служб (например, служб интеграции), доступ к которым можно получить через стандартные интерфейсы (например, HTTP REST). . Подробнее об облачных сервисах https://www.cncf.io
Хороший дизайн должен быть компонуемым и декомпозируемым, чтобы его можно было составить из независимых частей, которые можно разложить и заменить при необходимости.
Приведенная выше диаграмма является примером того, как мы можем думать о создании бизнес-ориентированной среды. Идея состоит в том, чтобы подчеркнуть роль среды хостинга и ее общих служб в построении защищенной бизнес-ориентированной системы.
Основными характеристиками архитектуры среды хостинга являются:
- Платформа — представляет общие службы между всеми системами (размещенными в среде). Он играет жизненно важную роль в автоматизации процесса инициализации в рамках непрерывной доставки системы, а также обеспечивает эксплуатацию и мониторинг работающих систем. Таким образом, это основа автоматизации и мобильности.
- Edge — представляет собой публичный шлюз к системам. Он играет важную роль в качестве первой линии защиты, контролирует трафик к основным бизнес-сервисам и несет нагрузку, не связанную с бизнесом (например, общедоступный контент и интеграцию с общедоступной службой).
- Интеграция — представляют собой общие сервисы, используемые для внутренней и внешней связи. Интеграция дает более широкую область для бизнес-систем, чтобы они зависели от других систем или предоставляли свои услуги другим системам.
- сквозные фреймворки и библиотеки — общие библиотеки, используемые во время разработки для создания различных систем.
- Бизнес-система — динамичная и центральная точка всего этого.
Платформа, интеграция и фреймворки играют жизненно важную роль в обеспечении высокого уровня автоматизации процессов.
Как подать заявку?
(1) Портативность
Насколько хорошо используется возможность повторного использования, настолько же повышается уровень переносимости кода/компонента.
И, поскольку мы стремимся построить бизнес-ориентированную систему. мы должны учитывать повторно используемые компоненты сквозного доступа, интеграции и периферии. Кроме того, бизнес-сервис многократного использования при нацеливании на разные приложения.
Любая требуемая конфигурация (например, настройки) должна быть независимой от переносимого компонента и вводиться во время выполнения с использованием различных методов (например, с помощью веб-службы настройки или любых других методов, подходящих для окончательного решения).
Портативность — это возможность повторного использования в действии
(2) Автоматизация
Это не будет сделано без хороших инструментов и хорошей платформы. Он должен состоять из независимых многократно используемых компонентов для составления автоматизированного бизнес-(или технического) процесса.
Автоматизация — это своего рода программирование, что означает, что она может развиваться с помощью методов машинного обучения ИИ. Это выделено на приведенной выше диаграмме «Пейзаж программных служб-›Интеграция Env-›Адаптивный ИИ» или любых других методов ИИ, нацеленных на интеграцию автоматизации.
(3) AI
Это будет частью каждой программной системы, встраивая модель ML внутрь системы. Принимая во внимание, что реализация ИИ не ограничивается конкретной системной функцией (периферия, бизнес или интеграция).
На следующей диаграмме показано, как машинное обучение станет аспектом программной системы, который изменит будущее разработки программных систем.
Перейдите по этой ссылке (Ландшафт машинного обучения), чтобы получить руководство по началу работы по использованию машинного обучения в разработке систем.
Внешний интерфейс
Внешний интерфейс (или клиентские каналы) — это клиентские приложения, которые взаимодействуют с бизнес-системой либо через службу презентаций, либо через API. Это не показано на диаграммах, поскольку та же идея может быть реализована при проектировании/создании интерфейсных приложений с учетом трех основных факторов: переносимости, автоматизации и искусственного интеллекта.
Фронтенд-приложения, такие как мобильное приложение, могут поддерживаться встроенной моделью машинного обучения или могут использоваться удаленно через API.
Пример в действии
На следующих диаграммах показан пример использования школьной системы. Идея состоит в том, чтобы показать основные компоненты/слои в системе и их взаимодействие с внешними системами.
Идентификация основных компонентов в системе и их матрицы связи позволяет нам определить объем работ по разработке и возможности повторного использования, автоматизации и машинного обучения.
Увеличьте «Env 1»
Заключение
Чтобы разработать стратегию перехода к интеллектуальным и гибким системам, необходимо подготовить портативные строительные блоки, зрелый процесс автоматизации и четкое видение машинного обучения.
Разрабатывайте строительные блоки с учетом возможности повторного использования, используя простые методы абстракций и внедрения зависимостей. Сделайте конструкцию системы простой, чтобы она состояла из подключаемых компонентов, которые можно заменять по мере необходимости без прерывания работы.
Машинное обучение становится аспектом современных программных систем, поэтому сейчас самое время начать создавать свои модели машинного обучения для различных систем, которые у вас есть.
Продолжение следует, как измерить?
Рекомендации
- Пейзаж машинного обучения
- Драйверы современной разработки программного обеспечения
- Дизайн, управляемый доменом (martinfowler.com)
- Инверсия управления — Википедия
- Демистификация шаблонов архитектуры программного обеспечения | Мысли
- Фонд облачных вычислений (https://www.cncf.io)
- Приложение Двенадцати Факторов