пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Ищете возможность анализировать сетевой трафик/отправлять его на систему записи телефонных разговоров? Изи. Коммутаторы Cisco (да и многие другие) дают возможность копировать пакеты с определенного порта или VLAN и отправлять эти данные на другой порт для последующего анализа (Wireshark, например).
Кстати, этот функционал полезен при использовании IDS (Intrusion Detection System) систем в целях безопасности. Мы уже рассказывали теоретические основы SPAN/RSPAN, поэтому, сегодняшняя статья будет посвящена практике настройке.
Про настройку SPAN
В рамках обычной SPAN сессии захват (копирование) сетевого трафика происходит с порта источника (source port) и отправляется на порт назначения (destination port). Обратите внимание на пример ниже: мы сделаем SPAN – сессию с порта fa 0/1 и отправим данные на порт fa 0/5:
Важно! SPAN – сессия может работать только в рамках одного коммутатора (одного устройства).
Конфигурация:
switch# configure terminal
switch(config)# monitor session 1 source interface fa0/1
switch(config)# monitor session 1 destination interface fa0/5
Просто, не правда ли? В рамках данной конфигурации весь трафик с порта fa 0/1 будет скопирован на порт fa 0/5.
Интереснее: пример RSPAN
Идем вперед. Более продвинутая реализация зеркалирования трафика это RSPAN (Remote SPAN). Эта фича позволяет вам зеркалировать трафик между различными устройствами (коммутаторами) по L2 через транковые порты. Копия трафика будет отправляться в удаленный VLAN между коммутаторами, пока не будет принята на коммутаторе назначения.
На самом деле, это легко. Давайте разберемся на примере: как показано на рисунке, мы хотим копировать трафик с коммутатора №1 (порт fa 0/1) и отправлять трафик на коммутатор №2 (порт fa 0/5). В примере показано прямое транковое подключение между коммутаторами по L2. Если в вашей сети имеется множество коммутаторов между устройствами источника и назначения – не проблема.
Конфигурация:
//Настройки на коммутаторе источнике
switch_source# config term
switch_source(config)# vlan 100 //Создаем Remote VLAN на первом коммутаторе (в который будем передавать данные с source порта)
switch_source(config-vlan)# remote span
switch_source(config-vlan)# exit
switch_source(config)# monitor session 10 source interface fa0/1
switch_source(config)# monitor session 10 destination remote vlan 100
//Настройки на коммутаторе получателе
switch_remote# config term
switch_remote(config)# vlan 100 //Создаем Remote VLAN на втором (удаленном) коммутаторе (в который будем передавать данные с source влана уже на порт назначения)
switch_remote(config-vlan)# remote span
switch_remote(config-vlan)# exit
switch_remote(config)# monitor session 11 source remote vlan 100
switch_remote(config)# monitor session 11 destination interface fa0/5
Таким образом, весь трафик с интерфейса fa 0/1 на локальном коммутаторе (источнике) будет отправлен в vlan 100, и, когда коммутатор получатель (remote) получит данные на 100 VLAN он отправит их на порт назначения fa 0/5. Такие дела.
Party Hard: разбираемся с ERSPAN
ERSPAN (Encapsulated Remote Switched Port Analyzer) - фича, которая используется для копирование трафика в L3 сетях. В основе работы механизма лежит GRE инкапсуляция.
Как показано ниже, между коммутатором источником и коммутатором получателем устанавливается GRE – туннель (между IP – адресами машин). Опять же, мы хотим отправить трафик с порт fa 0/1 на порт fa 0/5.
Конфигурация:
//Настройки на коммутаторе источнике
switch_source(config)# monitor session 1 type erspan-source
switch_source(config-mon-erspan-src)# source interface fa0/1
switch_source(config-mon-erspan-src)# destination
switch_source(config-mon-erspan-src-dst)# erspan-id 111 //Это значение должно быть одинаковым на всех устройствах
switch_source(config-mon-erspan-src-dst)# ip address 192.168.1.5 //IP - адрес коммутатора получателя
switch_source(config-mon-erspan-src-dst)# origin ip address 192.168.2.5 //IP - адрес коммутатора отправителя (источника)
//Настройки на коммутаторе получателе
switch_remote(config)# monitor session 1 type erspan-destination
switch_remote(config-mon-erspan-dst)# destination interface fa0/5
switch_remote(config-mon-erspan-dst)# source
switch_remote(config-mon-erspan-dst-src)# erspan-id 111
switch_remote(config-mon-erspan-dst-src)# ip address 192.168.1.5 //IP - адрес коммутатора получателя (назначения)
Траблшутинг
Мониторинг трафика в указанном VLAN:
monitor session 1 source vlan 13
Мониторинг входящего или только исходящего трафика:
monitor session 1 source vlan 13 rx/tx
Посмотреть конфигурацию сессии зеркалирования:
show monitor session 1
QoS это возможность сети обеспечить специальный уровень обслуживания для конкретных пользователей или приложений без ущерба остальному трафику. Главная цель QoS это обеспечение более предсказуемого поведения сети передачи данных при работе с тем, или иным типом трафика, путем обеспечения необходимой полосы пропускания, контролем над задержкой и джиттером и улучшением характеристик при потере пакетов. Алгоритмы QoS достигают этих целей путем ограничения трафика, более эффективным использованием каналов передачи, и назначением тех или иных политик к трафику. QoS обеспечивает интеллектуальную передачу поверх корпоративной сети, и, при правильной настройке, улучшает показатели производительности.
Политики QoS
Тип трафика
QoS
Безопасность
Когда?
Голос
Задержка меньше 150 мс в одну сторону
Шифрование на уровне передаче голоса
Понедельник - Пятница
Система планирования ресурсов предприятия
Обеспечение доступной полосы пропускания минимум 512 кб/с
Зашифрован
24 часа в сутки, 7 дней в неделю, 365 дней в году
Трафик, создаваемый программным обеспечением станков и оборудования
Обеспечение доступной полосы пропускания минимум 256 кб/с
В открытом виде
Понедельник - Пятница
Трафик от использования интернет ресурсов HTTP/HTTPS
Негарантированная доставка по принципу Best Effort
HTTP прокси сервер
Понедельник – Пятница, с 8 утра до 9 вечера.
Осуществление QoS в сетях унифицированных коммуникаций
Условно, процесс осуществления QoS в сетях Unified Communications (унифицированных коммуникаций), можно разделить на 3 этапа:
Определение типа трафика в сети и его требований. На данном этапе необходимо научить сеть определять типы трафика чтобы применять к ним те или иные QoS алгоритмы;
Сгруппировать трафик в классы с одинаковыми требованиями QoS. Например, можно определить 4 типа трафика: голос, высоко – приоритетный трафик, низко – приоритетный трафик и трафик от пользования браузером для просмотра WEB страниц;
Назначить политики QoS, применяемые к классам, определенным в п.2.
В современных корпоративных сетях, голосовой трафик всегда требует минимальную задержку. Трафик, который генерируют критически важные для бизнеса приложения требует маленькой задержки (например, информация, относящаяся к банковскому обслуживанию). Другие типы информации могут быть не так чувствительны к задержкам, например, передача файлов или электронная почта. Обычное использование интернета в личных целях на работе может быть так же ограничено или даже запрещено.
Согласно указанным принципам, можно условно выделить три QoS политики:
Без задержки: Присваивается в голосовому трафику;
Лучшее обслуживание: Присваивается к трафику с наивысшим приоритетом;
Остальное: Присваивается к низко – приоритетному и трафику web – браузеров;
Шаг 1: Определение типа трафика
Первым шагом на пути к осуществлению QoS является идентификация типов трафика в сети и определение конкретных требований каждого из типов. Перед осуществлением QoS, настоятельно рекомендуется провести аудит сети, чтобы полностью понимать как и какие приложения работают в корпоративной сети. Если осуществить политики QoS не имея полного понимания корпоративного сегмента сети, то результаты могут быть плачевными.
Далее, необходимо определить проблемы пользователей при работе с теми или иными сетевыми приложениями: например, приложение медленно работает из-за чего имеет плохую производительности работы. Необходимо измерить сетевой трафик в часы наибольшей нагрузки, используя специальные утилиты. Для понимания процессов в сети, необходимым шагом является измерение загрузки процессора каждого из единиц активного сетевого оборудования в период наибольшей загруженности, чтобы четко знать, где потенциально могут возникать проблемы.
После этого, необходимо определить бизнес цели и модели работы и составить список бизнес – требований. По итогам этих действий, каждый из пунктов списка можно сопоставить с тем или иным классом трафика.
В конце, необходимо определить уровни обслуживания которые требуются для различного вида трафика в зависимости от требуемой доступности и быстродействия.
Шаг 2: Сгруппировать трафик в классы
После идентификации сетевого трафика, необходимо использовать список бизнес требований, составленный на первом этапе, чтобы определить классы трафика.
Голосовой трафик всегда определяется отдельным классом. Компания Cisco имеет разработанные механизмы QoS для голосового трафика, например, Low latency queuing (LLQ) , цель которого заключается в контроле за тем, чтобы голос получал преимущество в обслуживании. После того как определены наиболее критичные приложения, необходимо определить классы трафика использую список бизнес требований.
Не каждое приложение имеет свой собственный класс обслуживания. Довольно много приложений с похожими требованиями к QoS группируются вместе в единый класс.
Пример классификации трафика
Типичный корпоративный ландшафт определяет 5 классов трафика:
Голос: Наивысший приоритет для трафика VoIP;
Критически важные: Небольшой набор критически важных для бизнеса приложений;
Транзакции: В данном классе присутствуют сервисы баз данных, интерактивный трафик и привилегированный сетевой трафик ;
Негарантированная доставка: Работает по принципу Best Effort, что дословно переводится как «лучшее усилие». В данный класс можно отнести интернет трафик и e-mail.
Шаг 3: Сгруппировать трафик в классы
Третьим шагом необходимо описать политики QoS для каждого из классов трафика, которые включают следующие действия:
Назначить минимальный размер гарантированной полосы пропускания;
Назначить максимальный размер полосы пропускания;
Назначить приоритеты для каждого из классов;
Использовать QoS технологии, такие как алгоритмы контроля очередей для управления перегрузками.
Рассмотрим на текущем примере определение политик QoS для каждого из классов:
Голос: Доступна полоса пропускания – 1мбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением EF [7]. Метка EF (Expedited Forwarding) означает то, что пакеты с таким маркером получают приоритет в очереди согласно принципу наименьшей задержки. Дополнительно используется алгорит LLQ;
Критически важные: Минимальная полоса пропускания – 1мбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением AF31 (метка в поле DSCP 011010), что обеспечивает наименьшую вероятность отбрасывания пакета. Параллельное использование алгоритма CBWFQ гарантирует необходимую полосу пропускания для маркированного трафика;
Негарантированная доставка: Максимальная полоса пропускания – 500кбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением Default (метка в поле DSCP 000000), что обеспечивает обслуживание по умолчанию. Алгоритм CBWFQ обеспечивает «доставку по возможности», которая ниже по приоритету классов «Голос» и «Критически важные».
Что такое линтер? Если коротко, линтер – это инструмент, который может улучшить ваш код. Нельзя сказать, что понятие «линтер» является уникальным для JavaScript. И все-таки, я бы сказал, что большинство людей, которые хотят изучить линтеры, интересуются именно теми, что ориентированы на JavaScript (или, если брать шире, на динамически типизированные языки).
В этой статье мы ответим на заглавный вопрос и не только. Мы начнем с определения, что такое «линтер». Вы сможете разобраться в том, что это такое и как оно появилась. Далее мы поговорим о преимуществах линтеров и перейдем к обсуждению различных типов проверок, которые они предлагают.
И напоследок мы продемонстрируем несколько примеров линтеров, которыми вы можете воспользоваться, и дадим несколько практических советов о том, как начать работу, и подытожим все сказанное.
Давайте приступим.
Что такое линтер? Краткий обзор
Давайте для начала дадим определение, что же такое линтер. Как вы уже прочитали во введении, линтер – это инструмент, который предназначен для того, чтобы улучшить ваш код. Но как он это делает? Ответ: путем анализа исходного кода в поисках проблем.
Термин «линтер» происходит о названия инструмента «lint», который анализировал исходный код на С. Специалист в области информатики Стивен К. Джонсон разработал эту утилиту в 1978 году, когда работал в Bell Labs.
И оригинальный инструмент lint, и подобные утилиты более ранних версий имели одну цель – анализ исходного кода с целью оптимизировать программу в процессе компиляции. Со временем в инструментах, подобных lint, стали появляться все больше различных других типов проверок и верификаций.
Однако, как мы уже упоминали во введении, линтеры не ограничиваются только компилируемыми языками. Напротив, можно сказать, что линтеры гораздо более полезны для интерпретируемых языков, так как не существует компилятора, который бы был способен выявляться ошибки в процессе разработки.
Преимущества линтеров
Вы только что узнали, что такое линтер, и вы даже знаете теперь, когда и кем он был изобретен. Вполне возможно, вы уже имеете хотя бы какое-то общее представление о том, что линтер может делать с вашим кодом. Но, если посмотреть с практической точки зрения, какие преимущества может дать этот инструмент? Вот некоторые из них:
Меньше ошибок в готовых продуктах
. Линтеры помогают выявлять и устранять различные технические проблемы в коде, например, «код с душком». Как результат, в производство уходит меньше недочетов.
Понятный, удобный в сопровождении и более последовательный код
. За счет соблюдения правил линтеры могут помочь сделать код более понятным и последовательным.
Меньше споров по поводу оформления кода и эстетических решений во время рецензирования кода
. Обсуждения во время рецензирования кода не должны быть наполнены бесконечными спорами о стилистических предпочтениях. Линтеры могут избавить вас от этого.
Объективная оценка качества кода
. Обсуждения качества кода зачастую приобретают субъективный характер. Линтеры позволяют выполнить объективную оценку качества кода с помощью измеримых критериев.
Более безопасный и производительный код
. Не все линтеры могут анализировать исходный код на предмет его производительности и безопасности, но некоторые все же могут.
Больше разработчиков узнают, что такое качество кода
. Линтеры могут помочь разработчикам (особенно новичкам) узнать, что такое качество кода.
В следующем разделе мы будем рассматривать некоторые типы проверок, которые предлагают линтеры. Когда вы его прочитаете, вы поймете, каким образом линтеры обеспечивают все эти преимущества.
Типы проверок, предлагаемые линтером
Как вы уже прочитали, оригинальный lint анализировал код с целью обеспечить оптимизацию программ в процессе компиляции, но со временем были выпущены усовершенствованные и более полные инструменты. На сегодняшний день существует огромное количество разных линтеров, которые предлагают огромное количество проверок. Давайте пробежимся по некоторым из них.
Синтаксические ошибки
Самый простой и одновременно самый важный тип проверок, который предлагает линтер, - это проверка синтаксических ошибок в JavaScript и других интерпретируемых языках. Разработчикам даже не стоит пытаться отправлять код в ветку main до тех пор, пока он не пройдет проверку синтаксиса.
Один из способов сделать это – использовать хук pre-commit, который не будет разрешать пользователям отправлять свой код, если проверки линтера показывает, что в коде есть проблемы.
Соблюдение стандартов оформления кода
Еще одна важная проверка, предлагаемая линтером, - это проверка соблюдения стандартов оформления кода. Некоторые люди могут не воспринимать ее всерьез как чисто эстетическую проблему, но они заблуждаются. Наличие единого выдержанного стиля оформления кода имеет практическую значимость с точки зрения когнитивной нагрузки, то есть чтения, понимания и сопровождения кода. Кодовую базу, которая имеет единый стиль оформления, будет легче разобрать, а разработчики, которые с ней работают, будут с меньшей вероятностью допускать ошибки.
Для этой цели – для проверки кодовых баз на соответствие стандартам оформления, существуют специальные линтеры. Некоторые инструменты довольно категоричны в этом плане, то есть они имеют заранее определенный набор правил и соглашений, который нельзя изменить. Впрочем, существуют также инструменты, которые можно легко настроить. Это позволяет пользователю адаптировать их к тому стилю оформления кода, который они предпочитают.
Потенциальные проблемы (или «код с душком»)
«Код с душком» - это признак того, что с вашим кодом что-то не так. В данном случае крайне полезным будет иметь инструмент, который бы автоматически выявлял эти признаки, и, таким образом, вы могли бы при необходимости разобраться с ними.
Например, многие люди, в том числе и я, расценивают длинные функции как тот самый «код с душком». Так что, вы можете настроить свой линтер таким образом, чтобы он мог находить функции, длина которых превышает заданное количество строк.
Другой часто упоминаемый пример «кода с душком» - это слишком сложный код. Но мы здесь говорим о сложности не в субъективном смысле, а в очень даже объективном. Цикломатическая сложность – это довольно полезная метрика кода, которая обозначает количество возможных ветвей выполнения внутри функции. Линтеры могут вычислять цикломатическую сложность ваших функций и отмечать те, которые превышают этот порог.
Проверки безопасности
И последнее, но от того не менее важное: безопасность, которая без всякого сомнения является самым важным аспектом современного приложения, особенно веб-приложения. Ошибетесь, и последствия могут быть катастрофическими не только в плане денег и репутации, но и в плане юридических проблем (возьмите к примеру Общий регламент ЕС о защите персональных данных или какие-нибудь другие регламенты).
К счастью, эта та область, в которой линтеры могут помочь, так как существуют инструменты, предлагающие необходимые проверки безопасности.
Статический анализ
Мы объяснили, что такое линтеры и в чем их польза. Кроме того, мы рассмотрели основные типы линтеров. Теперь вы готовы узнать об инструментах статического анализа, предназначенных для различных целей и языков программирования.
Однако, прежде чем мы перейдем к этому, давайте сделаем небольшое отступление и поговорим о том, что такое статический анализ, поскольку этот термин будет встречаться в следующем разделе, но мы так и не дали ему определения.
Итак, что же такое статический анализ? Статический анализ можно сравнить с отладкой перед запуском. Статический анализ заключается в использовании инструментов, которые анализируют исходный код в поисках ошибок, отсутствия соблюдения правил и соглашений или других потенциальных проблем.
В следующем разделе мы продемонстрировали примеры линтеров, распределенных по группам в зависимости от проверок, которые они выполняют. Линтеры, классифицированные как инструменты статического анализа, в основном относятся к первому и третьему типам линтеров, перечисленных в разделе выше.
Примеры линтеров
Давайте быстро пробежимся по некоторым примерам линтеров. Мы выделим примеры для разных языков программирования и сгруппируем их по типу проверки, который они выполняют. Имейте в виду, что некоторые инструменты могут выполнять не один тип проверки, так что они появляются в нескольких категориях.
Линтеры для статического анализа
StandardJS для JavaScript
PHPMD для PHP
StyleCop для C#
Линтеры для проверки безопасности
Gosec для Go
Bandit для Python
LGTM для нескольких языков, в том числе JavaScript, Python и C#
Линтеры для проверки соблюдения правил по оформлению кода
Prettier для JavaScript
Rubocop для Ruby
StyleCop для C#
Линтеры в JavaScript: как приступить к работе
Прежде чем завершить эту статью, мы хотим поделиться с вами небольшим практическим руководством по тому, как начать работу по проверке кода на JavaScript. И раз мы говорим о JavaScript, нет ничего удивительного в том, что у вас есть куча инструментов на выбор. Ну а поскольку нам нужно выбрать только один, мы отдадим предпочтение ESLint.
Установка ESLint
Сначала – главное, установим линтер. ESLint устанавливается через npm, а это значит, что у вас должен быть установлен Node.js. Если у вас его нет, вам придется его скачать и установить.
Установив Node.js, мы готовы к тому, чтобы установить ESLInt через npm.
Для того, чтобы глобально установить инструмент, вам нужно выполнить следующую команду:
npm install eslint --global
Однако это не совсем то, что указано в их документации. Вероятнее всего, вам следует установить ESLint для каждого проекта отдельно. Так что, начните с того, что создайте каталог для вашего проекта:
mkdir eslint-sample-app
Затем перейдите в каталог через командную строку и выполните команду ниже, чтобы создать файл package.json (он понадобиться дальше).
npm init
npm задаст вам несколько вопросов. Просто нажимайте Enter, чтобы ответить (будут использоваться ответы по умолчанию). После этого вы можете добавить ESLint к своему проекту с помощью следующей команды:
npm install eslint --save-dev
Запуск и настройка ESLint
Следующим шагом вы можете запустить ESLint, выполнив следующую команду:
npx eslint --init
Когда вы запустите эту команду, ESLint спросит вам, для чего вы хотите его использовать. Варианты ответа: проверить только синтаксис; проверить синтаксис и найти проблемы; проверить синтаксис, найти проблемы и оформить код.
Давайте остановимся на последнем варианте. Чтобы выбрать вариант ответа, воспользуйтесь клавишами со стрелками, а, чтобы подтвердить его, нажмите Enter. Далее ESLint захочет узнать, какие типы модулей использует ваш проект.
Варианты ответа:
Модули JavaScript
Модули CommonJs
Ни один из вариантов
Выберите «Модули JavaScript» и переходите дальше. Затем вам спросят, какой фреймворк использует ваш проект. Вариантов ответа снова будет три:
React
Vue
Ни один из вариантов
Давайте в данном случае выберем «Ни один из вариантов». Следующий вопрос общий: использует ли ваш проект TypeScript? Чтобы выбрать «нет», нажмите N. Далее вас спросят где запускается ваш код, в браузере или в Node.
После чего ESLint спросит вас, какой способ определения стиля кода выбрать для вашего проекта. Он предложит вам три варианта: использовать общепринятое руководство по стилю, отвечать на вопросы о ваших предпочтениях в стиле или изучить ваши файлы .js. Выберите первый вариант. Затем вам будут предложены три стиля: AirBNB, Standard, Google и XO. В рамках данного пособия давайте выберем Google.
На следующем этапе ESLint спросит вас, какой формат файла конфигурации вы предпочитаете. Выберите YAML. И наконец, вас спросят, хотите ли вы загрузить выбранный стиль кода с помощью npm. Выберите «Да».
Проверка файла с помощью ESLint
После того, как загрузка завершится, вы сможете приступить к использованию ESLint и проверить с его помощью файл. Но для этого вам нужно найти файл, который вы будете проверять. Если у вас где-то есть файл .js, просто скопируйте его в каталог вашего проекта. Или вы можете клонировать
этот репозиторий с одним файлом
и использовать его для тестирования.
Для того, чтобы проверить файл, выполните следующую команду:
npx eslint path-to-your-file.js
Вот какой результат я получил, запустив команду для файла greeting.js, который вы можете загрузить из репозитория на GitHub:
F:\demos\eslint-demo\greeter.js
2:3 error Missing JSDoc comment require-jsdoc
3:1 error This line has a length of 86. Maximum allowed is 80 max-len
10:4 error Unexpected 'this' no-invalid-this
? 3 problems (3 errors, 0 warnings)
Как вы можете видеть, я получил три ошибки и ни одного предупреждения.
Что такое линтер? Отличный инструмент для вашего арсенала
В этой статье мы изучили саму идею линтеров. Теперь у вас есть четкое представление о том, что такое линтеры и для чего они нужны. Кроме того, вы узнали о разных типах линтеров и увидели примеры категорий, которые направлены на различные языки программирования.
Помимо всего прочего, вы теперь знаете, как приступить к работе с линтером для JavaScript – ESLint.
И что же дальше? Есть еще несколько вещей, которые вас стоит узнать, что продолжить работу:
Отключение правил
Подключение правил в качестве предупреждения или ошибки
Интегрирование проверок в процесс сборки
Расширение конфигурации
Создание собственных правил
Разумеется, вы можете поэкспериментировать и с другими линтерами. То, что мы выбрали именно ESLint в данном руководстве, вовсе не означает, что вы должны на нем зацикливаться. Например, есть JShint – еще один популярный линтер для JavaScript.
И последнее, не забывайте, что проверки кода с помощью линтеров – это крайне важно, но это лишь еще одно оружие в вашем арсенале. Вы ни в коем случае не должны забывать об автоматизированном тестировании, рецензировании кода, рефакторинге и многих других подходах, методах и инструментах, которые есть в вашем распоряжении для нескончаемой борьбы с бардаком в вашей кодовой базе.
И раз мы упомянули все эти подходы, методы и инструменты, которые вы можете использовать для того, чтобы улучить свою кодовую базу, мы не можем не выделить сквозное тестирование, которое, к сожалению, довольно часто упускают из виду. И это просто какое-то безобразие. Правильно подобранный инструмент сквозного тестирования вполне может стать мощным союзников в схватке против энтропии кода.