Как измерить безопасность шифрования? В литрах кипятка!

Как измерить безопасность шифрования? В литрах кипятка!

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

Подобные оценки впервые прозвучали на конференции Crypto 2010, когда было показано, что для факторизации 768-битного RSA понадобилось бы энергии, достаточной, чтобы нагреть и довести до кипения два олимпийских бассейна. Это около полумиллиона киловатт-часов.

Из этих идей родилась терминология: 65 бит симметричного шифрования дают «защиту бассейна», а 114 бит — «глобальную защиту», то есть взлом эквивалентен кипячению всей воды Земли (1,4 млрд км³). Для сравнения: годовое производство энергии во всём мире (примерно 30 000 ТВт·ч) хватило бы только на взлом 91-битного шифрования или на кипячение Женевского озера.

Формула, связывающая длину ключа n с объёмом воды, выглядит так: число литров воды, которое можно вскипятить с энергией, необходимой для перебора, равно 6,777 × 10⁻¹⁴ × 2ⁿ.

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

Определение простого числа с помощью регулярного выражения

Финт здесь в том, что число представляется в виде одинаковых символов длиной, равной самому числу. Далее проверяется, если ли какое число, которое точненько укладывается в строку

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

Код.

JAVA

public static boolean isPrime(int n) {
     return !new String(new char[n]).matches(".?|(..+?)\\1+");
}

Python

def is_prime(n):
   return not re.match(r'^.?$|^(..+?)\1+$', '1'*n)

JavaScript ECMA6

function isPrime(n) {
    var re = /^.?$|^(..+?)\1+$/;
    return !re.test('1'.repeat(n));
}

JavaScript

function isPrime(n) {
   var re = /^.?$|^(..+?)\1+$/;
   return !re.test(Array(n+1).join('1'));
}

Perl

sub is_prime {
   return !((1x$_[0]) =~ /^.?$|^(..+?)\1+$/);
}

C#

public static bool IsPrime(int n) {
   return !Regex.IsMatch(new string('1', n), "^.?$|^(..+?)\\1+$");
}

Источник

https://illya.sh/the-codeumentary-blog/regular-expression-check-if-number-is-prime/

7 вариантов BI-платформы

Из заметки "На замену SAP: какую отечественную BI- платформу выбрать — 7 вариантов". IT-Expert, March 15, 2024

№ 7. Polymatica

В целом Polymatica использует простой и понятный интерфейс, требуя минимума знаний для базовой работы с платформой. На начало 2024 года BI от Polymatica внедряют более 60 системных интеграторов. Собственное хранилище может быть реализовано на базе ClickHouse или PostgreSQL, а коннекторы уже разработаны для большинства популярных СУБД и корпоративных платформ.

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

№ 6. Modus BI

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

Отсутствие возможности глубоко кастомизировать визуальные представления. Фактически пользователь ограничен настройкой стилей.

№ 5. Luxms BI

Разработчики платформы активно вкладываются во внедрение технологий AI/ML для глубокой аналитики данных, а также занимаются развитием собственного метаязыка LPE (аналог DAX). В Luxms реализована поддержка файлов Qlik (QVD), разработаны коннекторы к SAP. В отличие от многих других решений, Luxms одновременно предлагает как Self-Service- элементы для сборки простых дашбордов, так и возможности дополнительной разработки и глубокой кастомизации платформы под нужды конкретных пользователей с опорой на практики CI/CD. В составе платформы есть свой достаточно развитый ETL-инструмент Luxms Data Boring. У Luxms BI открытая архитектура. Она позволяет кластеризовать и масштабировать решение. 

Специалисты отмечают недостаточно проработанную документацию по платформе в целом, а также сложности в настройке представлений, аналитических элементов и кастомизации витрин данных.

№ 4. Insight BI

Конструктор для разработки, встроенные библиотеки шаблонов и маркетплейс готовых решений, собранных на портале разработчика Insight Visual Studio. Также в составе платформы имеется Insight Data Platform, обеспечивающая подключение к различным СУБД и информационным системам, сбор и обработку данных.

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

№ 3. Analytic Workspace

Разработчик - ОСТ - делает ставку на точечное решение задачи BI. В последнее время проекты AW отличаются встраиванием в готовые экосистемы, и это разумный подход для тех организаций, перед которыми стоит задача замены ставшего недоступным западного ПО. B AW BI имеется свой блок ETL, построенный с использованием Аpache Spark и Аpache Airflow. Он реализует базовые операции преобразования и объединения данных. Для продвинутых преобразований доступны SQL и Python.

Система визуализации в AW простая и интуитивная, но только пока вам не нужно получить какую-то особенную кастомизацию.

№ 2. Аналитическая платформа «Форсайт»

Платформа «Форсайт» подкупает большим арсеналом решений, который позволяет эффективно решать сложные задачи. Так, в портфеле вендора имеется как «тяжелая артиллерия» в виде BI- системы «Форсайт. Аналитическая платформа» (ФАП), так и облегченная FLY BI для более простых задач. Вместе с ФАП заказчики получают инструментарий классической и продвинутой аналитики, а также средства управления бизнес- процессами (ВРМ), которые позволяют не только заниматься аналитикой, но и разрабатывать бизнес-приложения. Платформа уже содержит все инструменты для сбора, обработки, мониторинга и анализа данных. Имеются инструменты предиктивной аналитики, а также встроенные системы ИИ, работы с большими данными и построения прогнозных и оптимизационных моделей. Экосистему дополняют продукты «Форсайт. Управление инвестициями», «Форсайт. Бюджетирование», «Форсайт. Сводная отчетность», «Форсайт. Кредитный конвейер», «Форсайт. Мобильная платформа».

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

№ 1. Аналитическая платформа Visiology

Предусмотрено использование нового аналитического движка ViQube 2, у которого «под капотом» лежит СУБД ClickHouse с автоматической оптимизацией схемы размещения данных и методов обработки запросов. Это позволяет избежать создания дополнительного аналитического хранилища и показывает высокую производительность. Достаточно простой собственный ETL-инструмент ViXtract, который является OpenSource-проектом. Открытый интерфейс позволяет использовать для больших проектов промышленный ETL, такой как Apache Airflow, или коммерческий инструмент, например Loginom. Модуль Smart Forms, способный автоматизировать ручной ввод при помощи веб-форм, а также загружать готовые документы Excel, моментально перенося их на ВI-платформу с отражением на реальных дашбордах. Поддержка DAX в том же виде, как он работает в Microsoft Power BI, возможность визуального конструирования модели данных, виртуального помощника ViTalkGPT с искусственным интеллектом и наличие средств интеграции дашбордов в порталы и приложения.

Источник.

https://telegra.ph/Na-zamenu-SAP-kakuyu-otechestvennuyu-BI--platformu-vybrat---7-variantov-03-15

* * *

Вертикально-интегрированная горно-металлургическая компания "Северсталь" строит платформу для хранения и анализа данных, основанную на стеке продуктов группы Arenadata.

Совместное решение станет полноценной заменой хранилища данных на базе SAP BW с процессами моделирования объектов, переноса объектов между системами, ведением ETL процессов, работой с данными.

Для решения задачи был выбран стек продуктов Arenadata: СУБД Arenadata DB, Arenadata QuickMarts для хранения и обработки данных на разных уровнях хранилища; система Arenadata Streaming для потоковой обработки данных в режиме реального времени; Arenadata Catalog для управления информационными активами компании и ведения корпоративного бизнес-глоссария в едином интерфейсе.

В перспективе альтернативное хранилище данных станет единым источником правды для нескольких компаний "Севергрупп", агрегирующим в себе потоки данных по 15 функциональным областям, включая производство, финансы, контроллинг, казначейство, инвестиции, закупки.

https://www.comnews.ru/digital-economy/content/234283/2024-07-11/2024-w28/1012/severstal-stroit-khranilische-dannykh-steke-produktov-arenadata

СУБД российского производства

В силу ряд условий и обстоятельств в 2024 можно уже говорить о СУБД российского производста, получившей название Tantor.

Как заявляется вендором, Tantor - удобная в использовании СУБД российского производства с повышенной производительностью и встроенной системой администрирования и мониторинга

Заявляются следующие качества этой СУБД.

Экономия человеческих и аппаратных ресурсов

• Улучшения в ядре СУБД повышают производительность и адаптируют продукт для высоконагруженных систем
• Реализован функционал для обеспечения совместимости при миграции с СУБД Oracle
• СУБД оптимально подходит для решения задач в части построения DWH и IoT благодаря улучшенным методам хранения и обработки данных

Экономия времени

• Непрерывность бизнес-процессов благодаря улучшениям в механизмах мониторинга, а также профилирования SQL-запросов
• Есть возможность использовать готовые решения от вендора для создания отказоустойчивых кластеров и организации инкрементального резервного копирования

Экономия денег

• Позволяет существенно экономить на эксплуатации благодаря экосистеме встроенных enterprise и OpenSource-инструментов
• Имеет адаптированные версии для облачной инфраструктуры, позволяющие гибко управлять ресурсами

Безопасность

• Гарантированы оперативное исправление найденных уязвимостей (CVE) и выпуск патчей в течение 96 часов
• Разработчики могут работать с обезличенными данными благодаря анонимизации логического дампа схемы и данных БД
• Обеспечена интеграция с ОС Astra Linux для повышения уровня защиты от несанкционированного доступа к данным

Функциональные возможности

Высокая производительность

• Оптимизация
• Поколоночное хранение данных
• Partition lock —для повышения производительности транзакций
• Стандартный алгоритм сжатия pglz
• Каскадная репликация
• 64-битный счетчик транзакций
• Увеличение скорости передачи данных между клиентом и сервером за счет сжатия
• Возможность конфигурации SLRU-буфера для оптимизации высоконагруженных систем
• Специальные патчи для оптимизации работы с «1С» и обеспечения совместимости с Oracle
• Планировщик заданий
• Подсказки (hint) для оптимизации планов запросов
• Использование пула соединений
• Автоматизация создания партиций

Снижение рисков простоя и потери данных за счет платформы мониторинга и администрирования

• Мониторинг ключевых метрик как в графическом интерфейсе, так и с помощью оповещений, интегрированный со службами сообщений (Telegram, Email и API)
• Визуальный профайлер SQL-запросов, позволяющий быстро выявлять проблемные места
• Сбор и хранение статистики планов выполнения запросов для дальнейшего проведения расследований
• Статистика работы и средства диагностики запросов для оптимизации приложений, работающих с базой данных
• Представление частоты выполнения планов в виде гистограммы
• Визуализация планов со статистикой выполнения каждого из них
• Анализ схемы данных, статистика использования объектов БД
• Управление конфигурациями СУБД из пользовательского интерфейса
• Наличие встроенного механизма расчета оптимальной конфигурации СУБД
• Визуализация сессий и блокировок с возможностью остановки выполнения запросов
• Логирование всех пользовательских действий с возможностью просмотра истории
• Отображение статуса и состояния репликации
• Предоставление информации о табличных пространствах
• Выполнение задач обслуживания через графический интерфейс
• Ролевой доступ к графическому интерфейсу для разграничения прав (RBAC)
• Интеграция с LDAP
• API для выгрузки данных во внешние системы

Упрощение ведения разработки

• Расширенные возможности секционирования больших таблиц
• Функции для вызова по протоколу HTTP без остановки выполнения запроса
• Создание переменных в пользовательских сессиях (особенно полезно при миграции с Oracle)
• Возможность создания гипотетических индексов
• Прогнозирование необходимости использования индексов на основании исторических запросов

Надежность и отказоустойчивость

• Встроенный инструмент для резервного копирования
• Поддержка системы резервного копирования RuBackup
• Возможность работы в режиме отказоустойчивого кластера
• Восстановление битых блоков с реплики на мастер

Расширенные возможности для соблюдения требований в части безопасности

• Поддержка защищенного подключения к СУБД
• Защита страниц с данными контрольными суммами
• Расширенный аудит всех операций в БД
• Расширенный контроль за пользовательскими учетными записями

Упрощение эксплуатации

• Внутренний планировщик заданий
• Динамическое маскирование конфиденциальных данных в БД
• Разведка данных в БД на предмет их конфиденциальности
• Инкрементальный бэкап

Специальные технические характеристики

• Набор функций для совместимости с СУБД MS SQL для «1С»
• Улучшения для оптимизации работы с «1С»
• Набор функций для совместимости с СУБД Oracle
• Оптимизированное сжатие WAL

Сайт СУБД - https://tantorlabs.ru/

Система измерения продуктивности разработчиков

Чтобы использовать достаточно детализированную систему измерения продуктивности разработчиков, важно понимать тритипа показателей, которые необходимо отслеживать: 

• на уровне системы, 
• на уровне команды, 
• на индивидуальном уровне.

Дополнение показателей DORA и SPACE показателями, ориентированными на возможности, может создать комплексное представление о продуктивности разработчиков программного обеспечения.

Набор метрик можно представить такой таблицей:

Примечание. (D) - DORA метрика, (S) - SPACE метрика, (О) - метрики. ориентированные на возможности.

Данная таблица взята из работы:

Chandra Gnanasambandam, Martin Harrysson, Alharith Hussin, Jason Keovichit, and Shivam Srivastava. Yes, you can measure software developer productivity. 17.08.2023. 

https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity

Оригинал рисунка:

Набор метрик прозрачный, в связи с чем воздерживаюсь от комментариев.

Метрики DORA: Измерение эффективности DevOps

DORA

DORA (DevOps Research and Assessment) — это аббревиатура, представляющая четыре ключевых показателя:

• частота развертывания (DF),
• время выполнения изменений (LT),
• время восстановления службы (TRS),
• частота сбоев изменений (CFR).

Метрики DORA широко используются для оценки эффективности практик DevOps и непрерывной поставки программных приложений.

Частота развертывания: эта метрика измеряет, как часто команда развертывает код в рабочей среде. Более высокая частота означает более высокую производительность, так как это означает, что команда может быстрее вносить изменения и внедрять функции.

Время выполнения изменений: показывает количество времени с момента инициирования изменения кода до его доставки в рабочую среду. Более короткие сроки выполнения заказов означают более быструю доставку и реагирование на потребности бизнеса.

Время восстановления службы: эта метрика относится ко времени, необходимому для восстановления службы после сбоя или сбоя. Более низкое время указывает на более эффективные процессы реагирования на инциденты.

Частота сбоев изменений: вычисляет процент развертываний, вызвавших сбой в рабочей среде. Более низкая частота отказов указывает на более высокое качество программного обеспечения.

Метрики SPACE: оценка возможностей команды

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

• Satisfaction & Well-Being. Удовлетворенность и Благополучие.
• Performance. Производительность.
• Activity. Активность.
• Collaboration & Communication. Сотрудничество и Общение.
• Efficiency & Flow. Эффективность и Поток.

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

Производительность: Фокусируется на качестве, надежности и эффективности выполняемой работы. Высокая производительность коррелирует с удовлетворенностью клиентов и потенциально большим количеством возможностей для бизнеса.

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

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

Эффективность и поток: Оценивает эффективность процессов и использования ресурсов, выявляя узкие места и помогая в стратегическом планировании.

DORA vs SPACE

На первый взгляд может показаться, что DORA и SPACE нацелены на схожие результаты — оптимизацию производительности и эффективности команд разработчиков программного обеспечения. Однако при ближайшем рассмотрении оказывается, что эти два показателя служат разным аспектам организационного роста и во многом дополняют друг друга.

Приоритетные направления

DORA: Этот фреймворк предназначен для оптимизации процессов DevOps. Основное внимание уделяется операционной эффективности, связанной с развертыванием кода, восстановлением служб и управлением изменениями. DORA предлагает инструмент для просмотра жизненного цикла разработки программного обеспечения, предоставляя обратную связь, которая может направлять техническую оптимизацию.

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

Конечные цели

DORA: Конечная цель состоит в том, чтобы улучшить технические процессы и сделать их упорядоченными, эффективными и надежными. Метрики направлены на сокращение узких мест и сбоев, тем самым максимизируя эффективность конвейера разработки.

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

Измерительные инструменты

DORA: Метрики здесь часто являются количественными и данные могут автоматически собираться с помощью инструментов непрерывной интеграции/непрерывного развертывания (CI/CD), систем управления инцидентами, а также систем ведения журналов и мониторинга.

SPACE: Метрики более разнообразны и включают в себя качественные данные, такие как опросы и интервью, количественные данные, такие как показатели выполнения задач или сроки выполнения проектов для производительности.

Кому это выгодно?

DORA: Как правило, метрики наиболее полезны для технических руководителей, инженеров DevOps и менеджеров по эксплуатации, непосредственно участвующих в оптимизации процессов.

SPACE: Эти показатели предназначены для более широкой аудитории, включая специалистов по управлению персоналом, менеджеров проектов и руководителей команд, которые интересуются жесткими и мягкими аспектами управления командой.

Взаимосвязанность

Несмотря на то, что они сосредоточены на разных аспектах, метрики DORA и SPACE не являются взаимоисключающими. Они могут дополнять друг друга. Например, команде, которая набрала хорошие баллы по метрике SPACE для «Эффективности и потока», может быть проще улучшить показатели DORA, такие как «Время выполнения изменений». И наоборот, надежные метрики DORA могут создать среду, в которой командам будет проще сотрудничать и общаться, тем самым улучшая метрики SPACE.

Итог

Подводя итог, можно сказать, что в то время как DORA нацелена на то, «как» процесс разработки, SPACE фокусируется на том, «кто». Чтобы организация была по-настоящему гибкой, устойчивой и практичной, учитывайте оба показателя в тандеме.

Метрика измерения производительности разработчиков

В течение 6 лет группа DevOps Research and Assessment (DORA) из Google анализировала состояние DevOps в разных организациях. Они пришли к выводу, что оценить качество DevOps можно по четырем ключевым метрикам:

• Deployment Frequency. Частота развертывания продукта. "Частота деплоев".
• Lead Time for Changes. Время внесения изменений.
• Change Failure Rate. Коэффициент ошибок.
• Time to Restore Service. Время восстановления.

Частота развертывания продукта.

Метрика "частота деплоев" отвечает на вопрос — как часто команда успешно передает разработки в продуктивную эксплуатацию. Чем чаще тем лучше.

Время внесения изменений. 

Представьте, что мы разрабатываем некоторую полезную микрофункциональность ("фичу"). Программисты получили спринт и начали работать. После разработки и тестирования разработка помещена в ветку "master" - релиза, который готовится к передаче в продуктивную эскплуацию. Сколько времени будет находится в ветке "master" - это и есть время внесения изменений? Чем меньше тем лучше.

Коэффициент ошибок. 

Случается, что после релиза возникают ошибки. Коэффициент ошибок — процент развертываний ("деплоев"), которые привели к проблемам в продуктивной системе. Чем меньше тем лучше.

Время восстановления. 

Из-за ошибки может произойти остановка в работке ("outage"). Может подвести код, может подвести инфраструктура, иногда - природа. Время восстановления — это время, которое нужно для восстановления после ошибки. Чем меньше — тем лучше.

Регулярно измеряя эти метрики вы можете получить оценку уровня DevOps и следить за ее прогрессом. Оценка может быть такой: Elite, High, Medium или Low.

Второй набор отраслевых показателей — это метрики SPACE:

• удовлетворенность и благополучие, 
• производительность,
• активность, 
• общение и сотрудничество, 
• эффективность и поток.

Эти показатели GitHub и Microsoft Research разработали в дополнение к метрикам DORA.

По материалам.

https://habr.com/ru/articles/583268/

PavloPoliakov. Измеряем DevOps, что такое DORA метрики.

Программное обеспечение трансформирует каждую отрасль

Все больше и больше традиционных компаний понимают, что для того, чтобы конкурировать и расти в цифровом мире, они должны выглядеть, думать и действовать как компании-разработчики программного обеспечения. Согласно исследованию McKinsey, проведенному в июне 2022 года, почти 70% наиболее эффективных экономических деятелей, по сравнению с половиной их коллег, используют собственное программное обеспечение, чтобы выделиться среди конкурентов. Треть - напрямую монетизирует программное обеспечение.

Хотя компании, возможно, уже признали важность программного обеспечения, они по-прежнему склонны рассматривать программное обеспечение как возможность, которую они могут "прикрутить" к существующиму бизнесу. 

И что приходится делать? Развивать софтверный бизнес, то есть создавать подразделение или бизнес-единицу, которые будут заниматься разработкой программного обеспечения. Но не получится подойти к развитию софтверного бизнеса на тех же корпоративных подходах и технологиях, что и традиционный бизнес. Но так не получится - чтобы развить софтверный бизнес, необходимы фундаментальные изменения, связанные с различным набором навыков, практикой, лидерством и организационной структурой.

Выделяют три архетипа компаний, переходящих от традиционной бизнес-модели к бизнес-модели программного обеспечения.

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

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

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

Некоторые компании следуют нескольким архетипам, если у них есть возможности и достаточный рыночный спрос.

Но не все так просто. Только 7% рынка программного обеспечения приходится на нетехнологические компании. Остальную долю рынка держат софтверные профессиональные компании.

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

Придерживаться культуры разработки программного обеспечения.

Требуется создать культуру, которая глубоко ценит творчество и мастерство инженеров, лидерство, ​​ориентированность на клиента. Руководящая команда должна обладать глубокое понимание бизнес-моделей и технологии программного обеспечения.

Лидерство

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

Коммуникация

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

Не менее важно знать, как идут дела у других компаний, какие используются технологии и каковы затраты ресурсов, труда и квалификации.

Инвестиции

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

Инвестируйте в менеджеров по программным продуктам

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

Две ключевые характеристики отличного менеджера по продукту:

1. Такие менеджеры зациклены на данных об использовании программного продукта и используют все доступные и недоступные данные: от знания клиентов, информирования о продвижении согласно дорожной карты создания программного продукта до принятия решений о выводе продукта из эксплуатации, а также в содействии пользователям деле быстрого извлечения выгод от использования клиентом программного продукта. Продукт-менеджеры проводят активные полевые испытания и эксперименты для получения нужных данных о том, как улучшать продукт.
2. У отличного менеджера по продукту прекрасное «чувство продукта», точно так же, как у лучшего тренера лошадей есть «чувство лошади». Основываясь на многолетнем опыте и мышлении, не ограниченном нормами, успешные продакт-менеджеры обладают интуитивной способностью понимать, как технологии могут решить проблему клиента по-новому. Они привлекают дизайнеров, инженеров и специалистов по обработке и анализу данных на ранней стадии формирования идей и задействуют широкий спектр нестандартного мышления.

Автономные команды, гибкая архитектура для достижения высоких результатов

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

Чтобы команды разработчиков могли работать автономно, им нужна гибкая техническая архитектура. Основные компоненты этой архитектуры включают API, которые могут получать доступ к базовым данным, алгоритмам и процессам в устаревших системах; набор микросервисов (по сути автономных единиц кода, которые выполняют определенную функцию), которые являются модульными и подключаются к API, устраняя зависимости, которые досаждают устаревшим системам, где изменение одной части кода обычно требует множественных изменений в других; и общая платформа данных, которая объединяет разрозненные источники данных в единый доступный пул, к которому разработчики могут легко получить доступ.

Экосистема в деле разработки программного обеспечения

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

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

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

Создание возможности выхода на рынок программного обеспечения

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

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

Поиск и сохранение талантов

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

Компаниям, стремящимся привлечь таланты в области программного обеспечения, вероятно, придется переосмыслить свои методы найма.

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

Опыт разработчиков может быть настолько важен, что компания использует панель инструментов для отслеживания оценок удовлетворенности разработчиков.

Источник

McKinsey Quarterly
Every company is a software company: Six ‘must dos’ to succeed
December 13, 2022

https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/every-company-is-a-software-company-six-must-dos-to-succeed

Тренды - Разработка программного обеспечения нового поколения

Разработка программного обеспечения нового поколения

Затронутые этапы жизненного цикла:

1. Планирование и анализ (Planning and analysis).
2. Архитектурный дизайн (Architecture design).
3. Разработка и кодирование (Development and coding).
4. Тестирование (Testing).
5. Развертывание и обслуживание (Deployment and maintenance).

Источник. 

McKinsey Technology Trends Outlook 2022. August 2022. McKinsey analysis. 

Технология или набор инструментов:

• Платформы с низким объемом кодирования или без кодирования (Low-code/no-code platform). Платформы на основе графического пользовательского интерфейса (GUI) для неразработчиков, которые можно использовать при создании приложений.
• Инфраструктура как код (Infrastructure-as-code). Шаблоны конфигурации для предоставления инфраструктуры для приложений, использующих Terraform, Ansible и т. д.
• Микросервисы и API  (Microswevices and APIs). Автономные модульные фрагменты кода, которые можно собирать в более крупные приложения.
• ИИ «партнер программиста»  (AI "pair programmer"). Рекомендации по коду на основе контекста входного кода или естественного языка.
• Тестирование с использованием ИИ (AI-based testing). Автоматизированное модульное тестирование и тестирование производительности для сокращения времени, затрачиваемого разработчиком на тестирование.
• Автоматическая проверка кода (Automated code review). Автоматизированные программные проверки исходного кода с помощью ИИ или предопределенных правил.

Каковы наиболее примечательные технологии?

На протяжении всего жизненного цикла разработки программного обеспечения технологии уже повышают скорость разработки.

Платформы с низким объемом кодирования или без кодирования (Low-code/no-code platform).

• Стандартизированные инструменты и процессы, масштабирующие технологические инновации за счет повторного использования компонентов.
• Ускорение разработки приложений с помощью программных компонентов plug-and-play
• Более тесная согласованность бизнеса в результате приближения технических требований к бизнес-подразделениям
• Автоматическое развертывание моделей в производственных приложениях
• Расширенный мониторинг и обслуживание (например, переобучение модели) для сведения к минимуму снижение производительности.

2. Этап - Архитектурный дизайн

Инфраструктура как код:

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

3. Этап - Разработка и кодирование

Программист - партнер ИИ

• Быстрая разработка, так как разработчики пишут код быстрее с меньшими трудностями, чтобы облегчить «поток разработчиков».
• Активатор автоматических переводов и инструментов lowcode/no-code

Микросервисы и API

• Ускорение разработки, поскольку микросервисы и API служат строительными блоками, которые компании используют для простого добавления функций в программное обеспечение.
• Новые потоки доходов в виде API-интерфейсов могут предоставляться клиентам в рамках модели «как услуга».

4. Этап - Тестирование

Тестирование на основе ИИ

• Более быстрое и эффективное тестирование благодаря интеллектуальной автоматизации
• Улучшенный тестовый охват и эффективность: ожидается, что автоматизированное написание сценариев превысит 80% тестового охвата.

5. Этап - Развертывание и обслуживание

Автоматическая проверка кода

• Более быстрая и эффективная проверка кода с более широким охватом в результате устранения ручного ввода и устранения человеческих предубеждений.

Что дебатируется?

1. В какой степени технология "без кода" может уменьшить потребность в программистах?

Хотя платформы с низким кодом/без кода помогают командам быстро создавать прототипы или позволяют неразработчикам взять на себя часть работы разработчиков, они по-прежнему недостаточно гибки с точки зрения сокращения объемов разработки на каждом этапе жизненного цикла разработки программного обеспечения (например, когда устаревшие системы требуют обновления).

2. С культурной точки зрения, будут ли команды — как разработчики, так и не разработчики — принимать или сопротивляться технологиям следующего поколения?

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

3. Какие проблемы, связанные с интеллектуальной собственностью могут повлиять на код, написанный приложением ИИ?

По мере того, как компании используют инструменты для создания ИИ, возникают проблемы с правом собственности: будет ли оно принадлежать компании, разработавшей приложение, или оно будет принадлежать поставщику инструментов для создания кода с поддержкой ИИ?

4 В какой степени бизнес-подразделения будут нести ответственность за «здоровье» приложений?

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

Источник. 

McKinsey Technology Trends Outlook 2022. August 2022. McKinsey analysis.

Перечень проблем в разработке ПО

Хорошая заметка про разработку в "Российское ПО или каково пить сладкий чай без сахара". https://habr.com/ru/company/ruvds/blog/672530/

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

И так сойдёт

Конечному пользователю предлагается то программное обеспечение, которое ему нужно, но при этом нет ни протестированного UI/UX, ни обкатки на бета-версии, ни продуманных элементов управления. Фактически пользователь получает функцию, которая ему нужна, а удобная она или нет — дело второе.

Есть конкуренция, есть строгие правила стора или маркетплейса — всё будет совершенно иначе, интерфейс будет продуман, протестирован и раскатан постепенно, со сбором баг-репортов.

Главное — продать

Одни ищут путь улучшения, другие ищут путь продажи.

А давайте прикроем то, что не очень?

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

Я так сказал!

Иногда руководители смотрят на пользователей из своего кабинета или судят о них, например, по статьям на Хабре, или считают откровенными дурачками (или, наоборот, компьютерными гениями). Они уверены, что знают о паттернах поведения всё и навязывают своё мнение, не слушая остальных. Разубедить — невозможно. А потом пользователь вообще не может понять, для кого разрабатывалась программа, требует обучения, жалуется на профильных сайтах и отзовиках.

Мечтатели

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

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

Плохое тестирование

Творец сотворил программу, творец отдыхает, какая к чёрту верификация?! Я знаю немало компаний, программное обеспечение которых не просто существует, а на слуху, но при этом не тестируется профессиональной командой QA. Тестируют либо сами разработчики, либо сотрудники компании, либо группа самых лояльных клиентов (лояльность обычно покупается за большую скидку или бесплатную поддержку).

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

Молодая динамичная команда…

…потому что на опытного разработчика мы не потянем. Есть компании, в которых опытных разработчиков на руках носят — вы легко вспомните В2С-сервисы, финтех и ритейл, где всё хорошо. Это видно по продукту. А есть компании (крупные в том числе), где дешевле взять пучок программистов, обучить, выжать из них человекочасы и объём кода. Разумеется, архитектура приложений, код и качество программ от этого лучше не становятся.

Автоматизация = ручной работе

Есть программы как в бизнес-секторе, так и в инженерной и промышленной среде, где руками быстрее или как минимум — столько же по времени. Иногда настолько долго обрабатывается информация (право, кому нужен этот рефакторинг!), иногда нужная информация или функций скрыта в дебрях кликов (и снова непродуманный UI/UX).

Нет вопросов, иди и фигачь

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

А вот понимание «почему» компания далась в ту или иную разработку, даёт понимание целей и проблем, которые программа будет решать. Ответ на этот вопрос даёт свой дух и идею.

Еще раз упомяну - по мотивам "Российское ПО или каково пить сладкий чай без сахара". https://habr.com/ru/company/ruvds/blog/672530/

Недостатки ООП

Есть много красивых идей, которые у людей ассоциируются с ООП (объектно-ориентированным программированием), но объектно-ориентированное программирование сопряжено также и с рядом недостаков.

По мотивам Object Oriented Programming is an expensive disaster which must end
(http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end)

Кстати, о парадигамах программирования можно ознакомиться в Википедии - их много! Но в данной статье раскрываются два тезиса:

1. По сравнению с другими языками (лиспами, функциональными языками и т. п.) ООП-языки не обладают уникальными сильными сторонами.
2. По сравнению с другими языками языки ООП обремены ненужной сложностью, что приводит к высоким издержкам проектирования и создания кода.

ООП может быть плохо определенным, аморфным понятием, но оно абсолютно доминирует в технологической индустрии. Многие разработчики программного обеспечения и многие компании считают, что ООП - единственный разумный способ разработки программного обеспечения сегодня. Любой, кто выступает против ООП, немедленно осознает тот факт, что он выступает против «общепринятого мнения» отрасли.

12 вещей, которые должны быть преимуществами ООП, но на самом деле таковыми не являются

• Инкапсуляция.
• Полиморфизм.
• Наследование.
• Абстракция.
• Повторное использование кода.
• Преимущества дизайна.
• Сопровождение программного обеспечения.
• Принцип единой ответственности (Single Responsibility Principle, SRP).
• Принцип открытия/закрытия (Open/closed principle).
• Принцип разделения интерфейса (Interface segregation principle, ISP).
• Принцип инверсии зависимостей (Dependency inversion principle).
• Статическая проверка типа.

ООП акцентирует внимание на внутренних свойствах объектов и внутреннем поведении, но при создании больших и главное, - развиваемых систем, - основаная сложность лежит в проектировании взаимодействия модулей, а не в области внутреннего устройства объектов. Конечно, важно и то, и другое, но суть проблем лежит в области акцентов - интеграция и взаимодействие или внутренняя структура. И еще одно, ООП - не слишком ли аморфная концепция с точки зрения обеспечения успеха?

Инкапсуляция

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

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

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

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

Полиморфизм

Полиморфизм в ООП слаб, и все же, как ни парадоксально, полиморфизм часто упоминается как сильная сторона ООП.

Зачем нам полиморфизм? Мы хотим гибкости в способах управления исполнением. Но языки ООП обеспечивают гибкость только на основе сигнатуры метода, и сигнатура почти всегда ограничена типами параметров, передаваемых в метод. Так в чем тогда преимущества полиморфизма, если они весьма относительны.

Есть и другие способы гибкой диспетчеризации исполнения.

Наследование

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

Но в программировании ООП наследование опасно. К недостаткам использования наследования объектов можно отнести следующие.

• Большая иерархия наследования. Чрезмерное использование наследования может привести к иерархии наследования, которая имеет несколько уровней глубины. Такими большими иерархиями наследования становится трудно управлять. Их трудно поддерживать из-за того, что производный класс уязвим для изменений, внесенных в любой из производных классов, что и  приводит к хрупкости. Есть еще соображения производительности: создание экземпляров таких классов включает вызов конструкторов по всей иерархии наследования. Плюс требования к памяти "выше среднего" для таких объектов. Примером такого класса - класс javax.swing.JFrame в библиотеке Java Swing, который имеет шесть уровней наследования.

• Хрупкие суперклассы. Классы, которые были подклассами, не могут быть изменены в последующих версиях, потому что это может отрицательно повлиять на производные классы.

• "Разрыв" инкапсуляции. Наследование в ООП - это прежде всего механизм повторного использования исходного кода, а не механизм повторного использования двоичных объектов. Но прозрачность характера наследования ООП зависит от того, является ли автор производного класса автором базового класса или имеет ли он доступ к деталям реализации базового класса. Это нарушает один из других принципов объектно-ориентированного программирования -  инкапсуляцию.

Джошуа Блох в своей книге «Эффективная Java» говорит: «Предпочитайте композицию наследованию». Это симптоматично, что ООП пришлось отказаться от такой мощной идеи как инкапсуляция и признать, что композиция стала предпочтительной стратегией.

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

Абстракция

«Разработчики программного обеспечения используют абстракцию для разложения сложных систем на более мелкие компоненты». Это абсолютно верно и не имеет ничего общего с ООП.

Эта часть относится к ООП: «Абстракция обозначает основные характеристики объекта, которые отличают его от всех других видов объектов и, таким образом, обеспечивают четко определенные концептуальные границы относительно зрительской точки зрения».

Это определение «абстракции» приводит к совету «программа к интерфейсу, а не "программа к реализации класса».

Объекты связывают функции и структуры данных в неделимые единицы. Но может это фундаментальная ошибка, поскольку функции и структуры данных принадлежат совершенно разным мирам.

Функции производят выход. У функций есть входы и выходы. Входы и выходы - это структуры данных, которые изменяются функциями. В большинстве языков функции построены из последовательности императивов типа: «Сделай то, а потом то ...». Чтобы понять функции, вы должны понимать порядок, в котором они выполняются. Функции понимаются как черные ящики, которые преобразуют входы в выходы. Если я понимаю ввод и вывод, значит, я понял функцию. Это не значит, что я мог написать функцию.

Структуры данных просто есть. Они ничего не делают. Они декларативны по своей сути. «Понять» структуру данных намного проще, чем «понять» функцию. Функции обычно «понимают», наблюдая за тем как они переносят структуру данных типа T1 в структуру данных типа T2.

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

Повторное использование

Конечно, если вы будете очень осторожны, вы можете добиться довольно высокого уровня повторного использования кода на любом языке, включая любой язык ООП. Но, как правило, приходится идти на компромиссы: достижение одной цели означает принесение в жертву другой. Чтобы достичь высокого уровня повторного использования языков ООП, часто приходится писать очень маленькие классы, что приводит к взрывному росту числа классов. 

Джон Баркер подчеркивает это:

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

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

Преимущества дизайна (Design Benefits)

Суть преимуществ дизайна в ООП формулируется так: «Кроме того, как только программа достигает определенного размера, объектно-ориентированные программы на самом деле проще программировать, чем не объектно-ориентированные».

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

Джефф Этвуд описал как минимум 2 проблемы с концепцией паттернов дизайна :

1. Шаблоны проектирования - это форма сложности. Как и в случае со всей сложностью, я бы предпочел, чтобы разработчики сосредоточились на более простых решениях, прежде чем сразу переходить к сложному рецепту шаблонов проектирования.

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

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

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

Сопровождение программного обеспечения

Об этом: «Объектно-ориентированную программу намного легче изменять и поддерживать, чем не объектно-ориентированную программу. Поэтому, несмотря на то, что перед написанием программы проводится много работы, требуется меньше работы для ее поддержки с течением времени ».

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

Кроме того, объектно-ориентированные программы обычно раздуты, содержат много бесполезного шаблонного кода. Поэтому для тех же функциональных возможностей, но реализованных в другом стиле (не в парадигме ООП), усилий по поддержке будет меньше.

Принцип единой ответственности (Single Responsibility Principle, SRP)

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

В пределах класса может быть много причин изменения состояния. Например, для класса "Сотрудник", изменение может вызвано многими причинами: изменением должности, зарплаты, квалификации, отпуском, болезнью и тому подобное. Эти методы обычно реализуют в пределах одного класса, с тем чтобы контролировать все причины изменения в одном месте. Реализуются они так потому что, согласно концепции ООП, хороший класс должен содержать все методы, управляющие им. И мы не можем распределить функции по разным классам, чтобы удовлетворить принципу SPR.

Принцип открытия/закрытия (Open/closed principle)

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

Принцип разделения интерфейса (Interface segregation principle)

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

ISP - это костыль, который поддерживает ООП. То есть ООП нуждается в поддержке. 

«ISP предназначен для того, чтобы система оставалась изолированной, и, в силу этого, ее было легче реорганизовать, изменить и повторно развернуть». 

Более серьезный вопрос: «Облегчает ли ООП рефакторинг, изменение и повторное развертывание?» 

Если ООП подрывает эти вещи, то ISP - не более чем лекарство для очень больного пациента.

Мы все можем согласиться с тем, что «написание… не требующего пояснений программного обеспечения почти так же важно, как написание рабочего программного обеспечения». Но как создать программное обеспечение, не требующее пояснений? 

Ключевым моментом является выявление базовой модели данных, то есть типов данных и их иерархии. 

Фредрик Брукс однажды сказал: "Покажи мне свои блок-схемы и скрой свои таблицы, и я буду продолжать озадачиваться. Покажите мне свои таблицы, и обычно ваши блок-схемы мне не понадобятся; они будут очевидны". 

Эрик Реймонд: "Покажите мне свой код и скройте свои структуры данных, и я буду продолжать озадачиваться. Покажите мне свои структуры данных, и обычно ваш код мне не понадобится; это будет очевидно".

В объектно-ориентированном языке программирования определения типов данных принадлежат объектам. Поэтому я не могу найти все определения типа данных в одном месте.

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

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

В конце концов, нужно ли вам отказаться от абстракций ООП и перейти к языку более низкого уровня, если вас больше всего беспокоят вопросы эффективности?

Принцип инверсии зависимостей (Dependency inversion principle)

Мы боремся с проблемой, которая существует только при использовании ООП. В сообществе Java возникла волна легких контейнеров, которые помогают собирать компоненты из разных проектов в единое приложение. В основе этих контейнеров лежит общий образец, реализующий концепцию под очень общим названием «Инверсия управления».

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

• Constructor Injection (внедрение конструктора), 
• Setter Injection (внедрение сеттера),
• Interface Injection (внедрение интерфейса).

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

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

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

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

Статическая проверка типа

Самый очевидный аргумент против статической типизации заключается в том, что она требует определенного уровня уверенности, которой может и не быть. Разработчики, использующие статическую типизацию, указывают все типы в начале своего проекта, прежде чем они получат более конкретные сведения о решаемой проблеме. Сторонники статической типизации приведут контраргумент о том, что типы легко менять по мере того, как разработчик узнает больше о решаемой проблеме. Но я бы сказал, что неверно делать вид, будто вы вначале понимаете систему. Я хочу честно сказать, - я невежественен, когда начинаю работать над проблемой, с которой никогда раньше не сталкивался.

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

Пример идеи зомби: - политические идеи, которые убиваются доказательствами, тем не менее, неуклонно продвигаются вперед, главным образом потому, что они соответствуют политической повестке дня. И есть явно политическая идея, которая привела ООП к своему пику в 1990-х: идея аутсорсинга.

Идея аутсорсинга разработки программного обеспечения основывалась на некоторых предположениях о том, как должна проводится разработка программного обеспечения. В частности, такой идеи - как идея о «гениальном» архитекторе, поддерживаемом армией дебилов, которые действуют как секретари, программируя под диктовку. ООП был программным эквивалентом тенденции, которая стала распространенной в производстве в 1980-е годы: дизайн должен оставаться в головной конторе а фактическое производство кода должно быть отправлено в страны третьего мира. Работая с UML-диаграммами, написание кода могло быть сведено к простой рутинной работе, в то время как разработкой программного обеспечения могли заниматься провидцы, обладающие эпическим воображением, провидцы, которые могли указать иерархию объектно-ориентированных приложений, которая затем могла быть отправлена ​​в Индию или Вьетнам.

Суть в том, что, затрудняя глупым программистам делать плохие вещи, Java действительно мешает умным программистам, пытающимся создавать хорошие программы.

Мифы о создании ПО

Многие компании, не связанные с ИТ-технологиями, обращаются к цифровым моделям построения бизнеса. Ставка тут - рост бизнеса за счет программного обеспечения. Например, среди промышленных компаний около 38% компаний заявили, что они стремятся получать более 50% доходов за счет цифровых технологий и услуг в течении следующих трех лет. Но и тут дело обошлось не без заблуждений.

Итак, вот некоторые из сложившихся заблуждений.

1. Цифровая трансформация - это инжерная задача. В частности, ИТ задача.

Но...

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

2. Компании нужно нанять несколько топ-менеджеров, работавших в лучших технологических компаниях для перенацеливания ИТ специалистов для построения нового программного обеспечения. 

Но...

Компании, которые не работают с цифровыми технологиями не могут конкурировать с лидирующими технологическими компаниями в вопросе привлечения лучших специалистов соответствующего технического и управленческого профиля. Лучшим выбором будет набор специалистов, работающих в компаниях среднего уровня.

3. Рост масштабов бизнеса должен обеспечиваться за счет приобретения мелких игроков.

Но...

Заключение одной якорной сделки на большую сумму дает в 5 раз больший эффект чем приобретение мелких компаний. Потому что серия небольших цифровых приобретений часто создает трудности с интеграцией недавно приобретенных компаний. Приобретаемые компании не только отличаются от культуры покупателя (как и следовало ожидать), но и обычно сильно отличаются друг от друга. Таким образом, становится трудно объединить эти компании вместе, чтобы сформировать новую цифровую операционную модель.

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

Но...

Продажа программного обеспечения отличается от продажи других продуктов. Продажа ПО требует технических навыков и глубокого опыта работы с программным обеспечением. "Обычный" торговый персонал может не понимать что за программное обеспечение они продают, это раз. И во-вторых, оин не имеет опыта, и тем самым не вызывает доверия клиентов. А завоевае доверия клиентов - крайне важно в конкурентной борьбе.

Оригинал текст с мифоми.

https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/four-myths-about-building-a-software-business

McKinsey Quarterly. "Четыре мифа о создании программного обеспечения". 30 апреля 2021 г. 

Извращение agile подхода в разработке ПО

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

(Это из http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end).

Например, agile методология - одна из попыток привнести правильные методы для разработки ПО. 

По поводу создания этой методологии Дэйв Томас писал, что 

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

• Люди и взаимодействия важнее процессов и инструментов.
• Рабочее программное обеспечение вместо исчерпывающей документации.
• Сотрудничество с клиентами в ходе реаализации.
• Реагирование на изменения вместо следования плану.

И далее "… Слово «гибкая разработка» было извращено до такой степени, что стало бессмысленным, и теперь скорее является "кормовой базой" консультантов и поставщиков услуг". … Как только Манифест стал популярным, слово agile стало маркетинговым термином, призванным улучшить продажи. Таким же маркетинговым словом, как и "эко-" и "натуральный". Слово, которым злоупотребляют таким образом, становится бесполезным - слово перестает иметь значение, когда превращается в бренд.

Ричард Бишоп пишет о подобном подходе к Agile со стороны тех, кто зарабатывает на консультировании и внедрении agile.

Я участвовал в трехдневном совещании по планированию шестинедельного «спринта». Я видел карточки пользовательских историй, на которых не было ничего, кроме надписи «Сделайте приборную панель лучше» и эти карточки были сделаны сертифицированными мастерами Scrum. В конце концов, они сказали мне, что работают в технологии Agile.

… Каждый раз, когда я говорю с так называемой Agile-компанией о том, как они работают, я получаю подробный список веб-приложений SaaS. Trello, Basecamp, JIRA, Pivotal - ни одного из этих инструментов не существовало, когда создавался Манифест гибкой разработки. Эти инструменты - не решение.

Задачи API

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

Тем не менее ряду предприятий не удалось получить ожидаемые выгоды от API. Во многих случаях создание API без продуманной стратегии создает беспорядок с дублированием разработок, с плохим обслуживанием и ограниченной прозрачностью, сводя на нет многие из потенциальных преимуществ интерфейсов. Некоторые компании потратили годы на замену мегасистем, на добавление API-интерфейсов не имея соответствующих стратегии и плана. И, соответственно, такие компании не сумели достичь  реального прогресса.

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

Чтобы избежать ловушек и получить выгоды от инициатив в области API, ИТ-директора должны решить семь ключевых задач.

Задача №1. С чего начать? 

Задача актуальна в том случае, если непонятно - какие первые шаги в деле создания и реализации API.

Гибкость API означает, что их можно использовать практически где угодно с тем, чтобы улучшить что-нибудь. Но чтобы принять решение о том, какие API-интерфейсы следует создавать, нужно определиться: какие API ориентированы на клиентские приложения, а какие API - на решение технологических задач. В таком контексте ИТ-руководители могут определять приоритеты разработки API на основе стратегических целей, путем оценки влияния разработок на бизнес и содействия решению задач модернизации и трансформации бизнеса. Работа с клиентом - хорошее место для размышлений о том, какие API стоит создавать. Это позволяет определить, какие API-интерфейсы могут объединить разрозненные ИТ-системы для обеспечения непрерывного взаимодействия с клиентами. 

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

• Доступ к данным и интеграция. API-интерфейсы могут предоставлять данные в различных ИТ-системах, как в устаревших, так и в современных. Затем их можно использовать для извлечения данных и связывания их с системами расширенной аналитики.
• Миграция в облако. Большинство крупных организаций по-прежнему имеют значительную внутреннюю локальную инфраструктуру и только начали переходить на частные облака. Небольшое количество компаний приступает к миграции в публичное облако. Управление гибридной облачной средой требует от ИТ-руководителей API-интерфейсов, которые могут получить доступ к инфраструктуре как в частных, так и в общедоступных облачных активах.
• Базовая цифровая трансформация. API-интерфейсы могут помочь в преобразованиях, поскольку они могут подключать основные ИТ-системы и конкретные данные внутри них к цифровым платформам. API-интерфейсы также могут служить соединительной тканью и механизмом синхронизации как в современных, так и в устаревших системах.

Все элементы тесно связаны. Таким образом, чтобы определиться с первоочередными API-интерфейсами, необходимо составить список наиболее важных задач. Затем отметить - какие API-интерфейсы способствуют решению этих задач. Тем самым, реализация этих API-интерфейсов позволяет разблокировать данные, облако и ресурсы, способствующие решению важных задач. Второе, определить API-интерфейсы, которые позволят организации работать гибко и продуктивно, в частности, работать в раъных режимах, - в режиме продуктивной эксплуатации, в режиме тестирования и обучения.

Задача №2. Как должны выглядеть команды разработки и внедрения API?

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

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

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

• Централизованный подход. Централизованная группа разрабатывает большинство API как для бизнеса, так и для технологических подразделений. Эта модель позволяет быстро создавать множество API, но центральной группе необходимо тесно сотрудничать с бизнесом на местах или с ИТ-подразделениями с тем, чтобы обеспечить приоритетность разработки нужных API.
• Децентрализованный подход. Набор специализированных "мастерских" - групп разработки API, встроенных в различные бизнес-подразделения и в технологические подразделения. Этот подход работает как кросс-функциональный. В этой модели API-интерфейсы с большей вероятностью будут согласованы с бизнес-потребностями, но обеспечение соблюдения стандартов и передовых методов разработки может оказаться трудным.
• Гибридный подход. Согласно гибридной модели централизованная структура, - фабрика API, - создает базовые API. Отдельные бизнес-подразделения и технологические подразделения вносят свой вклад в каталог API, следуя таксономии и стандартам, установленным центральным ИТ-подразделением и использует базовые API, созданные центральным подразделением.

Задача № 3: Что отслеживается и как демонстрируются преимущества программы API?

Компании часто используют множество разных и неподходящих показателей для оценки производительности API. Действия команд следует оценивать с использованием набора общих гибких метрик: прямая бизнес-ценность API-интерфейсов, ориентированных на клиентов, и повторное использование/сокращение "технической задолженности" для API-интерфейсов серверной части. Другие потенциальные метрики включают одобрение API разработчиками, вклад в упрощение архитектуры или снижение затрат на инфраструктуру и ключевые показатели эффективности (KPI) для конкретных случаев.

Общие метрики.

Затраты.

• Затраты на разработку API: средние затраты на разработку АРI, опеределяемые путем деления бюджета на разработку API, приходящегося на рассматриваемое API.
• Затраты на выполнение API. Средние операционные затраты на API, включая поддержку и исправление ошибок, опеределяемые как операционные расходы, приходящиеся на API.

Качество.

• Количество инцендентов на API. Число ошибок, происходящих в ходе применения API.
• Качество кода. Количество ошибок, приходящихся на автоматически выполняемые тесты.
• Покрытие автоматизированными тестами. Определяется в ходе проведения тестирования.

Результативность.

• Количество реализованных АPI. Общее число используемых API.
• Количество активно используемых API. Процент API, встроенных в приложения.

Влияние сервисных API. 

• Сокращение "технологической задолженности". Процент АPI, используемых в сервисных программах и программах разработки.
• Повторное использование API. Среднее число приложений и сервисов, в которые интегрированы API.

Влияние клиентских API.

• Монетизация. Доходы или прибыль, генерируемые API.

Задача №4. Какая бизнес-польза API-интерфейсов?

Повышают ли API-интерфейсы ценность и гибкость бизнеса?

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

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

Задача № 5: Какие технологические инструменты нужны?

ИТ-руководители могут легко потеряться в технологиях, связанных с API, что ведет к потере ресурсов и снижению производительности.

Первым ключевым техническим решением является выбор правильного фреймворка или платформы разработки приложений для создания API. Далее важно работать с руководителями бизнеса и иметь список надлежащих вариантов использования API-интерфейсов на основе технической осуществимости (например, готовности серверной части), бизнес-правил и условий, которые необходимо обрабатывать. Затем ИТ-организации необходимо установить форматы данных для API-интерфейсов и разработать эталонную архитектуру API, которая будет модульной, гибкой и расширяемой. Это предотвратит создание ненужных технических слоев. Руководители инженерных разработок также должны установить руководящие принципы разработки API, обучить владельцев продуктов лучшим практикам применения API, предоставлять наборы инструментов и каталоги API и следить, чтобы разработчики придерживались передовых практик и повторно использовали API.

Следующие технологическое решение касается шлюза и портала разработчика API. Шлюз API содержит все API, собирает аналитику в ходе выполнения транзакций и выполняет кэширование данных. Важно решить, кто управляет шлюзом, и установить правила управления им. Некоторые компании выбирают централизованную платформу API. Хотя для одной команды может быть полезно отвечать за шлюз, но эта команда может стать узким местом. Облачный API-шлюз и портал для разработчиков позволяют отдельным подразделениям отвечать за разные наборы API, а также позволяют разработчикам получать доступ ко всем API в одном месте. Это обеспечивает децентрализованное управление на основе ряда опубликованных стандартов, которые применяются в организации.

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

Проблема № 6: Кому и какие API принадлежат?

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

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

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

Гибкий жизненный цикл API непрерывного улучшения

Анализ потребностей в API.

• Сопоставление индивидуальных требований к API с дорожной картой.
• Обеспечение перекрестных ссылок API с существующим каталогом.
• Опубликование всех API через портал для использования.

Разработка/расширение/повторное использование.

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

Развертывание API.

• Опубликование API для шлюзов, предоставление документации и сообщение сообществу пользователей.

Использование API.

• При необходимости поддержка и исправление API.
• Поддержка проектных команд, использующих API.
• Мониторинг во время работы:
• Безопасность.
• Применение.
• Ценность для бизнеса.
• Измерение и регулирование.

Обзор производительности API.

• Рассмотрение каждого спринта, API метрик для определения последующих шагов (продолжение операций, модификаций или вывода из эксплуатации).
• Извлечение уроков из мониторинга.
• Потребность новых модификаций в рамках действующих жизненных циклов. 

Вывод API из эксплуатации.

• Вывод устаревщих API.

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

Задача № 7: Определиться - откуда взять достаточно квалифицированных сотрудников?

Есть два набора решений, которые компании должны принять в отношении квалификации.

1. Какие приобрести новые навыки.

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

2. Какие технологические внутренние возможности улучшить или создать

Для создания новых бизнес-возможностей необходимо информировать бизнес-лидеров о ценности API и повышать квалификацию ИТ-архитекторов и разработчиков, чтобы они могли работать в современной среде разработки API. Руководители бизнеса должны понимать "что такое API-интерфейс" и варианты его использования, какие требуются ресурсы для разработки, развертывания и эксплуатации API прежде всего для получения полной ценности от использования API. ИТ-архитекторы и разработчики должны хорошо разбираться в различных типах API-интерфейсов, которые потребуются и изучать современные технологии. Они также должны получить возможность пользоваться основными инструментами и средами разработки API.

Данный материал изложен в 

Семь непреложных задач API, которые необходимо решить ИТ-директорам 19 декабря 2018 г. | Статья

Об абстрациях в ООП

Взято из следующего материала http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end .

Что касается этого стремления к абстракции в ПО, Джоэл Спольски написал пародию о постройке полки для специй.

Я решил купить молоток и попросил у продавца молоток.

"Молоток?" он спросил. «Никто больше не покупает молотки. Они немного старомодны ».

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

«Что ж, проблема с молотками в том, что существует очень много разных видов. Кувалды, гвоздодеры, перфораторы. Что, если вы купили один молоток, а потом поняли, что вам понадобится другой молоток позже? Для следующего задания вам придется купить отдельный молоток. Как оказалось, большинству людей действительно нужен один молоток, способный справиться со всеми видами молотковых задач, с которыми вы можете столкнуться в своей жизни ».

«Хммммм. Что ж, я полагаю, это звучит нормально. Вы можете показать мне, где найти универсальный молот ».

«Нет, мы их больше не продаем. Они довольно устарели ».

"В самом деле? Я думал, вы только что сказали, что Universal Hammer - это волна будущего ».

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

"Это правда. Итак, если никто больше не покупает универсальные молотки, и если вы больше не продаете все эти старомодные молотки, какие молотки вы продаете? »

«На самом деле, мы вообще не продаем молотки».

"Так…"

«Согласно нашим исследованиям, людям действительно нужен был не универсальный молоток. Всегда лучше иметь молоток, подходящий для работы. Итак, мы начали продавать молотковые заводы, способные производить любые виды молотков, которые могут быть вам интересны. Все, что вам нужно сделать, это укомплектовать молотковую фабрику рабочими, активировать оборудование, купить сырье, оплатить счета за коммунальные услуги и PRESTO… вы получите * именно тот молоток, который вам нужен, в кратчайшие сроки ».

«Но я действительно не хочу покупать молотковый завод…»

"Это хорошо. Потому что мы их больше не продаем ».

«Но я думал, ты только что сказал…»

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

«Да, в этом есть большой смысл».

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

«Дай угадаю. Вы их больше не продаете ».

"Неа. Конечно нет. Оказывается, люди не хотят строить целую фабрику только для того, чтобы произвести пару молотов. Предоставьте заводское строительство специалистам по заводскому строительству, я всегда так говорю!! »

«И я бы с тобой согласился».

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

«Ну, на самом деле это не так ...»

«Я знаю, что ты собираешься сказать !! … И мы их больше не продаем. По какой-то причине не так много людей покупали фабрики по производству молотов, поэтому мы придумали новое решение проблемы ».

"Ага."

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

«Да, без шуток».

«Итак, на этой неделе мы представляем универсальную фабрику по производству инструментов, чтобы все ваши различные фабрики по производству инструментов могли производиться на одной объединенной фабрике. Фабрика-фабрика-фабрика будет производить только те инструментальные фабрики, которые вам действительно нужны, и каждая из этих фабрик-фабрик будет производить одну-единственную фабрику на основе ваших индивидуальных спецификаций инструмента. Окончательный набор инструментов, который появится в результате этого процесса, станет идеальным инструментом для вашего конкретного проекта. У вас будет именно молоток, который вам нужен, и именно та рулетка, которая идеально подходит для вашей задачи, и все это одним нажатием кнопки (хотя вам также, возможно, придется развернуть несколько файлов конфигурации, чтобы все это работало в соответствии с вашими ожиданиями."

«Так у вас нет молотков? Вовсе нет?"