Фикс-билд ClearSQL 7.1.2 (build 194) выложили 15 ноября 2018, но ссылку на пресс-релиз найти не удалось, потому что в обычном месте хранения всех RNs (s3-eu-west-1.amazonaws.com/conquestbucket/Release+notes/CS/) нет соответствующего pdf-файла. Билд был выложен уже после выпуска следующей мажорной версии - 8.0 (12 ноября 2018), что означает наличие серьёзного фикса в предыдущей поддерживаемой версии. Мой отчёт соответствует пунктам Release Notes, которые доступны из главного меню приложения "Help / Release Notes".
IMPROVEMENTS 1.5+0.5=2 из 2+1=3 возможных
SQL*Plus 0.5+1=1.5 из 2 возможных
⦁ Optimized the interaction between ClearSQL and SQL*Plus.
Оптимизировано взаимодействие между ClearSQL и SQL*Plus.
Поскольку нет конкретики, что именно оптимизировано (объёмы передачи данных, скорость или перекодировка), то можно либо мучаться и искать бесконечно разницу между предыдущим билдом и текущим, либо снять балл с пункта RNs за невнятное описание и не тратить время. Проведя пару тестов (выполнение скрипта с UTF-символами и скрипта большого размера) на предыдущем билде и текущем, мне не заметна была оптимизация. Но изменение другого порядка случайно удалось приметить: исполняемый файл для запуска SQL*Plus берётся (ищется) не только в первой папке из списка системной переменной PATH; пункты работы с SQL*Plus добавлены в контекстное меню редактора. За такое усовершенствование могу дать только полбалла, поскольку оно не соответствует словам тех.писательницы.
⦁ Improved messages related to the SQL*Plus feature.
Улучшены сообщения при работе с SQL*Plus.
Для теста выполняем все экшены, касающиеся SQL*Plus, в предыдущем и текущем билдах и выписываем (или сохраняем скриншоты) тексты сообщений. Сравнив тексты, получаем разницу в сторону дружелюбности и увеличения подробностей. Изменение заслуживает балл.
Import Wizard 0.5 из 1 возможного
⦁ File extensions used in the filter are now shown on the status bar of the wizard.
Расширения файлов, используемые при фильтрации, теперь показаны на статусной строке мастера.
Мастер импорта имеет два вида: импорт скриптов из файловой системы и импорт DDL объектов из базы. В данном случае рассматривается только импорт скриптов из файловой системы. Настройка фильтров по расширению файлов "New Project, Import and Link Manager / Files and Folders / File extension filter" доступна в установках приложения "Options / Preferences". В статусной строке мастера давно имелось место для отображения фильтров, и даже когда-то там они отображались. Так что этот пункт по ошибке расположен в улучшениях, так как ему самое место в числе исправленных багов. Хинт для этого элемента экрана также не изменён, и при огромном количестве расширений, не умещающихся в видимой части экрана, их всё ещё невозможно все увидеть. Так что, пункт получает лишь полбалла. И это весьма высоко оценено, за счёт не снижения общего количества очков за счёт выявленных или неисправленных багов.
BUGS FIXED 1.1+0+0.8+1+1=3.9 из 2+1+1+1+2=7 возможных, -1-1.2=-2.2 за баги
Import Wizard 0+1=1 из 2 возможных, -1-0.2=-1.2 за баги
⦁ Importing package specs with their package bodies no longer raises the warning message that such objects already exist.
Импорт спецификации пакета с его телом больше не сопровождается предупреждением об уже существующем таком объекте.
Описанный баг более вероятно, что проявлялся только при импорте DDL объекта из базы данных. Но для полноты проверки добавим в проект и скрипты из файловой системы. Импорт из базы проведём в следующих вариантах: в единую папку проекта обе составляющие пакета, в разные папки проекта тело и спецификацию, посмотрим вариацию одноимённых объектов в разных схемах базы, аналогично попробуем добавить объектный тип с его телом, обратим внимание на расширения файлов в дереве проекта. Тем самым выполним не только проверку полноценности исправления, но и учтём регрессию, перекрёстность и интеграцию. Нагрузку или безопасность этот фикс не должен изменить, поэтому эти тесты пропустим, а вот на интерфейс (логичность и понимание)стоит обратить внимание, потому что любые ограничения должны быть задокументированы или интуитивно доступны. Тестовыми данными будут одноимённые объекты (пакет и объектный тип с телами) в двух схемах любой доступной базы, причём содержимое объектов берём минимальное, потому что упор в тесте идёт на имя объекта. Также к тестовым данным отнесём файлы скриптов с изменяемыми именами и расширениями. Для создания объектов в базе удобно воспользоваться продуктом SQLDetective и его модулем Stored Program Editor, который способен создать нужные нам объекты с дефолтным наполнением. В нём же вы можете создать текстовые файлы для перепроверки импорта из файловой системы. Стоит предупредить, что объектов в папке базы должно быть более одного, чтобы при последующем импорте не вставлялась папка типа в проект. В предыдущем билде предупреждение об уже существующем скрипте в проекте появлялось при включенных опциях "Objects only" или "Checked only" в мастере импорта из базы в туже папку проекта, но не для импортируемого тела после импортированной спецификации пакета. Этот диалог ошибки усовершенствован в предупреждение с пятью вариантами (всем "да", всем "нет", прекратить), также заменён термин "файл" на "объект" при импорте не из файловой системы, а из базы данных. Пакеты и объектные типы обрабатываются одинаково. На аналогичный диалог заменено сообщение об ошибке при импорте из файловой системы. Это хорошие плюсы фикса. Но, к сожалению, в рамках фикса абсолютно упущен случай "Schemas, type folders, and objects", который безусловно всё также добавляет дубликаты объектов и папок в проект без каких-либо проверок и предупреждений. Считаю это недоправкой текущего фикса и затянувшимся старым багом. По совокупности выясненного исправления пункт RNs не получает балл, так как абсолютно не соответствует новому функционалу, а долгосрочная проблема дубликатов отнимает у билда ещё балл. За неописанные, хоть и полезные, изменения баллов добавлять не имею права, поскольку сокрытие от пользователя информации в среде тестировщиков карается оформлением задачи в баг-трекер.
В процессе тестов мне показалось странным, что мастер импорта из файловой системы до сих пор не оснащён функцией автоматического разбиения импортируемого скрипта на отдельные DDL и DML команды, как это реализовано в "SQLDetective / Stored Program Editor" .
⦁ Objects with similar names but different owners are now imported correctly.
Объекты с одинаковыми именами, но различных владельцев, теперь импортируются корректно.
В пункте RNs не уточнено, но полагаю, что фикс касается только импорта из базы данных с включенной опцией "Include object owner in script content", так что импорт из файловой системы рассматривать не буду. Если предыдущий пункт полноценно тестировался, то можно воспользоваться его шагами и результатами. На какую "корректность" стоит ориентироваться? Ни в какой документации ответ найти нельзя. Поэтому за использование термина без уточнения правил снимаю -0.2 балла. Из числа тестов для предыдущего пункта RNs берём те, что касались опции "Include object owner in script content". Для обоих её состояний смотрим на результаты импорта одноимённых объектов в единую папку проекта из двух разноимённых схем. Наличие диалога вместо окна ошибки в текущем билде позволяет импортировать копии одноимённых объектов из разных схем в одну папку проекта. Так что этот пункт RNs вполне можно было бы с соответствующей формулировкой разместить в блоке новшеств. Изменение получает балл.
Project Manager 1 из 1 возможного
⦁ Fixed the order of code review rules in the “By Code Review” filter.
Исправлен порядок правил кодирования в фильтре “By Code Review”.
Для теста раскроем указанный список в предыдущем и текущем билдах. В такой формулировке мне пришлось потратить намного больше времени на поиск факта исправления, нежели тех.писательница напрямую сказала бы о применении сортировки в алфавитном порядке к наименованиям правил внутри имеющихся групп. За введение пользователей в недоумение исправление получает не полный балл, а лишь половину.
Summary Info 0.8 из 1 возможного
⦁ Script statuses now correctly fit in the “Folder, Scripts, Script Statuses” panel.
Статусы скриптов теперь корректно распределены по панели “Folder, Scripts, Script Statuses”.
Проверку фикса стоит проводить не только в интерфейсной панели, но и в отчёте по проекту при разных состояниях (как в интерфейсе или дефолтные размеры для отчёта) опции "Project Report Assistant / New Report / Summary Options / Panes Size and Position". Для теста лучше взять демо-проект, потому что в нём имеются все нужные данные, в частности, скрипты в разных статусах. Подскажу, что панель “Folder, Scripts, Script Statuses” по-умолчанию расположена на закладке General в интерфейсной панели Summary и на странице "Project/Folder/Script Summary" в отчёте. Разница с предыдущим билдом заметна, если в проекте имеются скрипты всех статусов, потому что легенда чарта в отчёте прижата к значениям папок и скриптов, а в интерфейсе последние два из пяти возможных не умещались при дефолтной высоте панели. О корректности не может быть и речи, поскольку панель в интерфейсе и отчёте всегда имеет различный вид. Из всего выясненного даю фиксу 0.8 балла.
Code Analyzer Options 0 из 1 возможного
⦁ The filter on the Code Review Options page is no longer hidden when DPI 125% and higher is applied.
Фильтр на странице опций правил кодирования больше не прячется при увеличенном разрешении экрана.
Минимальная высота окна настроек анализатора кода изначально не рассчитана на монитор 9*16, и кроме элементов фильтра страницы вне экрана оказываются главные функциональные кнопки всего окна при разрешении монитора более 100%. Выход из положения в максимизации размеров окна. Но даже при максимизации в предыдущем билде не замечено прятание фильтра. Поэтому пункт RNs считается припиской и не получает ни балла.
Preferences 0.8+0.3=1.1 из 2 возможных, -1 за баги
⦁ Sorting of the summary code metrics is now reset to default correctly.
Сортировка суммарных метрик кода теперь восстанавливается в дефолтное состояние корректно.
Какая сортировка или какой её режим считается корректным по мнению тех.писательницы? Это знает только она, поскольку не указала общеизвестное правило, либо не расшифровала истинную причину бага. Поскольку пункт RNs в блоке настроек приложения, то проверять будем только здесь, то есть на странице "Preferences / Main Window / Summary" самый нижний элемент экрана - таблицу "Sort by" в блоке "Code Metrics". В предыдущем билде поиграем с перестановкой сортировок (клик левой кнопкой мыши по заголовку столбца меняет направление сортировки, снимает или устанавливает нумерацию и направление сортируемого столбца): любое изменение сортировки отображается в дереве страниц красной галочкой и кнопка OK активируется, клики по колонкам таблицы отрабатывают в ожидаемом порядке, после исполнения "Reset / Reset Current Page to Default" пропадает красная галочка в дереве страниц и гаснет кнопка OK, а иконки на столбцах перерисовываются после маха мышкой по их экранной области, оставляя сортировку нескольких столбцов в разном порядке. Стоит учесть, что назначение дефолтных значений осуществляется ещё и иными способами: выполнить "Reset / Reset All Pages to Default" в Preferences, установить приложение на чистую от настроек машину или удалить их из реестра и файловой системы. Посмотрим теже действия в текущем билде и выясним отличия. Сразу становится приметным отсутствие иконок фильтрации (красный флаг) и встроенного хелпа (синяя окружность с буквой i). После аналогичных шагов выясняется, что для перерисовки заголовков таблицы теперь не нужно проводить по ним мышкой, а сортировка устанавливается на поле Cyclomatic Complexity. Так что с учётом неясного описания фикс получает 0.8 балла.
⦁ Default sorting of the summary code metrics in Preferences is set to Cyclomatic Complexity, descending and it no longer differs from the sorting on the Summary tab.
Сортировка суммарных метрик кода по-умолчанию в настройках приложения устанавливается по Cyclomatic Complexity в обратном порядке и она больше не отличается от сортировки на закладке Summary.
Исходя из тестов предыдущего пункта RNs сразу заключаем, что сортировка по-умолчанию в обратном порядке ставится на столбце Cyclomatic Complexity, то есть различна с предыдущим билдом. Поэтому необходимо провести тест апдейта: запустить предыдущий билд с установками по-умолчанию, обновить приложение до текущего билда и дождаться предупреждения о смене настройки. Зачем такое проверять? У пользователя может быть настроен автоматический генератор отчётов с последующей отправкой его руководству, а если шеф получит неожиданные результаты, то исполнителю от этого станет весьма плохо. Поскольку продукт для конечного пользователя, а не для самореализации производителей, то любой шаг программиста в первую очередь должен быть обдуман с точки зрения юзера, а не маркетолога. Остаётся допроверить, что эта же установка автоматически переносится в интерфейсную панель Summary. Но не стоит забывать, что значения таблицы Code Metrics доступны не только в разрезе проекта на интерфейсной странице Summary (по-умолчанию, таблица Code Metrics расположена на закладке "Code Metrics - Details", остальные таблицы не упомянуты в RNs), но и в разрезе скрипта на странице "Script: Editor and Analyzer Info / Code Metrics", а также в отчёте по проекту в множественных разрезах (проект/папка/скрипт - суммарные страницы, скриптовые значения, детализация результатов анализа). Хоть два последних места и не упомянуты в фиксе, но их всё же стоит посмотреть для консистентности модулей. Поскольку при тестах предыдущего пункта RNs мы не открывали результаты анализа проекта и скрипта, то не заметили, что в Preferences дефолтная сортировка в таблице Code Metrics на странице "Preferences / Main Window / Summary" равнялась фактически выставленной сортировке в таблице Code Metrics на интерфейсной закладке Summary с результатами анализа проекта и никак не связана с аналогичной таблицей на закладке "Script: Editor and Analyzer Info / Code Metrics", что впрочем логично с точки зрения программиста, но сомнительно для пользователя. В текущем билде настройка в Preferences и сортировка в таблице "Summary / Code Metrics - Details / Code Metrics" связаны в оба направления и применяются точно также, как это и было в предыдущем билде. Отчёт по проекту не имеет никакой настройки для сортировки результатов Code Metrics и берёт их из интерфейса для суммарных таблиц и невесть откуда для скриптовых результатов. Отдельная закладка опций сортировки в мастере отчёта касается только дерева скриптов проекта. В итоге исправление выполнено наполовину, не являлось багом, а должно было быть в числе новшеств с предупреждением о введение дефолтного значения. Поэтому даю лишь 0.3 балла. А за недоделки в отчёте и скриптовом уровне снимаю ещё по полбалла.
Итого по билду: 2+3.9=5,9 баллов из 3+7=10 возможных показывают готовность билда на 59%, за баги снимается -2.2 балла.
IMPROVEMENTS 1.5+0.5=2 из 2+1=3 возможных
SQL*Plus 0.5+1=1.5 из 2 возможных
⦁ Optimized the interaction between ClearSQL and SQL*Plus.
Оптимизировано взаимодействие между ClearSQL и SQL*Plus.
Поскольку нет конкретики, что именно оптимизировано (объёмы передачи данных, скорость или перекодировка), то можно либо мучаться и искать бесконечно разницу между предыдущим билдом и текущим, либо снять балл с пункта RNs за невнятное описание и не тратить время. Проведя пару тестов (выполнение скрипта с UTF-символами и скрипта большого размера) на предыдущем билде и текущем, мне не заметна была оптимизация. Но изменение другого порядка случайно удалось приметить: исполняемый файл для запуска SQL*Plus берётся (ищется) не только в первой папке из списка системной переменной PATH; пункты работы с SQL*Plus добавлены в контекстное меню редактора. За такое усовершенствование могу дать только полбалла, поскольку оно не соответствует словам тех.писательницы.
⦁ Improved messages related to the SQL*Plus feature.
Улучшены сообщения при работе с SQL*Plus.
Для теста выполняем все экшены, касающиеся SQL*Plus, в предыдущем и текущем билдах и выписываем (или сохраняем скриншоты) тексты сообщений. Сравнив тексты, получаем разницу в сторону дружелюбности и увеличения подробностей. Изменение заслуживает балл.
Import Wizard 0.5 из 1 возможного
⦁ File extensions used in the filter are now shown on the status bar of the wizard.
Расширения файлов, используемые при фильтрации, теперь показаны на статусной строке мастера.
Мастер импорта имеет два вида: импорт скриптов из файловой системы и импорт DDL объектов из базы. В данном случае рассматривается только импорт скриптов из файловой системы. Настройка фильтров по расширению файлов "New Project, Import and Link Manager / Files and Folders / File extension filter" доступна в установках приложения "Options / Preferences". В статусной строке мастера давно имелось место для отображения фильтров, и даже когда-то там они отображались. Так что этот пункт по ошибке расположен в улучшениях, так как ему самое место в числе исправленных багов. Хинт для этого элемента экрана также не изменён, и при огромном количестве расширений, не умещающихся в видимой части экрана, их всё ещё невозможно все увидеть. Так что, пункт получает лишь полбалла. И это весьма высоко оценено, за счёт не снижения общего количества очков за счёт выявленных или неисправленных багов.
BUGS FIXED 1.1+0+0.8+1+1=3.9 из 2+1+1+1+2=7 возможных, -1-1.2=-2.2 за баги
Import Wizard 0+1=1 из 2 возможных, -1-0.2=-1.2 за баги
⦁ Importing package specs with their package bodies no longer raises the warning message that such objects already exist.
Импорт спецификации пакета с его телом больше не сопровождается предупреждением об уже существующем таком объекте.
Описанный баг более вероятно, что проявлялся только при импорте DDL объекта из базы данных. Но для полноты проверки добавим в проект и скрипты из файловой системы. Импорт из базы проведём в следующих вариантах: в единую папку проекта обе составляющие пакета, в разные папки проекта тело и спецификацию, посмотрим вариацию одноимённых объектов в разных схемах базы, аналогично попробуем добавить объектный тип с его телом, обратим внимание на расширения файлов в дереве проекта. Тем самым выполним не только проверку полноценности исправления, но и учтём регрессию, перекрёстность и интеграцию. Нагрузку или безопасность этот фикс не должен изменить, поэтому эти тесты пропустим, а вот на интерфейс (логичность и понимание)стоит обратить внимание, потому что любые ограничения должны быть задокументированы или интуитивно доступны. Тестовыми данными будут одноимённые объекты (пакет и объектный тип с телами) в двух схемах любой доступной базы, причём содержимое объектов берём минимальное, потому что упор в тесте идёт на имя объекта. Также к тестовым данным отнесём файлы скриптов с изменяемыми именами и расширениями. Для создания объектов в базе удобно воспользоваться продуктом SQLDetective и его модулем Stored Program Editor, который способен создать нужные нам объекты с дефолтным наполнением. В нём же вы можете создать текстовые файлы для перепроверки импорта из файловой системы. Стоит предупредить, что объектов в папке базы должно быть более одного, чтобы при последующем импорте не вставлялась папка типа в проект. В предыдущем билде предупреждение об уже существующем скрипте в проекте появлялось при включенных опциях "Objects only" или "Checked only" в мастере импорта из базы в туже папку проекта, но не для импортируемого тела после импортированной спецификации пакета. Этот диалог ошибки усовершенствован в предупреждение с пятью вариантами (всем "да", всем "нет", прекратить), также заменён термин "файл" на "объект" при импорте не из файловой системы, а из базы данных. Пакеты и объектные типы обрабатываются одинаково. На аналогичный диалог заменено сообщение об ошибке при импорте из файловой системы. Это хорошие плюсы фикса. Но, к сожалению, в рамках фикса абсолютно упущен случай "Schemas, type folders, and objects", который безусловно всё также добавляет дубликаты объектов и папок в проект без каких-либо проверок и предупреждений. Считаю это недоправкой текущего фикса и затянувшимся старым багом. По совокупности выясненного исправления пункт RNs не получает балл, так как абсолютно не соответствует новому функционалу, а долгосрочная проблема дубликатов отнимает у билда ещё балл. За неописанные, хоть и полезные, изменения баллов добавлять не имею права, поскольку сокрытие от пользователя информации в среде тестировщиков карается оформлением задачи в баг-трекер.
В процессе тестов мне показалось странным, что мастер импорта из файловой системы до сих пор не оснащён функцией автоматического разбиения импортируемого скрипта на отдельные DDL и DML команды, как это реализовано в "SQLDetective / Stored Program Editor" .
⦁ Objects with similar names but different owners are now imported correctly.
Объекты с одинаковыми именами, но различных владельцев, теперь импортируются корректно.
В пункте RNs не уточнено, но полагаю, что фикс касается только импорта из базы данных с включенной опцией "Include object owner in script content", так что импорт из файловой системы рассматривать не буду. Если предыдущий пункт полноценно тестировался, то можно воспользоваться его шагами и результатами. На какую "корректность" стоит ориентироваться? Ни в какой документации ответ найти нельзя. Поэтому за использование термина без уточнения правил снимаю -0.2 балла. Из числа тестов для предыдущего пункта RNs берём те, что касались опции "Include object owner in script content". Для обоих её состояний смотрим на результаты импорта одноимённых объектов в единую папку проекта из двух разноимённых схем. Наличие диалога вместо окна ошибки в текущем билде позволяет импортировать копии одноимённых объектов из разных схем в одну папку проекта. Так что этот пункт RNs вполне можно было бы с соответствующей формулировкой разместить в блоке новшеств. Изменение получает балл.
Project Manager 1 из 1 возможного
⦁ Fixed the order of code review rules in the “By Code Review” filter.
Исправлен порядок правил кодирования в фильтре “By Code Review”.
Для теста раскроем указанный список в предыдущем и текущем билдах. В такой формулировке мне пришлось потратить намного больше времени на поиск факта исправления, нежели тех.писательница напрямую сказала бы о применении сортировки в алфавитном порядке к наименованиям правил внутри имеющихся групп. За введение пользователей в недоумение исправление получает не полный балл, а лишь половину.
Summary Info 0.8 из 1 возможного
⦁ Script statuses now correctly fit in the “Folder, Scripts, Script Statuses” panel.
Статусы скриптов теперь корректно распределены по панели “Folder, Scripts, Script Statuses”.
Проверку фикса стоит проводить не только в интерфейсной панели, но и в отчёте по проекту при разных состояниях (как в интерфейсе или дефолтные размеры для отчёта) опции "Project Report Assistant / New Report / Summary Options / Panes Size and Position". Для теста лучше взять демо-проект, потому что в нём имеются все нужные данные, в частности, скрипты в разных статусах. Подскажу, что панель “Folder, Scripts, Script Statuses” по-умолчанию расположена на закладке General в интерфейсной панели Summary и на странице "Project/Folder/Script Summary" в отчёте. Разница с предыдущим билдом заметна, если в проекте имеются скрипты всех статусов, потому что легенда чарта в отчёте прижата к значениям папок и скриптов, а в интерфейсе последние два из пяти возможных не умещались при дефолтной высоте панели. О корректности не может быть и речи, поскольку панель в интерфейсе и отчёте всегда имеет различный вид. Из всего выясненного даю фиксу 0.8 балла.
Code Analyzer Options 0 из 1 возможного
⦁ The filter on the Code Review Options page is no longer hidden when DPI 125% and higher is applied.
Фильтр на странице опций правил кодирования больше не прячется при увеличенном разрешении экрана.
Минимальная высота окна настроек анализатора кода изначально не рассчитана на монитор 9*16, и кроме элементов фильтра страницы вне экрана оказываются главные функциональные кнопки всего окна при разрешении монитора более 100%. Выход из положения в максимизации размеров окна. Но даже при максимизации в предыдущем билде не замечено прятание фильтра. Поэтому пункт RNs считается припиской и не получает ни балла.
Preferences 0.8+0.3=1.1 из 2 возможных, -1 за баги
⦁ Sorting of the summary code metrics is now reset to default correctly.
Сортировка суммарных метрик кода теперь восстанавливается в дефолтное состояние корректно.
Какая сортировка или какой её режим считается корректным по мнению тех.писательницы? Это знает только она, поскольку не указала общеизвестное правило, либо не расшифровала истинную причину бага. Поскольку пункт RNs в блоке настроек приложения, то проверять будем только здесь, то есть на странице "Preferences / Main Window / Summary" самый нижний элемент экрана - таблицу "Sort by" в блоке "Code Metrics". В предыдущем билде поиграем с перестановкой сортировок (клик левой кнопкой мыши по заголовку столбца меняет направление сортировки, снимает или устанавливает нумерацию и направление сортируемого столбца): любое изменение сортировки отображается в дереве страниц красной галочкой и кнопка OK активируется, клики по колонкам таблицы отрабатывают в ожидаемом порядке, после исполнения "Reset / Reset Current Page to Default" пропадает красная галочка в дереве страниц и гаснет кнопка OK, а иконки на столбцах перерисовываются после маха мышкой по их экранной области, оставляя сортировку нескольких столбцов в разном порядке. Стоит учесть, что назначение дефолтных значений осуществляется ещё и иными способами: выполнить "Reset / Reset All Pages to Default" в Preferences, установить приложение на чистую от настроек машину или удалить их из реестра и файловой системы. Посмотрим теже действия в текущем билде и выясним отличия. Сразу становится приметным отсутствие иконок фильтрации (красный флаг) и встроенного хелпа (синяя окружность с буквой i). После аналогичных шагов выясняется, что для перерисовки заголовков таблицы теперь не нужно проводить по ним мышкой, а сортировка устанавливается на поле Cyclomatic Complexity. Так что с учётом неясного описания фикс получает 0.8 балла.
⦁ Default sorting of the summary code metrics in Preferences is set to Cyclomatic Complexity, descending and it no longer differs from the sorting on the Summary tab.
Сортировка суммарных метрик кода по-умолчанию в настройках приложения устанавливается по Cyclomatic Complexity в обратном порядке и она больше не отличается от сортировки на закладке Summary.
Исходя из тестов предыдущего пункта RNs сразу заключаем, что сортировка по-умолчанию в обратном порядке ставится на столбце Cyclomatic Complexity, то есть различна с предыдущим билдом. Поэтому необходимо провести тест апдейта: запустить предыдущий билд с установками по-умолчанию, обновить приложение до текущего билда и дождаться предупреждения о смене настройки. Зачем такое проверять? У пользователя может быть настроен автоматический генератор отчётов с последующей отправкой его руководству, а если шеф получит неожиданные результаты, то исполнителю от этого станет весьма плохо. Поскольку продукт для конечного пользователя, а не для самореализации производителей, то любой шаг программиста в первую очередь должен быть обдуман с точки зрения юзера, а не маркетолога. Остаётся допроверить, что эта же установка автоматически переносится в интерфейсную панель Summary. Но не стоит забывать, что значения таблицы Code Metrics доступны не только в разрезе проекта на интерфейсной странице Summary (по-умолчанию, таблица Code Metrics расположена на закладке "Code Metrics - Details", остальные таблицы не упомянуты в RNs), но и в разрезе скрипта на странице "Script: Editor and Analyzer Info / Code Metrics", а также в отчёте по проекту в множественных разрезах (проект/папка/скрипт - суммарные страницы, скриптовые значения, детализация результатов анализа). Хоть два последних места и не упомянуты в фиксе, но их всё же стоит посмотреть для консистентности модулей. Поскольку при тестах предыдущего пункта RNs мы не открывали результаты анализа проекта и скрипта, то не заметили, что в Preferences дефолтная сортировка в таблице Code Metrics на странице "Preferences / Main Window / Summary" равнялась фактически выставленной сортировке в таблице Code Metrics на интерфейсной закладке Summary с результатами анализа проекта и никак не связана с аналогичной таблицей на закладке "Script: Editor and Analyzer Info / Code Metrics", что впрочем логично с точки зрения программиста, но сомнительно для пользователя. В текущем билде настройка в Preferences и сортировка в таблице "Summary / Code Metrics - Details / Code Metrics" связаны в оба направления и применяются точно также, как это и было в предыдущем билде. Отчёт по проекту не имеет никакой настройки для сортировки результатов Code Metrics и берёт их из интерфейса для суммарных таблиц и невесть откуда для скриптовых результатов. Отдельная закладка опций сортировки в мастере отчёта касается только дерева скриптов проекта. В итоге исправление выполнено наполовину, не являлось багом, а должно было быть в числе новшеств с предупреждением о введение дефолтного значения. Поэтому даю лишь 0.3 балла. А за недоделки в отчёте и скриптовом уровне снимаю ещё по полбалла.
Итого по билду: 2+3.9=5,9 баллов из 3+7=10 возможных показывают готовность билда на 59%, за баги снимается -2.2 балла.
Комментариев нет:
Отправить комментарий