По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Процесс анализа программного кода должен быть максимально автоматизирован. Когда вы создаете запрос на включение изменений, как минимум, вам нужно запустить модульные тесты и статический анализ программного кода в функциональной ветке. Средства автоматизации могут многое рассказать о качестве кода: метрики, покрытие кода модульными тестами, обнаружение дублированных строк и т.д.
Однако есть как минимум 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, документация по структуре, проектная документация)?
Создается ли тикет
технических недоработок
, если запрос на внесение изменений содержит неэффективный или «грязный» код, который сейчас невозможно перестроить из-за недостаточного количества времени?
Заключение
Количество пунктов, на которых проверяющий должен заострить свое внимание, зависит от конкретного проекта и даже от конкретного запроса на внесение изменений. Ваш с коллегами мозговой штурм (если вы примите во внимание вышеприведенные пункты) может значительно снизить риск того, что вы забудете о чем-то важно при анализе программного кода.
В данной статье расскажем про полезные инструменты, которые стали доступны в 4 версии графического интерфейса Elastix. Модуль, который управляет всеми этими инструментами так и называется Tools.
Итак, для того, чтобы попасть в модуль нужно проделать следующий путь PBX → Tools, как показано ниже:
Как видно, нам доступно 5 функциональных инструментов:
Asterisk-Cli
Asterisk File Editor
Text to Wav
Festival
Recordings
Давайте обо всём по порядку.
Asterisk-Cli
Данный функционал избавляет нас от необходимости подключаться к нашей IP-АТС Asterisk по SSH или Telnet для доступа к командной строке, позволяя вводить необходимые команды прямо из web-интерфейса Elastix. Например, может понадобиться для перезагрузки Asterisk или всей системы целиком, просмотра логов, включения режима отладки и т.п.
Ниже представлен пример выполнения команды dialplan show (просмотр правил маршрутизации)
Asterisk File Editor
Позволяет в реальном времени просматривать и менять содержимое конфигурационных файлов Asterisk. Стоит отметить, что при изменении некоторых конфигурационных файлов, Asterisk требуется перезапустить. Для этого предусмотрена отдельная кнопка Reload Asterisk
Text to Wav
Очень простой функционал Text-to-Speech. Пишем в строку нужную фразу, выбираем формат WAV или GSM и жмём кнопку Generate Audio File. Доступен только на английском языке.
Festival
Включаем и выключаем поддержку модуля Festival
Recordings
Данный функционал позволяет быстро добавить звуковую запись в модуль System Recordings. Доступно два способа:
Первый – проассоциировать внутренний номер с аккаунтом пользователя, с которого вы зашли в web-интерфейс, дать записи имя и нажать Record. Через некоторое время, АТС совершит вызов на указанный номер, после короткого звукового гудка – начнётся запись и завершится, когда вы положите трубку.
Второй – загрузить звуковой файл самостоятельно с компьютера.
У каждого из нас, наверное, есть родственник (бабушка, брат, племянник или еще кто-то), который говорил так быстро, что вы не могли понять слова, которое он говорил? Некоторые компьютерные программы тоже "говорят" слишком быстро. Рисунок 1 иллюстрирует это.
На рисунке:
В момент времени 1 (T1) отправитель передает около четырех пакетов на каждые три, которые может обработать приемник. Приемник имеет пяти-пакетный буфер для хранения необработанной информации; в этом буфере находятся два пакета.
В момент времени Т2 отправитель передал четыре пакета, а получатель обработал три; буфер в приемнике теперь содержит три пакета.
На этапе T3 отправитель передал четыре пакета, а получатель обработал три; буфер в приемнике теперь содержит четыре пакета.
На этапе T4 отправитель передал четыре пакета, а получатель обработал три; буфер в приемнике теперь содержит пять пакетов.
Следующий переданный пакет будет отброшен получателем, потому что в буфере нет места для его хранения, пока получатель обрабатывает пакеты, чтобы их можно было удалить. Что необходимо, так это своего рода петля обратной связи, чтобы сказать передатчику замедлить скорость, с которой он посылает пакеты, как показано на рисунке 3.
Этот тип обратной связи требует либо неявной сигнализации, либо явной сигнализации между приемником и передатчиком. Неявная передача сигналов используется более широко. При неявной сигнализации передатчик предполагает, что пакет не был принят на основании некоторых наблюдений о потоке трафика. Например, получатель может подтвердить получение некоторого более позднего пакета, или получатель может просто не подтвердить получение определенного пакета, или получатель может не отправлять что-либо в течение длительного периода времени (в терминах сети). При явной сигнализации получатель каким-то образом напрямую сообщает отправителю, что определенный пакет не был получен.
Windowing
Windowing в сочетании с неявной передачей сигналов, безусловно, является наиболее широко используемым механизмом управления потоками в реальных сетях. Windowing по существу состоит из следующего:
Передатчик отправляет некоторое количество информации получателю.
Передатчик ждет, прежде чем решить, правильно ли была получена информация или нет.
Если получатель подтверждает получение в течение определенного периода времени, передатчик отправляет новую информацию.
Если получатель не подтверждает получение в течение определенного периода времени, передатчик повторно отправляет информацию.
Неявная сигнализация обычно используется с Windowing протоколами, просто не подтверждая получение конкретного пакета. Явная сигнализация иногда используется, когда получатель знает, что он сбросил пакет, когда полученные данные содержат ошибки, данные получены не по порядку или данные иным образом повреждены каким-либо образом. Рисунок 3 иллюстрирует простейшую Windowing схему-окно с одним пакетом.
В одиночном окне пакета (также иногда называемом ping pong) передатчик отправляет пакет только тогда, когда получатель подтвердил (показанный на рисунке как ack) получение последнего переданного пакета. Если пакет не получен, получатель не подтвердит его. При отправке пакета отправитель устанавливает таймер, обычно называемый таймером повторной передачи; как только этот таймер активируется (или истекает), отправитель предполагает, что получатель не получил пакет, и отправляет его повторно.
Как долго должен ждать отправитель? Существует несколько возможных ответов на этот вопрос, но по существу отправитель может либо ждать фиксированное количество времени, либо установить таймер на основе информации, полученной из предыдущих передач и условий сети. Простой (и наивной) схемой было бы
Измерьте промежуток времени между отправкой пакета и получением подтверждения, называемый временем обратного пути (RTT- Round Trip Time, хотя обычно пишется в нижнем регистре, поэтому rtt).
Установите таймер повторной передачи на это число плюс небольшое количество времени буфера, чтобы учесть любую изменчивость в RTT на протяжении нескольких передач.
Кроме того, получатель может получить две копии одной и той же информации:
A передает пакет и устанавливает таймер его повторной передачи
B получает пакет, но
Не может подтвердить получение, потому что он находится вне памяти или испытывает высокую загрузку процессора или какое-то другое состояние.
Отправляет подтверждение, но оно отбрасывается сетевым устройством.
Таймер повторной передачи в точке A истекает, поэтому отправитель передает другую копию пакета.
B получает эту вторую копию той же информации
Как получатель может обнаружить дублированные данные? Для получателя представляется возможным сравнить полученные пакеты, чтобы увидеть, есть ли дублирующаяся информация, но это не всегда будет работать - возможно, отправитель намеревался отправить одну и ту же информацию дважды. Обычный метод обнаружения дублирующейся информации заключается в включении некоторого вида порядкового номера в передаваемые пакеты. Каждому пакету присваивается уникальный порядковый номер при его создании отправителем; если получатель получает два пакета с одинаковым порядковым номером, он предполагает, что данные дублированы, и отбрасывает копии.
Окно размером 1, или ping pong, требует одного кругового перехода между отправителем и получателем для каждого набора передаваемых данных. Это, как правило, приводит к очень низкой скорости передачи. Если рассматривать сеть, как о сквозном железнодорожном пути, а каждый пакет-как об одном вагоне поезда, то наиболее эффективное использование пути и самая быстрая скорость передачи данных будут тогда, когда путь всегда полон. Это физически невозможно, однако, в случае сети, потому что сеть используется многими наборами отправителей и получателей, и всегда есть сетевые условия, которые помешают использованию сети достичь 100%. Существует некоторый баланс между повышением эффективности и скорости отправки более одного пакета за один раз, а также мультиплексированием и "безопасностью" отправки меньшего количества пакетов за один раз (например, одного). Если правильная точка баланса может быть вычислена каким-то образом, схема управления потоком с фиксированным окном может хорошо работать. Рисунок 4 иллюстрирует это.
На рисунке 4, предполагаемое фиксированное окно с тремя пакетами:
При T1, T2 и T3 A передает пакеты; A не нужно ждать, пока B что-либо подтвердит, чтобы отправить эти три пакета, так как размер окна установлен на 3.
В момент T4 B подтверждает эти три пакета, что позволяет A передать другой пакет.
При T5 B подтверждает этот новый пакет, даже если это только один пакет. B не нужно ждать, пока A передаст еще три пакета, чтобы подтвердить один пакет. Это подтверждение позволяет A иметь достаточный бюджет для отправки еще трех пакетов.
При T5, T6 и T7 A отправляет еще три пакета, заполняя свое окно. Теперь он должен ждать, пока B не подтвердит эти три пакета, чтобы отправить больше информации.
На этапе T8 B подтверждает получение этих трех пакетов.
В схемах управления окнами, где размер окна больше одного, существует четыре вида подтверждений, которые приемник может отправить передатчику:
Положительное подтверждение: приемник подтверждает получение каждого пакета в отдельности. Например, если порядковые номера 1, 3, 4 и 5 были получены, приемник подтвердит получение этих конкретных пакетов. Отправитель может сделать вывод, какие пакеты не получил приемник, отметив, какие порядковые номера не были подтверждены.
Отрицательное подтверждение: приемник отправляет отрицательное ack для пакетов, которые, по его мнению, отсутствуют или были повреждены при получении. Например, если порядковые номера 1, 3, 4 и 5 были получены, приемник может сделать вывод, что порядковый номер 2 отсутствует, и отправить отрицательное ack для этого пакета.
Выборочное подтверждение: по сути, это сочетание положительного и отрицательного подтверждения, как указано выше; приемник отправляет как положительные, так и отрицательные подтверждения для каждой последовательности полученной информации.
Кумулятивное подтверждение: подтверждение получения порядкового номера подразумевает получение всей информации с более низкими порядковыми номерами. Например, если порядковый номер 10 подтвержден, подразумевается информация, содержащаяся в порядковых номерах 19, а также информация, содержащаяся в порядковом номере 10
Третий оконный механизм называется управлением потоком скользящего окна. Этот механизм очень похож на фиксированный механизм управления потоком окон, за исключением того, что размер окна не является фиксированным. При управлении потоком со скользящим окном передатчик может динамически изменять размер окна при изменении сетевых условий. Приемник не знает, какого размера окно, только то, что отправитель передает пакеты, и время от времени приемник подтверждает некоторые или все из них, используя один из механизмов подтверждения, описанных в предыдущем списке. Механизмы скользящих окон добавляют еще один интересный вопрос к вопросам, уже рассмотренным в других механизмах управления окнами: какого размера должно быть окно? Простое решение позволяет просто вычислить rtt и установить размер окна, кратный rtt. Были предложены более сложные решения;
Negotiated Bit Rates (Согласование Bit Rates)
Другое решение, которое чаще используется в сетях с коммутацией каналов, а не в сетях с коммутацией пакетов, заключается в том, чтобы отправитель, получатель и сеть согласовывали скорость передачи битов для любого конкретного потока. Широкий спектр возможных скоростей передачи данных был разработан для ряда различных сетевых технологий. Возможно, "наиболее полный набор" предназначен для асинхронного режима передачи данных (ATM)-но данные сети ATM вы скорее всего найдете в ближайшем Музее истории сетей, потому что ATM редко развертывается в производственных сетях. Битовые скорости ATM являются:
Постоянная скорость передачи (Constant Bit Rate -CBR): отправитель будет передавать пакеты (или информацию) с постоянной скоростью; следовательно, сеть может планировать с учетом этой постоянной нагрузки на полосу пропускания, а приемник может планировать с учетом этой постоянной скорости передачи данных. Этот битрейт обычно используется для приложений, требующих синхронизации времени между отправителем и получателем.
Переменная скорость передачи (Variable Bit Rate -VBR): отправитель будет передавать трафик с переменной скоростью. Эта скорость обычно согласовывается с несколькими другими частями информации о потоке, которые помогают сети и получателю планировать ресурсы, включая:
Пиковая скорость или максимальная скорость передачи пакетов в секунду, которую планирует передать отправитель
Устойчивая скорость или скорость, с которой отправитель планирует передавать данные в обычном режиме
Максимальный размер пакета или наибольшее количество пакетов, которые отправитель намеревается передать за очень короткий промежуток времени
Доступная скорость передачи (Available Bit Rate -ABR): отправитель намеревается полагаться на способность сети доставлять трафик с максимальной отдачей, используя некоторую другую форму управления потоком, такую как метод скользящего окна, для предотвращения переполнения буфера и настроить передаваемый трафик на доступную полосу пропускания.