По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Процесс анализа программного кода должен быть максимально автоматизирован. Когда вы создаете запрос на включение изменений, как минимум, вам нужно запустить модульные тесты и статический анализ программного кода в функциональной ветке. Средства автоматизации могут многое рассказать о качестве кода: метрики, покрытие кода модульными тестами, обнаружение дублированных строк и т.д.
Однако есть как минимум 50 вещей, которые нельзя проверить автоматически. Они нуждаются во внимательном взгляде опытного проверяющего (это дает нам хоть какую-то надежду на то, что роботы не заменят разработчиков в ближайшем будущем).
Требования
Программный код реализует все функциональные требования, которые необходимы заказчику?
Программный код удовлетворяет всем нефункциональным требованиям, таким как производительность и безопасность? Если нефункциональные требования не были упомянуты заказчиком, то этот вопрос необходимо уточнить у проектировщика или у самого заказчика.
Условия сопровождения
Помещены ли все интерфейсы, классы и т.д. на соответствующий прикладной уровень в соответствии с архитектурой
Onion/Clean
?
Не изобретаете ли вы колесо, когда пишете программный код? Можно ли его заменить чем-то, что уже существует и что предоставляет какая-либо сторонняя библиотека?
Есть ли уже реализованная логика или какие-то ее фрагменты в кодовой базе?
Правильно ли была выбрана область жизненного цикла для интерфейса и реализации в контейнере внедрения зависимостей?
Являются ли реализованные функции детерминированными (то есть всегда ли они выдают один и тот же результат для одних и тех же входных данных)?
Все ли зависимости явно внедряются через конструктор типов?
Есть ли сильная связанность между классами, которая может затруднить повторное использование кода?
Используются ли
объекты-значения
вместо элементарных типов данных для того, чтобы избежать проблемы одержимости элементарными типами?
Соответствуют ли реализованные компоненты, такие как функции, классы, интерфейсы и модули,
принципу единственной обязанностей
?
Расширяются ли существующие функциональные возможности при помощи декораторов, технологий аспектно-ориентированного программирования (принципа открытия-закрытия) или они модифицируются на месте?
Правильно ли реализованы механизмы синхронизации потоков при доступе к объектам-одиночкам в веб-приложениях?
Используются ли по возможности
неизменяемые типы данных
вместо изменяемых для того, чтобы избежать побочных эффектов?
Добавлена ли функция ведения журнала с верными
уровнями ведения протокола
в основные места кода, которые требуют отслеживания?
Производительность
Правильно ли были выбраны
структуры данных
? Например, используется ли структура Hashtable вместо массива, когда нужно часто искать значения, для того, чтобы избежать линейного поиска?
Распараллелены ли длительные операции между всеми доступными ядрами для того, чтобы использовать ресурсы компьютера максимально эффективного?
Выполняет ли программный код большое количестве
операций по выделению памяти
для объектов в куче, оказывая тем самым дополнительную нагрузку на программу сборки мусора?
Кэшируются
ли данные, которые были считаны из базы данных, локально или в удаленном кэше?
Сколько раз текущий код обращается к базе данных? Возможно стоит получить все данные за одно или несколько обращений?
Выполняет ли код все обращения к базе данных, ввод-вывод и другие блокирующие вызовы асинхронно?
Использует ли код
пул потоков
по максимуму вместо того, чтобы создавать новые потоки?
Правильно ли выбран баланс между
нормализацией
и
денормализацией
при создании дополнительных таблиц базы данных?
Правильно ли добавляются или исправляются индексы, если запрос на включение изменений содержит новые SQL-запросы?
Возникает ли
проблема с N+1 запросами
при извлечении данных из базы данных при помощи фреймворка ORM?
Установлен ли правильный уровень изоляции транзакций в хранимых процедурах?
Возвращают ли SQL-запросы избыточные данные из базы данных, которые не требуются для кода приложения? Используется ли что-то вроде
SELECT *
или что-то подобное?
Модульное и интеграционное тестирование
Полностью ли модульные тесты покрывают дополнительную логику?
При появлении исправлений в логике, появляются ли изменения в соответствующем модульном тесте?
Всегда ли все реализованные модульные или другие виды тестов ведут себя детерминировано? Например, приостанавливают ли они выполнение потока на какой-то определенный период времени перед утверждением (что по своей сути является ошибочным шаблоном)?
Все ли модульные тесты реализованы в соответствии с принципами
F.I.R.S.T.
?
Есть ли какие-либо признаки проблем в модульном тестировании, такие как проблемы с
логикой проверки условий
,
рулеткой с утверждениями
,
дублированием утверждений
и другие?
Добавлен ли интеграционный тест, как минимум, для happy-path-сценария (сценария счастливого пути) реализованной функции?
Все ли зависимости тестируемого объекта имитируются для того, чтобы модульный тест случайно не превратился в интеграционный и не выполнился быстрее положенного?
Изолированы ли модульные и интеграционные тесты друг от друга?
Конечные точки API
Выбираются ли HTTP-команды, такие как
GET, POST, PUT, DELETE
и другие, в соответствии с действием их конечной точки?
Отвечает ли каждая конечная точка API за выполнение лишь одной бизнес-операции? Или все же нескольких?
Возвращает ли конечная точка API правильный код состояния? Например, не возвращает ли она код 401 вместо 500 при несанкционированном запросе?
Сжимаются ли объемные ответы перед их отправкой вызывающей стороне?
Защищены ли конечные точки API политиками аутентификации и авторизации?
Позволяет ли API, который возвращает большой список объектов, фильтровать его и разбивать на страницы?
Является ли конечная точка API GET идемпотентной?
Используются ли имена существительные вместо глаголов в именах конечных точек API?
Критические изменения
Имеются ли в конечной точке API такие критические изменения, как переименование API, удаление или переименование его параметров?
Имеются ли критические изменения в полезных данных сообщения (в случае, если используется брокер сообщений), например, удаление или переименование его свойств?
Повлияют ли такие изменения в схеме базы данных, как удаление столбцов или таблиц, на другие службы системы?
Системная среда
Насколько загружен ЦП и сколько оперативной памяти потребляет код при выполнении запроса на включение изменений? Будет ли в средах, в которых будет развернут код (среда тестирования, среда приёмочного пользовательского тестирования, производственная среда), достаточно мощный процессор и достаточный объем оперативной памяти для эффективного выполнения кода?
Будет ли реализованная логика, алгоритмы, структуры данных и т.д. работать достаточно быстро на большом наборе данных, который может быть в производственной среде?
Документация
Была ли изменена документация для того, чтобы отразить новые изменения программного кода (документация API, документация по структуре, проектная документация)?
Создается ли тикет
технических недоработок
, если запрос на внесение изменений содержит неэффективный или «грязный» код, который сейчас невозможно перестроить из-за недостаточного количества времени?
Заключение
Количество пунктов, на которых проверяющий должен заострить свое внимание, зависит от конкретного проекта и даже от конкретного запроса на внесение изменений. Ваш с коллегами мозговой штурм (если вы примите во внимание вышеприведенные пункты) может значительно снизить риск того, что вы забудете о чем-то важно при анализе программного кода.
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 1974 года («Формальные требования к виртуализируемым архитектурам третьего поколения» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешная виртуализация должна обеспечивать такую среду, которая:
Эквивалента физическому компьютеру, поэтому доступ программного обеспечения к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
Обеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
По возможности эффективно выполняет операции непосредственно на базовых аппаратных ресурсах, включая ЦП.
Виртуализация позволяет разделить физические ресурсы вычислений, памяти, сети и хранилища («основополагающая четверка») между несколькими объектами. Каждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. Грамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой связи между средами. Виртуализация также позволяет создавать и запускать новые виртуальные машины почти мгновенно, а затем удалять их, когда они перестанут быть необходимыми.
Для больших приложений, поддерживающих постоянно меняющиеся бизнес-требования, возможность быстрого вертикального масштабирования с повышением или понижением производительности может означать разницу между успехом и неудачей. Адаптивность, которую предлагает виртуализация, позволяет скриптам добавлять или удалять виртуальные машины за считанные секунды, а не недели, которые могут потребоваться для покупки, подготовки и развертывания физического сервера.
Как работает виртуализация?
В невиртуальных условиях, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начиная с Кольца 0 (Ring 0) по Кольцо 3).
Как правило, только ядро операционной системы хоста имеет какой-либо шанс получить доступ к инструкциям, хранящимся в кольце под номером 0. Однако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызывая больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправлял запросы на такие ресурсы, как память и хранилище, на виртуализированные системы, эквивалентные им.
При работе в аппаратной среде без виртуализации SVM или VT-x все это выполняется с помощью процесса, известного как ловушка, эмуляция и двоичная трансляция. На виртуализированном оборудовании такие запросы, как правило, перехватываются гипервизором, адаптируются к виртуальной среде и возвращаются в виртуальную машину.
Простое добавление нового программного уровня для обеспечения такого уровня организации взаимодействия приведет к значительной задержке практически во всех аспектах производительности системы. Одним из успешных решений было решение ввести новый набор инструкций в ЦП, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позволяет гостевой ОС работать без какого-либо влияния на другие несвязанные операции.
На самом деле, при правильной реализации виртуализация позволяет большинству программных кодов работать как обычно, без каких-либо перехватов.
Несмотря на то, что эмуляция часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. В то время как виртуализация стремится разделить существующие аппаратные ресурсы между несколькими пользователями, эмуляция ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. Для этого требуется программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.
Эмуляция может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.
Согласно сложившимся представлениям, существует два класса гипервизоров: Type-1 и Type-2.
Bare-metal гипервизоры (исполняемые на «голом железе») (Type-1), загружаются как операционная система машины и – иногда через основную привилегированную виртуальную машину – сохраняют полный контроль над аппаратным обеспечением хоста, запуская каждую гостевую ОС как системный процесс. XenServer и VMWare ESXi – яркие примеры современных гипервизоров Type-1. В последнее время использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хотя раньше оно использовалось только для описания систем Type-1. Первоначально более общим термином, охватывающим все типы систем, был «Мониторы виртуальных машин». То, в какой степени люди используют термин «мониторы виртуальных машин» все это время, наводит меня на мысль, что они подразумевают «гипервизор» во всех его интерпретациях.
Гипервизоры, размещенные на виртуальном узле (Type-2) сами по себе являются просто процессами, работающими поверх обычного стека операционной системы. Гипервизоры Type-2 (включая VirtualBox и, в некотором роде, KVM) отделяют системные ресурсы хоста для гостевых операционных систем, создавая иллюзию частной аппаратной среды.
Виртуализация: паравиртуализация или аппаратная виртуализация
Виртуальные машины полностью виртуализированы. Иными словами, они думают, что они обычные развертывания операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. Поскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ОС, то они могут работать с готовыми немодифицированными программными стеками. Однако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмуляции занимало дополнительное время и циклы.
В случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хотя бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Эта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. На первых порах это позволяло гипервизорам PV достигать более высокой производительности для операций, требующих подключения к аппаратным компонентам.
Тем не менее, для того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ЦП, которая позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, связанное с ловушкой и эмуляцией, и в полной мере воспользоваться преимуществами аппаратных расширений и немодифицированных операций ядра программного обеспечения.
Также значительно повысить производительность виртуализации может последняя технология Intel – таблицы расширенных страниц (EPT – Extended Page Tables).
В связи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.
Аппаратная совместимость
Как минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ЦП хоста. Именно поэтому вы должны убедиться, что на вашем сервере есть все, что вам необходимо для задачи, которую вы собираетесь ему дать. Большая часть того, что вам нужно знать, храниться в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. Однако вам нужно знать, то искать, потому что флагов будет очень много.
Запустите эту команду, чтобы посмотреть, что у вас под капотом:
$ grep flags /proc/cpuinfo
Контейнерная виртуализация
Как мы уже видели ранее, виртуальная машина гипервизора – это полноценная операционная система, чья связь с аппаратными ресурсами «основополагающей четверки» полностью виртуализирована – она думает, что работает на собственном компьютере.
Гипервизор устанавливает виртуальную машину из того же ISO-образа, который вы загружаете и используете для установки операционной системы непосредственно на пустой физический жесткий диск.
Контейнер в свою очередь фактически представляет собой приложение, запускаемое из скриптообразного шаблона, которое считает себя операционной системой. В контейнерных технологиях, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые зависят от ядра хоста и представления аппаратных ресурсов «основополагающей четверки» (т.е. ЦП, ОЗУ, сеть и хранилище) для всего, то они делают.
Конечно, с учетом того, что контейнеры фактически являются изолированными расширениями ядра хоста, виртуализация Windows (или более старых или новых версий Linux с несовместимыми версиями libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Но эта технология обеспечивает невероятно простые и универсальные вычислительные возможности.
Перемещение
Модель виртуализации также позволяет использовать широкий спектр операций перемещения, копирования и клонирования даже из действующих систем (V2V). Поскольку программные ресурсы, определяющие виртуальную машину и управляющие ею, очень легко идентифицировать, то обычно не требуется очень много усилий для дублирования целых серверных сред в нескольких местах и для разных целей.
Иногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Большинство платформ предлагают единую операцию командной строки для перемещения гостей между хостами.
Перемещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.
Одним из важных компонентов установления соединения по протоколу SIP является протокол Session Description Protocol, или сокращенно SDP.
О протоколе SDP впервые заговорили в 1998 году в рамках опубликованного RFC2327. Спустя 8 лет, в 2006 году протокол претерпел некоторые изменения, которые были отображены в RFC4566.
Протокол SDP используется для установления соединения и согласования параметров передачи и приема аудио или видео потоков между оконечными устройствами. Наиболее важными параметрами обмена являются IP – адреса, номера портов и кодеки. Давайте разбираться?
Пример SDP
При установлении сессии SDP параметры передаются в рамках SIP – запросов. Давайте взглянем на один из таких запросов. В данном случае распарсим SIP INVITE, который прилетело на нашу IP – АТС Asterisk с помощью утилиты sngrep:
INVITE sip:74996491913@192.168.x.xxx:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 80.xx.yy.zz:5060;branch=z9hG4bK-524287-1-MThkZjMzNzMyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;rport
Via: SIP/2.0/UDP 80.xx.yy.zz:5077;branch=z9hG4bK-XXXXXXXXXXXXXXXX;rport=5077
Max-Forwards: 69
Record-Route: <sip:80.xx.yy.zz:5060;lr;transport=UDP>
Contact: <sip:80.xx.yy.zz:5077>
To: <sip:74996491913@80.xx.yy.zz>
From: <sip:7925XXXXXXX@80.xx.yy.zz>;tag=qdpxhe2avyyjcqfn.o
Call-ID: fb9909e8fYYYYYYYYYYYYYYYYYYYYYY
CSeq: 479 INVITE
Expires: 300
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
P-Asserted-Identity: <sip:7925XXXXXXX@80.xx.yy.zz>
Remote-Party-ID: <sip:7925XXXXXXX@80.xx.yy.zz>;party=calling
h323-conf-id: 4133864240-4217115111-2706418710-XXXXXXXXX
Portasip-3264-action: offer 1
cisco-GUID: 4133864240-4217115111-2706418710-XXXXXXXXX
Content-Length: 278
v=0
o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz
s=-
c=IN IP4 80.xx.yy.zz
t=0 0
m=audio 57028 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
В приведенном примере можно увидеть, что основная часть SIP – сообщения отделена от SDP сегмента пустой строкой. Помимо прочего, поле Content-Type, что сообщение сопоставимо с SDP параметрами.
Про SDP поля
Каждый из параметров SDP сообщения можно отнести к одной из следующих категорий:
Имя сессии;
Время, в течении которого сессия активна;
Параметры медиа;
Информация о пропускной способности;
Контактная информация;
Поговорим об основных параметрах. Они всегда имеют следующее обозначение: <поле> = <значение>. Поле всегда обозначается 1 буквой.
Поле
Значение
Формат
v=
версия протокола
v=0
o=
инициатор сессии и соответствующие идентификаторы
o=<имя_пользователя> <идентификатор_сессии> <версия> <тип_сети> <тип_адреса> <адрес>. В нашем примере поле o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz (IN - тип сети, интернет, IP4 - тип адреса, IPv4;
s=
имя сессии
в нашем примере прочерк ("-"), имя сессии не указано;
c=
информация о подключении;
Синтаксис таков: c=<тип_сети> <тип_адреса> <адрес>. В нашем примере IN IP4 80.xx.yy.zz. Параметры IN/IP4 объяснены выше.
t=
время активности сессии
Синтаксис поля таков: t=<начальное_время> <конечное_время>. Это обязательное поле, но важно отметить, что оно весьма субъективно, так как невозможно предсказать точное время начала и окончания. В нашем примере t=0 0
m=
тип передачи медиа данных, формат и адресация
m=<тип_медиа> <порт> <транспорт> <формат_передачи>. Давайте разберемся - у нас m=audio 57028 RTP/AVP 0 8 18 101, это означает передачу аудио (может быть значение video, или передача обоих типов), порт передачи обозначен как 57028, транспорт, указанный как RTP/AVP, означает передачу по протоколу RTP в рамках стандарта Audio and Video Conferences with Minimal Control, который описан в RFC3551. После, первый 0 означает протокол G.711 uLaw, 8 означает G.711 ALaw, 18 означает G.729. То есть условно говоря, нам предложено предпочтение кодеков сначала G.711 uLaw, затем G.711 ALaw, и третьим приоритетом G.729. 101 означает поддержку динамического типа данных, например DTMF.
a=
параметры сессии
a=<параметр> или a=<параметр><значение>. SDP сессия может содержать несколько дополнительных атрибутов передачи. Более подробно мы рассмотрим далее.
Помимо указанных параметров, зачастую встречаются такие как k=, в рамках которого описывается метод шифрования, или i=, содержащий дополнительную информацию о сессии. Поговорим про параметры поля a=:
Параметр
Синтаксис и описание
rtpmap
a=rtpmap:<тип> <название_кодировки>/<частота_дискретизации> [/<параметры_кодирования>].
Данный параметр подсказывает имена кодеков, частоту и прочие параметры кодирования для данных, обозначенных в параметре m=. Например, у нас a=rtpmap:0 PCMU/8000, означает использование G.711 с импульсно - кодовой модуляцией по U - закону с частотой дискретизации 8000 Гц.
sendrecv
a=sendrecv
Данный параметр указывает на то, что мы собираемся отправлять и получать медиа - данные. Например, возможно опция отправки (sendonly), только получение (recvonly) и отключения медиа (inactive);
ptime
a=ptime:<длительность_пакета>
Продолжительность RTP - пакет (в миллисекундах). Условно говоря, какой длительности фрагмент голоса переносит один RTP - пакет;
fmtp
a=fmtp:<формат> <специальные_параметры>
Параметр описывает дополнительные параметры сессии, например, такие как режим подавления тишины (VAD) и прочие;