Разница между Continuous Delivery и Continuous Deployment
Continuous Integration (CI) — непрерывная интеграция, это практика разработки программного обеспечения, при которой члены команды часто интегрируют свою работу. Интеграция это слияние новой версии кода со стабильной и проверка, что при этом ничего не сломалось. Следуя этой практике, обычно, каждый сотрудник интегрирует изменения по крайней мере ежедневно, что приводит к нескольким интеграциям в день. Каждая интеграция проверяется автоматизированной сборкой (включая тестирование), чтобы как можно быстрее обнаружить ошибки интеграции. Многие команды пришли к выводу, что такой подход приводит к значительному сокращению проблем интеграции и позволяет команде быстрее разрабатывать целостное программное обеспечение. Подробнее можно почитать у Мартина Фаулера. В современном IT многие знакомы с CI, но мало кто знает, что скрывается за аббревиатурой CD.
Собеседуя Ops’ов в OneTwoTrip, среди прочего я спрашивал что такое CI, а потом что такое CD. Не смотря на то, что зачастую люди могли дать какой-либо вразумительный ответ, почти никто не мог рассказать разницу между Continuous Delivery и Continuous Deployment. Я и сам постоянно забываю правильный ответ, поэтому решил написать эту заметку. Для кого-то это может быть критично, например если на собеседовании вам попадется такой же поехавший как я.
Разница между Continuous Delivery и Continuous Deployment очень маленькая. Представим два пайплайна для одного и того же приложения. В каждом есть шаги:
- Source Control — внесение изменений в систему контроля версий ПО
- Build — сборка приложения и прогон unit тестов
- Staging — деплой на тестовое окружение, прогон интеграционных, нагрузочных и других тестов
- Production — деплой на окружение с пользователями
Каждый пайплайн запускается автоматически по триггеру из системы контроля версий. В случае Continuous Deployment каждый следующий шаг, будет выполнен автоматически если предыдущий был успешный, включая деплой на Production.
Если же у вас Continuous Delivery, то шаги будут выполняться автоматически только в безопасной среде, а перед деплоем на Production пайплайн остановится и будет ждать ручного подтверждения. Механизм, как это будет реализовано может быть разным. От самого простого, когда ответственный человек должен зайти в пайплайн и нажать кнопку Next, до интерактивного бота с кнопками в корпоративном мессенджере.
Зачем нужен ручной апрув перед деплоем на Production, ведь это тормозит пайплайн т.е. доставку фич и исправлений багов? Вопрос резонный, но ответ такой же. Не все проекты одинаковые, есть такие в которых решение о деплое на Production должно быть принято человеком ответственно и осознанно. Когда бизнес сложный, с большим количеством факторов и нельзя переложить выбор “деплоить или нет” на пару алгоритмических критериев, тогда и применяется Continuous Delivery, а не Continuous Deployment.
Для простоты я сделал специальную диаграмму, она доступна по короткой ссылке doam.ru/cdvscd.
#DevOps #CI/CD
- Поблагодарить автора
- Telegram канал
Что такое CI/CD?
CI/CD, или «непрерывная интеграция/непрерывная доставка» либо «непрерывное развертывание», — это методика разработки программного обеспечения, реализуемая благодаря инструментам автоматизации. Регулярные и надежные обновления уменьшают циклы выпуска за счет непрерывной доставки кода.
Всё о CI/CD
CI/CD является собирательным термином, охватывающим несколько этапов DevOps. CI (непрерывная интеграция) — это способ интеграции изменений кода в репозиторий по несколько раз в день. У CD есть два значения: непрерывная доставка автоматизирует интеграцию в то время, как непрерывное развертывание автоматически выпускает финальную сборку для конечных пользователей. Регулярное тестирование в рамках CI/CD уменьшает количество ошибок и дефектов кода, что делает эту методику незаменимой для рабочего процесса DevOps.
- Непрерывная интеграция (CI)
- Непрерывная интеграция (CI)
- Непрерывная интеграция (CI)
- Непрерывная доставка
- Чем отличаются DevOps и CI/CD?
Непрерывная интеграция (CI)
CI — это методика DevOps и этап жизненного цикла DevOps, на котором разработчики регистрируют код в общем репозитории кода, часто по несколько раз в день. Желательно, чтобы каждый раз автоматический инструмент сборки проверял изменение или ветку на наличие ошибок и готовность к разработке. Отсюда и главное преимущество — проблемы выявляются на ранних этапах еще до того, как приведут к неприятным последствиям.
Реализация CI подразумевает интеграцию маленьких подгрупп изменений в компактные сроки вместо менее частых обновлений существенного объема, которые занимают больше времени. Благодаря автоматизации процессов тестирования, слияния и регистрации изменений в общем репозитории команды разработчиков могут ускоренно доставлять более читаемый код. Легкая читаемость кода позволяет быстрее проходить этап проверки, выпускать более стабильный продукт и повышать эффективность процесса разработки за счет упрощенного масштабирования.
Непрерывная интеграция (CI)
CI — это методика DevOps и этап жизненного цикла DevOps, на котором разработчики регистрируют код в общем репозитории кода, часто по несколько раз в день. Желательно, чтобы каждый раз автоматический инструмент сборки проверял изменение или ветку на наличие ошибок и готовность к разработке. Отсюда и главное преимущество — проблемы выявляются на ранних этапах еще до того, как приведут к неприятным последствиям.
Реализация CI подразумевает интеграцию маленьких подгрупп изменений в компактные сроки вместо менее частых обновлений существенного объема, которые занимают больше времени. Благодаря автоматизации процессов тестирования, слияния и регистрации изменений в общем репозитории команды разработчиков могут ускоренно доставлять более читаемый код. Легкая читаемость кода позволяет быстрее проходить этап проверки, выпускать более стабильный продукт и повышать эффективность процесса разработки за счет упрощенного масштабирования.
Непрерывная интеграция (CI)
CI — это методика DevOps и этап жизненного цикла DevOps, на котором разработчики регистрируют код в общем репозитории кода, часто по несколько раз в день. Желательно, чтобы каждый раз автоматический инструмент сборки проверял изменение или ветку на наличие ошибок и готовность к разработке. Отсюда и главное преимущество — проблемы выявляются на ранних этапах еще до того, как приведут к неприятным последствиям.
Реализация CI подразумевает интеграцию маленьких подгрупп изменений в компактные сроки вместо менее частых обновлений существенного объема, которые занимают больше времени. Благодаря автоматизации процессов тестирования, слияния и регистрации изменений в общем репозитории команды разработчиков могут ускоренно доставлять более читаемый код. Легкая читаемость кода позволяет быстрее проходить этап проверки, выпускать более стабильный продукт и повышать эффективность процесса разработки за счет упрощенного масштабирования.
Непрерывная доставка
За CI следует непрерывная доставка — своего рода контрольный этап в процессе разработки перед выпуском и развертыванием итогового продукта для пользователей. После подтверждения изменения кода автоматически доставляются в репозиторий.
Цель непрерывной доставки заключается в том, чтобы доставлять наборы изменений в главную сборку маленькими порциями, которые не нарушат статус «готово к коммерческому использованию» итогового продукта, не готового к выпуску. Готовый продукт может содержать небольшие ошибки, которые, тем не менее, не смогут поставить под угрозу удобство использования.
Реализация непрерывной доставки подразумевает, что разработчики будут тратить меньше времени на внутреннее тестирование, так как согласно этой методике до этапа доставки по определению доходит только стабильный код. Это упрощает процесс выявления ошибок и сокращает время на их исправление.
Чем отличаются DevOps и CI/CD?
DevOps является культурой и процессом, нацеленным на повышение эффективности разработки программного обеспечения.
Конвейер CI/CD — это определенная цепочка этапов, связанная с инструментами и средствами автоматизации, на основе которых реализуется жизненный цикл DevOps. Хотя CI/CD и является неотъемлемой частью культуры DevOps, последняя гораздо шире охватывает жизненный цикл разработки программного обеспечения: от сотрудничества межу разработчиками и структуры команд до мониторинга, контроля версий и т. д.
У разных компаний способ внедрения DevOps может сильно отличаться, но по своей сути DevOps невозможно реализовать без CI/CD. Конвейер CI/CD неразрывно связан с культурой DevOps и ее процессами небольших частых выпусков.
Непрерывная интеграция, поставка или развертывание
В контексте современных методов разработки и DevOps часто используются аббревиатуры CI и CD. Аббревиатура CI означает непрерывную интеграцию. Это фундаментальная рекомендация DevOps, согласно которой разработчики должны регулярно проводить слияние изменений кода в центральном репозитории, где выполняются автоматизированные сборки и тесты. Аббревиатура CD может означать как непрерывную поставку, так и непрерывное развертывание.
В чем разница между непрерывной интеграцией, непрерывной поставкой и непрерывным развертыванием (CI/CD)?
Непрерывная интеграция
Разработчики, применяющие непрерывную интеграцию, при каждой возможности выполняют слияние своих изменений с основной веткой. Изменения, внесенные разработчиком, проверяются путем создания сборки и запуска автоматических тестов на этой сборке. С таким подходом вы избегаете сложностей при интеграции, когда нужно ждать дня релиза, чтобы выполнить слияние изменений в соответствующей ветке.
При использовании непрерывной интеграции уделяется большое внимание автоматизации тестирования, в результате которого при интеграции новых коммитов в основную ветку работа приложения не нарушается.
Непрерывная поставка
Непрерывная поставка является продолжением непрерывной интеграции, поскольку при ней происходит автоматическое развертывание всех изменений кода в тестовой и (или) рабочей среде после этапа сборки.
Это значит, что автоматизирован не только процесс тестирования, но и процесс выпуска продукта, поэтому приложение можно развернуть в любое время одним нажатием.
Теоретически при непрерывной поставке вы можете выпускать релизы ежедневно, еженедельно, каждые две недели или с любой другой периодичностью, актуальной для бизнеса. Однако если вы действительно хотите получить преимущества от непрерывной поставки, следует выполнять развертывание в рабочей среде как можно раньше, обеспечивая выпуск небольших пакетов изменений, в которых легко найти ошибку в случае проблем.
См. решение
Разработка и эксплуатация программного обеспечения с помощью Open DevOps
Связанные материалы
Что такое конвейер DevOps?
Непрерывное развертывание
Непрерывное развертывание идет на один шаг дальше, чем непрерывная поставка. При этом подходе каждое изменение, которое проходит все стадии производственного конвейера, выпускается для клиентов. Вмешательство человека не требуется, и развертыванию нового изменения в рабочую среду может помешать только ошибка во время теста.
Непрерывное развертывание — это отличный способ ускорить цикл обратной связи с клиентами и избавить команду от лишнего напряжения, отменив «день релиза». Разработчики могут сосредоточиться на создании ПО. Они видят, как их код запускается в работу за считанные минуты, стоит только закончить.
Как эти подходы взаимосвязаны друг с другом
Проще говоря, непрерывная интеграция является частью как непрерывной поставки, так и непрерывного развертывания. А непрерывное развертывание похоже на непрерывную поставку, за исключением того, что релизы выполняются автоматически.
Каковы преимущества каждого из подходов?
What are the benefits of each practice?
Мы объяснили разницу между непрерывной интеграцией, непрерывной поставкой и непрерывным развертыванием, но еще не рассмотрели причины, по которым стоит внедрять эти подходы. Очевидно, что внедрение каждого из них требует расходов, но это в значительной степени оправдывается получаемыми преимуществами.
Непрерывная интеграция
Что от вас потребуется (расходы)
- Вашей команде придется писать автоматические тесты для каждой новой функции, улучшения или баг-фикса.
- Необходим сервер непрерывной интеграции, который может отслеживать основной репозиторий и автоматически запускать тесты для каждого нового отправленного коммита.
- Разработчикам необходимо выполнять слияние своих изменений как можно чаще, как минимум один раз в день.
Что вы получите
- В рабочую среду попадает меньше багов, поскольку за счет автоматических тестов ухудшения обнаруживаются на ранних этапах.
- Когда все проблемы интеграции решаются на ранних этапах, сборка релиза проходит легко.
- Переключаться на другой контекст приходится реже, так как разработчики получают предупреждение сразу же, как только нарушат сборку, и могут поработать над исправлением, прежде чем перейти к другой задаче.
- Радикально снижаются затраты на тестирование: ваш CI‑сервер может выполнять сотни тестов за несколько секунд.
- Команда контроля качества тратит меньше времени на тестирование и может сосредоточиться на повышении культуры качества.
Непрерывная поставка
Что от вас потребуется (расходы)
- Для непрерывной интеграции нужна прочная основа. Ваш комплект тестов должен покрывать достаточную часть базы кода.
- Развертывания необходимо автоматизировать. Хотя запуск все еще осуществляется вручную, после начала развертывания вмешательство человека требоваться не должно.
- Скорее всего, вашей команде понадобится освоить флаги возможностей, чтобы возможности, работа над которыми не завершена, не влияли на работу клиентов.
Что вы получите
- Отныне развертывание ПО перестало быть сложным. Вашей команде больше не нужно тратить несколько дней на подготовку к релизу.
- Можно чаще выпускать релизы, ускоряя цикл обратной связи со своими клиентами.
- Решения по поводу небольших изменений принимаются без лишнего напряжения, что способствует ускорению итераций.
Непрерывное развертывание
Что от вас потребуется (расходы)
- Ваша культура тестирования должна быть на самом высоком уровне. Качество вашего комплекта тестов будет определять качество ваших релизов.
- Процесс документирования должен идти в ногу с темпами развертываний.
- Флаги возможностей становятся неотъемлемой частью процесса выпуска серьезных изменений. Они обеспечивают возможность координировать работу с другими отделами (такими как поддержка, маркетинг, PR и т. д).
Что вы получите
- Вы сможете ускорить процесс разработки, так как вам не нужно будет прерывать его на время релизов. Конвейеры развертывания срабатывают автоматически при каждом внесении изменений.
- Сокращается количество рисков, связанных с релизами, и облегчается выпуск фиксов в случае появления проблем, поскольку каждое развертывание осуществляется после внесения сравнительно небольшого количества изменений.
- Клиенты видят непрерывный поток улучшений, при этом качество повышается каждый день, а не раз в месяц, квартал или год.
Традиционно одной из статей расходов, связанных с непрерывной интеграцией, является установка и обслуживание сервера CI. Однако можно значительно сократить расходы на внедрение этих подходов, используя облачный сервис, например Bitbucket Pipelines, который добавляет возможности автоматизации в каждый репозиторий Bitbucket. Просто добавив файл конфигурации в корень репозитория, можно создать конвейер непрерывного развертывания, который будет выполняться для каждого нового изменения, отправляемого в основную ветку.
Переход от непрерывной интеграции к непрерывному развертыванию
Если вы только начинаете работу над новым проектом и у вас пока нет пользователей, вам может быть просто развертывать каждый коммит в рабочую среду. Можно даже начать с автоматизации развертываний и выпустить альфа-версию в рабочую среду без клиентов. Затем, по мере разработки приложения, вы будете повышать культуру тестирования и увеличивать покрытие кода. А к тому времени, когда вы будете готовы подключать пользователей, у вас выработается отличный процесс непрерывного развертывания, где все новые изменения тестируются перед их автоматическим выпуском в рабочую среду.
Но если у вас уже есть приложение, которым пользуются клиенты, стоит притормозить и начать с непрерывной интеграции и непрерывной поставки. Начните с внедрения базовых модульных тестов, которые запускаются автоматически. На данном этапе еще рано фокусироваться на сложном сквозном тестировании. Вместо этого нужно постараться как можно скорее автоматизировать развертывания и перейти к этапу, на котором развертывания в промежуточные среды будут выполняться автоматически. Когда вы наладите автоматические развертывания, можно будет сосредоточиться на совершенствовании тестов, вместо того чтобы периодически делать остановки для координации процесса выпуска.
Как только выпуск ПО начнет происходить ежедневно, можно будет рассматривать возможность непрерывного развертывания. Однако перед этим необходимо убедиться, что к такому повороту готова и остальная часть вашей организации: документация, поддержка, маркетинг. Эти подразделения тоже должны адаптироваться к новой частоте выпуска релизов. Важно организовать процесс так, чтобы они не пропускали значительных изменений, которые могут повлиять на клиентов.
Cdl cdp что это
DevOps = красивое название для ПРОЦЕССОВ активного взаимодействия разработчиков с администраторами (БД и систем) и автоматизаторами тестирования , которые (процессы) максимально стандартизированы с помощью договорённостей в командах и обеспеченностью сред для разработки и автоматизированы за счёт использования специальных инструментов поставки, прогона тестов, развёртывания.
- ускорения и упрощения оргпроцедур по получению техники для разработчика с уже установленной или быстро устанавливаемой/обновляемой IDE и другого необходимого инструментария, а также по получению необходимых сетевых доступов с рабочих станций.
- упрощения и ускорения процедур по выделению и масштабированию мощностей для стендов, необходимых для развёртывания ПО и его тестирования
, обычно за счёт использования облачных решений (Amazon AWS, Google Cloud, Microsoft Azure, SberCloud, Yandex.Cloud) - использования средств автоматизации операций для всего процесса поставки (Jenkins, TeamCity, рукописные скрипты)
- использования средств виртуализации и контейнеризации (Docker, Kubernetes)
- внедрения практики CI/CD/CDP и неизбежно с ней связанной автоматизацией тестов (unit, API, web-API, regress)
- внедрения решений по мониторингу как целых стендов, так и отдельных хостов, ВМ, веб-сервисов и приложений
- перехода на микросервисную архитектуру и service mesh с автотестированием контрактов многочисленных API (особенно если используется модный сейчас gRPC, например-например)
N.B. В повседневности словом devops чаще обозначают РОЛЬ администратора, который сопровождает стенды разработки и тестирования, управлением всеми этими средствами автоматизации поставки CI/CD/CDP (см. ниже).
Суть CI/CD/CDP
- чекина изменений в репозиторий;
- статического анализа кода: на уязвимости, на соответствие требованиям и стандартам;
- компиляции и формирования билда (сборки);
- передачи обратной связи об успехе/неудаче билда в виде уведомлений по выбранным каналам;
- деплоев на dev / test / staging / prod;
- всех необходимых тестов (unit, smoke, acceptance, regression, integration, end-to-end);
- заведения issue в СУП в случае ошибок;
- слияния изменений с нужной веткой в случае «зелёных» тестов.
VM и Docker
- Основы Docker. Большой практический выпуск (Артем Матяшов , 2020). Отлично разъясняет суть Docker, демонстрирует практические примеры.
- Основы Kubernetes
Суть
Контейнер = набор процессов, изолированный от остальной ОС, и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы (runtime & supporting files). Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.
- Виртуализация обеспечивает одновременную работу нескольких операционных систем на одном компьютере;
- Контейнеры используют одно и то же ядро операционной системы и изолируют процессы приложения от остальной системы.
Разница между Виртуальной машиной и Контейнером
Примеры решений контейнеризации
- Облачные решения:
- Amazon AWS ECS
- Azure Container Service (ACS)
- Docker
- Kubernetes
- Docker Engine API
- Kubernetes
- Azure Service Fabric
Поясняющая схемка OS, Istio, k8s
Поясняющая схемка некоторых сущностей Openshift, Istio, k8s для себя.
Доразобраться с Route и Gateway.
Аутентификация к API OS через curl
- Делаем запрос на получение OAuth token, используя, например, basic-аутентификацию OS User’ом curl -X GET «https://master-address:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token» -H «Content-Type: application/json» -H «X-CSRF-Token: XXX» -u [username] -ikL
- Из ответа из header’а < Location: https://10.64.33.43:8443/oauth/token/implicit#access_token=TOKENSCHMOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer берём значение TOKENSCHMOKEN (можно сразу grep'ать вместе с запросом выше), это и будет наш Bearer-токен для последующих запросов к API OS.
- Выполняем нужный нам запрос, например почитать yaml какого-то Deployment’а curl -X GET «https://api.master-address:8443/apis/apps/v1/namespaces/[namespace]/deployments/[deployment]» -H «Content-Type: application/json» -H «Authorization: Bearer TOKENSCHMOKEN» -ik , и в ответе получаем искомый yaml.
- GitHub Gist — tuxfight3r’s curl notes — openshift rest api login / json patch via curl
- OpenShift documentation — Architecture — Additional Concepts — Authentication
- OpenShift documentation — AIP reference — apps — Deployment
Контракты API
API = application programming interface = опубликованный программный интерфейс компонента/системы, позволяющий другим компонентам/системам получать доступ к какой-либо функции.
- Функциональная (сигнатура и семантика):
- Название API
- Входные данные / параметры вызова (протокол, URI)
- Возвращаемые данные
- Семантика (описание функциональности)
- Шаблон интеграционного взаимодействия
- Потребитель
- Нефункциональная ( SLA ):
- Доступность (availability, %)
- Время ответа (latency, ms) = время, необходимое приложению, чтобы ответить на запрос
- Пропускная способность (throughput, transactions per second, tps) = количество транзакций (запросов), которое приложение может обработать в течение секунды
- Какие-либо ограничения (по размеру сообщения, безопасности и т.п.)
Обычно контракты API ведут как в Confluence, так и в специальных системах — реестр API.
CDC (Consumer Driven Contract)
CDC (Consumer Driven Contract) = контракт потребителя сервиса.
Представляет из себя соглашение между сервисом-поставщиком и сервисом-потребителем в том, что
сервис-поставщик обязуется уметь принимать на вход от сервиса-потребителя определённую структуру данных определённых типов, сериализованную JSON/XML/binary/.
и гарантирует возвращать в ответ определённую структуру данных определённых типов, также сериализованную.
CDC фокусируется на поведении и данных, которые важны Потребителю, т.е. требования исходят от Потребителя: мне нужно вот это.
- OpenAPI для Swagger
- WSDL для SOAP
- WADL для REST HTTP сервисов
- Protocol Buffers для gRPC
Этот подход когда-то реализован в виде WSDL/WADL-сервисов
, развивался для REST HTTP в виде, например, OpenAPI с его .yaml-файлами контрактов ( Contract-First API Development with OpenAPI Generator and Connexion)
, а сейчас его популярность сильно возросла в связи с активным продвижением gRPC и его .proto-файлами контрактов (статьи GRPC сервис на примере генератора паролей и gRPC — фреймворк от Google для удалённого вызова процедур)- Пирамида тестов на практике # Контрактные тесты
- Consumer Driven Contracts глазами разработчика
- Consumer Driven Contracts — HTTP-REST контрактные тесты на Java & Spring & Gradle/Maven
Оценка задач
Метод трёх точек (3-point estimation)
Метод для расчёта временных затрат в проектах с уникальными задачами в условиях неопределённости и при наличии нескольких типов рисков. Используется в IT достаточно широко.
Для того, чтобы начать применять этот метод, нужно проанализировать предмет доработки и описание реализации. Попытаться провести аналогии с ранее выполненными задачами с похожим скоупом. Определить риски и описать мероприятия по устранению этих рисков (что делаем, если сработал тот или иной риск).
WM = (O + 4*BG + P) / 6
О (opitimistic) — оптимистичное время выполнения задачи, если все пойдет хорошо, т.е. если не наступит ни один из выявленных и зафиксированных рисков.
BG (best guess) — наиболее вероятное время, или средняя продолжительность выполнения аналогичной задачи, при условии выполняли её уже много раз.
Р (pessimistic) — пессимистичное время выполнения задачи, если сработали все выявленные риски.
WM (weighted mean) — взвешенное значение с учетом рисков и последствий воздействия негативных и позитивных факторов.
SD (standard deviation) — стандартное отклонение, используемое для расчета вероятностей.Как видим, суть метода сводится к тому, что мы предполагаем, что с вероятностью 4/6 всё пойдёт так, как было и ранее в подобных случаях, с учётом менее вероятных (по 1/6) отклонений в стороны «всё будет плохо» и «всё пройдёт идеально».
- Точности (используется 3 оценки вместо одной)
- Повышения ответственности членов команды за оценку, поскольку они должны учитывать риски
- Получить описание рисков в каждой задаче
Метод «Объём неясен, дам заведомо большую оценку, поторгуемся»
Суть в том, что по некоторым задачам ты вроде бы не знаешь даже примерно сколько она займёт трудозатрат, но готов назвать запредельно большую оценку (чувствуешь в ней внутреннюю уверенность, хоть и боязно произнести), за которую вы уж точно сделаете, но которая точно не понравится вопрошающему (заказчику работ).
Что это даёт — это выкладывает на стол переговоров повод для торга «ты мне уточнение входных данных, я тебе уточнение оценки».
Например, «Слушай, я не знаю во сколько её оценить, давай на все непонятные CR напишем по 500 часов, потом поторгуемся с возмущённым Клиентом, пусть разъяснит».Кастомный метод для T-Shape оценки «размера» задачи
- Интерфейсы (интеграция с новыми Системами)
- данные (в БД, файлах)
- формы GUI
- интерфейсы (интеграция с другими Системами)
- периодические задания (SSIS-пакеты, job’ы, cron’ы)
- вспомогательные (плагины, хранимые процедуры SQL)
- сообытийные процедуры для форм GUI
- те или иные отчёты
- подсистема управления правами
- предполагаются изменения в БП = Регистрация Клиента (S)
- но потребность в вовлечении заказчика = средняя (M)
- и объект доработки = форма GUI, событийные процедуры для форм GUI, данные (M)
Что делаем: оцениваем задачи таким образом, некоторое время накапливаем статистику по времени выполнения оценённых таким образом задач, а далее при планировании мы уже на этапе такой оценки будем знать, что задача L скорее всего будет выполняться за X дней и т.п.
Потенциал для совершенствования: если суммируются несколько признаков одного уровня (например, объекты доработки), то оценка по этому признаку уходит на уровень выше.
Во фронт или в бэк?
- (валидация) проверка что в форму для числа введено число, а не срока — это чистый фронт;
- (верификация) проверка по КЛАДР -однозначный бэк;
Уровень квалификации
Junior — тот, кого нельзя оставить без присмотра. Задачу надо разжевать, код придирчиво отревьюить, время от времени узнавать, как дела и поправлять на ходу. Выхлопа от работы джуна ожидать не стоит (т.е. времени он не сэкономит, скорее потратит), но на него можно сгрузить рутину и через некоторое время он подтянется и выхлоп будет.
Middle — работает работу сам. В задачах тоже разбирается сам, где не может, сам задаёт релевантные вопросы. Кроме ревью кода пригляда за ним не требуется, но и помощи в определении курса тоже не ожидается.
Senior — автономная боевая единица. Если в него кинуть размытой формулировкой проекта, то он её сам уточнит, ещё и укажет на слабые места и покритикует, подберёт рабочий стек технологий (без оглядки на хайп) и сам в одиночку всё запрограммирует (и за джунами присмотрит). Ещё и заказчика пнёт (возможно, через прокладку-менеджера, если таковая зачем-то есть), что тот ему ещё вчера обещал уточнения к ТЗ прислать.
OOP — базис
- Классы и фабрики. Как разобрать и собрать объект с наследованием на прототипах
- Factory, Singleton, Strategy, Front Controller
Объектно-ориентиированное программирование (ООП) = методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования/
- Контроль доступа. Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные внутри класса и из классов-потомков, и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках.
- Методы доступа. Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access — доступ), а по отдельности — геттерами (англ. get — чтение) и сеттерами (англ. set — запись)
Наследование = свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым, родительским или суперклассом. Новый класс — потомком, наследником, дочерним или производным классом.
Полиморфизм подтипов (иногда просто — «полиморфизм») = свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
- «полей» — переменных более элементарных типов;
- «методов» — процедуров и функций, связанных с классом, для работы с его полями. Они определяют действия, которые можно выполнять над объектом такого типа, и которые сам объект может выполнять. То есть он является моделью информационной сущности с внутренним и внешним интерфейсами для оперирования своим содержимым (значениями полей).
Объект — cущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса. Взаимодействие объектов в абсолютном большинстве случаев обеспечивается вызовом ими методов друг друга.
Распространённые ошибки
- неосмысленные имена переменных;
- проверка наиболее возможной ситуации находится в конце списка проверок;
- отсутствие проверки «если ничего из указанного»;
- отсутствие валидации параметров метода в самом начале метода;
- отсутствие валидации данных до выполнения операции с данными в БД типа update/insert (не отлавливаются пустые значения. );
- обращение в БД с запросами вида «select * from A» (возвращает очень много данных);
- неоправданное и неаргументированное время жизни при использовании кэшей;
- ошибки с правами доступа (пароли лежат где-то в открытом виде. );
- глобальные константы в коде классов;
- куча одинаковых(очень похожих) кусков кода не вынесены в функции;
- использование функции, когда не полностью известно(понятно) её предназначение и принцип работы (например, использование функции округления, не интересуясь в какую сторону она округлит);
- отсутствие комментариев на сложных участках;
- подключать/использовать библиотеки/функции дублирующие функциональность друг друга, когда можно было бы обойтись чем-то одним из арсенала;
- оставлять в коммите код, использовавшийся для дебага (может тормозить систему, заполняет логи лишней информацией);
- размещение сложных условий в одну строку (нечитабельно, например t = y && p &&!q&&(!!l)?k?m:n :0);
Никогда не пишите длинных if-ов - при переборе массивов, особенно двумерных, каждый раз использовать обращение к элементу массива, а не присвоить его значение какой-нибудь переменной и работать с ней в пределах, даёт существенный прирост скорости в часто выполняемых операциях в том числе с клиентской стороны при обхода DOM-дерева, иначе каждый раз у элемента верхнего будет искаться наследник и так далее.