Редизайн интерфейса приложения. #8

Сегодня я снова вернусь к “жизнеописанию” своего проекта. Возможно, в этом посте вы найдете еще один аргумент, для того, что бы перейти на Delphi XE2. Начну я с небольшого вступления.

На семинаре Embarcadero в Киеве в сентябре прошлого года я услышал историю о переводе на юникод очень большого проекта. Собственно, и истории ни какой не было. Был проект, который разработчики, с одной стороны, и хотели бы перевести на старшую версию Delphi. А с другой стороны у них в проекте 5 млн. строчек кода. И, естественно, перспектива рефакторинга и последующего тестирования такого количества кода их весьма пугает. А так ли страшно это на самом деле?

Я уже говорил, что проект у меня относительно не большой. Но вчера я обнаружил, что у меня у самого 0,6 млн. строк. Т.е. в теории выйти на сопоставимые порядки сложности приложения вполне реально, даже если не решать “сверхзадач” (я ни в коем случае не призываю оценивать сложность проекта количеством кода!).

Но таким объемом кода надо эффективно управлять и контролировать его. Конечно, hint’ы и warning’и помогают хоть как-то избегать ляпов. Но довольно часто разработчики просто не обращают на них внимания (что в корне не правильно), тупо полагаясь на оптимизатор.  Даже в довольно именитых наборах компонентов, при сборке исходников hint’ы и warning’и встречаются в изобилии. И полная ревизия всех сообщений компилятора – задача не простая.

И вот здесь очень удобно использовать QA Audits – инструмент, впервые появившийся в Delphi 2010. Использовать это средство в полном объеме могут владельцы Enterprise, Ultimate и Architect редакций Delphi.

Вы можете воспользоваться пунктом меню Project | QA Audits для вызова диалога настройки аудита.

Диалог настройки проверяемых параметров.

Я изначально не менял никаких настроек. Нажав на кнопу Start, после примерно минутного ожидания я получил весьма любопытный отчет. Количество проблемных пунктов меня просто удивило.

Результат QA аудита.

Как видно на рисунке, все потенциальные проблемы имеют свою аббревиатуру, которая указывает на тип. С помощью контекстного меню можно вызвать описание проблемы. При чем описания эти очень детальные, и практически всегда они сопровожденны примерами. У меня даже появилась идея перевести все эти описания на русский.

Конечно, соблюсти все рекомендации QA Audit практически невозможно. Например некоторыми соглашениями по оформлению кода я пожертвовал сразу, исключив этот пункт из настроек аудита. Некоторые рекомендации аудитора меня серьезно озадачили. Я так и не понял, что же с ними не так. К счастью таковых оказалось не много.

Но такие ляпы, как в коде, приведеном ниже ловить можно и нужно.

if Options.UseOwnTitles then
      begin
        // [Save own grid titles into the .ini file]
        try
          fIni:= TIniFile.Create(GetCustIniFileName(GridTitles));
          SaveCxGridLayout((dgd.Views[0] as TcxGridDBTableView), fIni, gstrSECTION_GRID);
        finally
          fIni.Free;
        end;
        RestoreCxGridTitles(dgd, 0, arrGridTitles); // Restore original titles
      end
      else
      begin
        RestoreCxGridTitles(dgd, 0, arrGridTitles); // Restore original titles
      end;

Конечно, не все так идеально, как хотелось бы. QA Audit не сделает ваш код идеальным в автоматическом режиме. Но для больших проектов это весьма ценный помощник при различного рода рефакторинге приложений. Особенно это ощутимо, когда проект несколько раз “переходил из рук в руки”.

На странице проекта Delphifeeds.ru в Facebook я разместил опрос относительно того, используете ли вы QA Audit.

Другие статьи серии:

Редизайн интерфейса приложения. #0
Редизайн интерфейса приложения. #1
Редизайн интерфейса приложения. #2
Редизайн интерфейса приложения. #3
Редизайн интерфейса приложения. #4
Редизайн интерфейса приложения. #5
Редизайн интерфейса приложения. #6
Редизайн интерфейса приложения. #7