# БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее Красивые диаграммы Арт ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision / Концепция АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ Типы интеграции SOA Solution Design DDD Микросервисы и service mesh ESB DevOps CI/CD/CDP VM и Docker Оценка задачи git Frontend HTTP/REST Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тест-анализ Тестирование требований Тест план Тест дизайн XPATH Безопасность Нагрузочное Android Автоматизация Selenium Генератор ИНН ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro
Эта страница:
Почерпнуть мудрость Суть CI/CD/CDP QG (Quality Gates) Уровень квалификации VM и Docker Оценка "величины" задачи OOP - базис Распространённые ошибки
Ещё в этом разделе:
DevOps Frontend HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows Linux
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
DevOps
last update: 16-07-2020, 13:23
Все балаганы с картинками и фасилитаторами заканчиваются в тот момент, когда насладившийся картинками и фасилитированным общением начальник уходит, и оставшимся инженерам надо, наконец, заняться настоящим мышлением, то есть выдать на-гора реально сложный работающий продукт.
Красивый и захватывающий процесс легко подменяет результат.
Конечно, инженеры, которых учили думать, работают не так, как об этом рассказывают опирающиеся на картинки люди из движения design-thinking.
Почерпнуть мудрость

Разное

Интерфейсы

Суть CI/CD/CDP
(скачать схему в XML-формате draw.io)

Основная идея CI/CD/CDP = создание автоматизированного конвейера поставки продукта заказчику/потребителю за счёт автоматизации:

  1. чекина изменений в репозиторий
  2. статического анализа кода: на уязвимости, на соответствие требованиям/стандартам
  3. компиляции и формирования билда (сборки)
  4. всех необходимых тестов (unit, smoke, acceptance, regression, integration, end-to-end)
  5. заведения в СУП issue в случае ошибок
  6. обратной связи об успехе/неудаче в виде отчётов о билде и уведомлений по выбранным каналам
  7. слияния изменений с основной веткой в случае "зелёных" тестов
  8. деплоя на dev/test/staging/prod

Continuous integration, CI = автоматизированная интеграция программного кода в существующий проект в репозитории с последующей компиляцией, формированием сборки и прогоном базовых автотестов.
Считается, что должно занимать <= 10 минут.

Сontinuous delivery, CD = CI + автоматизированная поставка готовой сборки ПО с изменениями на сервера разработки и тестирования с прогоном автотестов.

Сontinuous deployment, CDP = CD + автоматизированное развёртывание изменений в Пром.

Всё это счастье достигается посредством использования таких инструментов как, например, GitLab CI, BitBucket Pipelines, AWS CodeBuild, Bamboo, TeamCity, Jenkins и сильно облегчающей деплои контейнеризации (Docker).

QG (Quality Gates)
Из статьи Кто ответит в agile за качество разработки сложных проектов, или методология Quality Gates:
Уровень квалификации

Junior -- тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.

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

Senior -- автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.

VM и Docker
Что почитать на тему:

Разница между Виртуальной машиной и Контейнером

(скачать схему в XML-формате draw.io)

Примеры решений контейнеризации

  • Облачные решения:
    • Amazon AWS ECS
    • Azure Container Service (ACS)
  • On-premise решения:
    • Docker
    • Kubernetes
  • Оркестрация:
    • Docker Engine API
    • Kubernetes
    • Azure Service Fabric
  • Самописное решение:
    1. API-контейнеризация + ручная автоматизация
Оценка "величины" задачи

Метод трёх точек (3-point estimation)

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

WM = (O + 4*BG + P) / 6
О (opitimistic) - оптимистичное время выполнения задачи, если все пойдет хорошо, т.е. если не наступит ни один из выявленных и зафиксированных рисков.
BG (best guess) - наиболее вероятное время, или средняя продолжительность выполнения аналогичной задачи, при условии выполняли её уже много раз.
Р (pessimistic) - пессимистичное время выполнения задачи, если сработали все выявленные риски.
WM (weighted mean) - взвешенное значение с учетом рисков и последствий воздействия негативных и позитивных факторов.
SD (standard deviation) - стандартное отклонение, используемое для расчета вероятностей.

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

Чего позволяет добиться метод трёх точек:

  • Точности (используется 3 оценки вместо одной)
  • Повышения ответственности членов команды за оценку, поскольку они должны учитывать риски
  • Получить описание рисков в каждой задаче

Кастомный метод для T-Shape оценки "размера" задачи

Связан с методологией Kanban.
Набросокъ:
"Размер" задачи Затрагиваемые Бизнес-процессы Потребность в степени вовлечения Заказчика и сторонних стейкхолдеров Объект доработки - тип компонента ПО
L (список наиболее суровых развестистых бизнес-процессов) высокая
(почти ничего не известно, размытые бизнес-требования, требуется информация от контрагентов)
  • Интерфейсы (интеграция с новыми Системами)
M (список бизнес-процессов "средней руки") средняя
(уже есть вопросы, чуются подводные камни в бизнес-требованиях, нет чётких кейсов воспроизведения ошибки)
  • данные (в БД, файлах)
  • формы GUI
  • интерфейсы (интеграция с другими Системами)
  • периодические задания (SSIS-пакеты, job'ы, cron'ы)
  • вспомогательные (плагины, хранимые процедуры SQL)
S (список коротких прямолинейных бизнес-процессов) минимальная
(уже всё понятно, и нам сообщено, есть чёткий кейс воспроизведения ошибки)
  • сообытийные процедуры для форм GUI
  • те или иные отчёты
  • подсистема управления правами

Размер задачи оценивать в максимальный из получившихся оценённых параметров, например:
У нас есть

  • предполагаются изменения в БП = Регистрация Клиента (S)
  • но потребность в вовлечении заказчика = средняя (M)
  • и объект доработки = форма GUI, событийные процедуры для форм GUI, данные (M)
, значит оцениваем задачу как М.

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

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

OOP - базис

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

Инкапсуляция = свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе. Некоторые языки (например, С++) отождествляют инкапсуляцию с Сокрытием, но большинство (Smalltalk, Eiffel, OCaml) различают эти понятия.
Инкапсуляция обеспечивается следующими средствами:

  • Контроль доступа. Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные внутри класса и из классов-потомков, и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках.
  • Методы доступа. Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access - доступ), а по отдельности - геттерами (англ. get - чтение) и сеттерами (англ. set - запись)

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

Полиморфизм подтипов (иногда просто - "полиморфизм") = свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Класс - универсальный, комплексный (составной) тип данных, состоящий из тематически единого набора:

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

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

Распространённые ошибки
  1. неосмысленные имена переменных;
  2. проверка наиболее возможной ситуации находится в конце списка проверок;
  3. отсутствие проверки "если ничего из указанного";
  4. отсутствие валидации параметров метода в самом начале метода;
  5. отсутствие валидации данных до выполнения операции с данными в БД типа update/insert (не отлавливаются пустые значения,..);
  6. обращение в БД с запросами вида "select * from A" (возвращает очень много данных);
  7. неоправданное и неаргументированное время жизни при использовании кэшей;
  8. ошибки с правами доступа (пароли лежат где-то в открытом виде,..);
  9. глобальные константы в коде классов;
  10. куча одинаковых(очень похожих) кусков кода не вынесены в функции;
  11. использование функции, когда не полностью известно(понятно) её предназначение и принцип работы (например, использование функции округления, не интересуясь в какую сторону она округлит);
  12. отсутствие комментариев на сложных участках;
  13. подключать/использовать библиотеки/функции дублирующие функционал друг друга, когда можно было бы обойтись чем-то одним из арсенала;
  14. оставлять в коммите код, использовавшийся для дебага (может тормозить систему, заполняет логи лишней информацией);
  15. размещение сложных условий в одну строку (нечитабельно, например t = y && p &&!q&&(!!l)?k?m:n :0);
    Никогда не пишите длинных if-ов
  16. при переборе массивов, особенно двумерных, каждый раз использовать обращение к элементу массива, а не присвоить его значение какой-нибудь переменной и работать с ней в пределах, даёт существенный прирост скорости в часто выполняемых операциях в том числе с клиентской стороны при обхода DOM-дерева, иначе каждый раз у элемента верхнего будет искаться наследник и так далее.
Технологический налог