Home

Автор: Боб Салмон (Bob Salmon)
Оригинал статьи
Перевод: Ольга Алифанова

Эта статья - ответ на челлендж Министерства тестирования “Как мы хакнули инструмент, чтобы заставить его работать на нас”. Сначала я поговорю об инструментах в целом, а затем приведу пару примеров не особенно стандартного использования инструментов. Я уже писал немного об инструментах, но не в этом контексте. Использование инструментов интересным способом или их комбинирование часто встречается в физическом мире - неудивительно, что мы переносим эту идею и на ПО тоже. Пила и стусло, молоток и долото - инструменты улучшают друг друга.

Хороший ящик с инструментами - больше, чем сумма его составляющих

Взлом инструментов

Инструменты вроде Emacs, Visual Studio и VS Code - это швейцарские ножи в том смысле, что они пытаются самостоятельно решить множество проблем. Я пользовался всеми тремя, все из них люблю, и зачастую они именно то, что мне нужно. Но иногда в них есть пробелы, или же легче или быстрее использовать другой подход. Тут и вступает в игру взлом инструментов.

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

Это соответствует UNIX-философии инструментов, которые можно комбинировать: каждый инструмент сфокусирован на одной задаче и отлично взаимодействует с другими инструментами. В случае UNIX это взаимодействие с другими - стандарт интерфейсов ввода-вывода между инструментом и другими инструментами / файловой системой / экраном / клавиатурой. Инструменты легко составлять в цепочки, где результат работы инструмента А становится входными данными для инструмента В, и так далее. Эта философия перешла в PowerShell, упростивший процесс и сделавший его приятнее.

Два приведенных ниже примера не используют преимущества UNIX или архитектуры PowerShell, но все еще должны справляться с вопросом интерфейсов между инструментарием.

Планирование проекта

Прежде чем описывать инструменты, объясню проблему, которую они помогли решить. На прошлой работе у нас была большая база кода на С, разделенная на множество отдельных библиотек (файлы .so и .a). Ранее этот код предполагал, что текст может нормально храниться и обрабатываться, если каждый символ в тексте представлен единственным байтом. Это отлично работает для английского и ряда других языков, но не универсальный подход для всех языков и стран.

Дабы продавать наше ПО в большем количестве стран, нужно было конвертировать код, дабы он мог использовать несколько байтов для символа в тексте - то есть нужно было сделать код мультибайтовым. Однобайтовый код может вызывать мультибайтовый код, но не наоборот, так как поведение однобайтового кода - подмножество мультибайтового. Если библиотека А вызывает библиотеку В:

• если мы конвертируем В в мультибайт, а затем А, код сработает и пройдет тесты.
• если мы конвертируем А, а затем В, код не будет компилироваться, пока и А и В не будут сконвертированы.

Следовательно, нам нужно было выявить все зависимости между библиотеками в терминах “если А вызывает В”. Помимо этого, нам нужно было разработать эффективное транзитивное замыкание этих зависимостей. Если А вызывает В, а В вызывает С, нам нужно сначала обработать С, затем В, затем А. Нам нужно знать, какие библиотеки находятся в самом низу - в смысле, не вызывают никакие другие. Затем, когда они сконвертированы, нужно знать, какие библиотеки обращаются только к сконвертированным, и так далее.

С описанием проблемы разобрались, перейдем к решению. Мы написали небольшую программу на С, которая исследовала метаданные (символьную таблицу) каждой библиотеки и отслеживала, какой код других библиотек ей вызывается. Каждая библиотека исследовалась в изоляции, чтобы не волноваться по поводу общей картины. Результатом работы этого инструмента был текстовый файл, содержащий имя каждой библиотеки и пары A -> B для всех вызываемых ей библиотек.

Формат этого файла был входным форматом для GraphViz.  GraphViz ничего не понимает в библиотеках С, мультибайтовом коде, однобайтовом коде, и прочих подобных вещах. Он может взять текстовый файл, описывающий блобы и линии между ними, и распределить их на странице так, что блобы не перекрывают друг друга, а линии максимально короткие.

Как только мы получили текстовый файл с библиотеками и их зависимостями в формате GraphViz и скормили его в GraphViz, результатом стала PERT-диаграмма проекта. Мы знали, что начинать надо с библиотек внизу диаграммы, затем переходить к библиотекам на уровень выше, и т. д.

Работа с данными

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

Я часто обращаюсь к Notepad++ и Excel, а также к обоим сразу - каждый из них умеет что-то, что напарник не может. Иногда быстрее выбрать данные, которые хочешь оставить, а иногда - удалить данные, которые не нужны. Инструменты позволяют делать и то, и другое.

Преимущества Notepad++ в том, что он мало весит, в его макросах, в функции “найти и заменить”. Так как он мало весит, он быстро стартует и может справиться с большими файлами. Макросы позволяют нажать на запись, выполнить серию операций при помощи клавиатуры и/или мыши, а затем нажать на стоп. Последовательность операций между записью и стопом можно заново проиграть бесконечное количество раз - столько, сколько нужно, чтобы поместить курсор в конец файла.

Функция поиска и замены имеет три режима - обычный, расширенный, и регулярные выражения. Иногда я использую “найти и заменить” как “найти и удалить”, оставляя поле замены пустым - все, что соответствует поисковому запросу, будет заменено на пустоту, то есть удалено.

Расширенный режим позволяет ставить в конце полей поиска и замены “\n” - разрыв строки. Это означает, что можно легко найти начало или конец строк, объединять их или разделять, удаляя или добавляя разрывы строки. К примеру, если у вас есть однострочный XML или HTML, его можно быстро привести в более-менее читабельный вид, заменяя “><” на “>\n<”. В результате разрыв строки будет помещен между концом одного элемента и началом другого, и каждый элемент займет отдельную строку.

Регулярные выражения - это свой отдельный мир (иногда - мир боли и отчаяния), но они сильно повышают вашу гибкость.

Excel хорошо работает, когда ваши данные разделены на строки и колонки - например, разделены разрывами строки и запятыми. Если данные еще не приведены к такой структуре, с этим может помочь Notepad++, это достаточно легко делается. Excel хорош для удаления или смещения колонок (он также может на время их скрыть). Он также умеет сортировать строки и использовать автоматические фильтры для показа или скрытия строк. Иногда я переключаюсь с инструмента на инструмент, и все, что вам нужно при этом помнить - что Excel-файлы следует сохранять в CSV, а не в XSLX-формате.

Заключение

Если инструмент не решает всех проблем, это может раздражать. Однако комбинация инструментов или восполнение их недостатков может быть креативным и полезным процессом. Разработка инструментов, которые хорошо справляются с одной конкретной задачей и умеют дружить с другими инструментами, приведут к арсеналу, который больше, чем сумма его составляющих, благодаря помогающим друг другу инструментам.

Обсудить в форуме