Рефакторинг “ада включения файлов”

StackOverflow https://stackoverflow.com/questions/143745

Вопрос

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

Редактировать: Одна вещь, которую я забыл спросить:есть ли в vbscript какой-либо механизм для предотвращения повторного включения файла?Что-то вроде #ifndef из C?

Это было полезно?

Решение

Есть несколько основных вещей, которые вы можете сделать при использовании классического приложения ASP, но, вероятно, в конечном итоге вы пожалеете о том, что сделали это.

  1. Устраните дублирующиеся включаемые файлы.Каждое классическое приложение ASP на те, которые я видел у 5 "для входа.АСП" страниц и 7 "datepicker.js" файлы и так далее.Найдите и удалите все дубликаты, а затем при необходимости измените ссылки в остальной части приложения.Будьте осторожны, проверяя различия в каждом файле при его удалении - часто дублированные файлы имеют небольшие отличия, потому что автор оригинала скопировал их, а затем изменил только копию.Это отличная вещь для Эволюции, но не столько для кода.
  2. Создайте рациональную структуру папок и переместите в него все файлы.Это очевидно, но именно о таком поступке вы больше всего пожалеете.Независимо от того, являются ли ссылки в приложении относительными или абсолютными, вам придется изменить большинство из них.
  3. Объедините все ваши включаемые файлы в один большой файл.Затем вы можете логически упорядочить все функции и разбить их на отдельные файлы с разумными именами.Затем вам нужно будет просмотреть страницу приложения за страницей и выяснить, какими должны быть инструкции include на каждой странице (или придерживаться одного файла и просто включать его на каждой странице - я не могу вспомнить, хорошая ли это идея в ASP).Я не могу понять уровень сложности, связанный с этим, и это предполагает, что существующие включаемые файлы не используют глобальные файлы с одинаковыми именами.

Я бы не стал делать ничего из этого.Перефразируя Стива Йегге (я думаю), "в классическом ASP-приложении нет ничего плохого, что нельзя было бы исправить с помощью полной перезаписи".Я очень серьезно отношусь к этому - я не думаю, что в этом мире есть большая трата времени программиста, чем поддержание приложения на ASP, и проблема только усугубляется по мере того, как ASP все больше и больше устаревает.

Другие советы

@Музигенизация маркированный список - хороший совет, которому следует следовать, но я бы с ним не согласился -

"Я бы не стал делать ничего из этого.Перефразируя Стива Йегге (я думаю), "нет ничего плохого в классическом ASP-приложении, которое нельзя исправить с помощью полной перезаписи".Я очень серьезно отношусь к этому - я не думаю, что в этом мире есть большая трата времени программиста, чем поддержание приложения на ASP, и проблема только усугубляется, поскольку ASP все больше и больше устаревает ".

Все это очень хорошо, но если это крупное устаревшее приложение, то полная перезапись часто невозможна из-за нехватки времени / ресурсов разработчика.

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

  1. Там, где требуется новая функциональность, она реализована в ASP.NET.Это происходит в 95% случаев.Крайние случаи в 5% случаев обычно заключаются в том, что существует большое количество точек, где новый код приложения соприкасается со старым приложением, требуя от нас выполнения большого количества классической переработки ASP, что потенциально делает приложение более хрупким.

  2. При изменении функциональности мы оцениваем, можем ли мы провести рефакторинг до ASP.NET с минимальным воздействием.Если это невозможно, то мы внесем изменения в классический ASP и приведем в порядок существующий код по ходу работы, напримерупрощение вложенности файлов include, замена javascript более удобным для кроссбраузерности кодом и тому подобное.

В ответ на ваш вопрос о #ifndef, боюсь, эквивалента не существует.

  1. Используйте один файл для глобальных заголовков и включений (давайте назовем его t-head.asp).Этот файл включен во все файлы asp.
  2. Используйте один файл, чтобы создать визуальный глобальный заголовок сайта (логотипы, меню и т.д.) и включить его сразу за ним.Давайте назовем это t-begin.asp
  3. Используйте один файл, чтобы сделать сайт визуальным глобальным нижним колонтитулом (авторское право, google analytics и т.д.) и закрыть все разделы или таблицы, открытые в t-begin.asp.Давайте назовем этот файл t-end.asp
  4. Используйте одну папку для размещения файлов бизнес-логики, называемую BUS.Файлы в этой папке не могут содержать includes.Каждой функции внутри файла должно предшествовать имя логического блока (Т. е.:все функции в products.asp должны начинаться с product_*)
  5. Используйте одну папку, чтобы поместить некоторый повторно используемый код пользовательского интерфейса под названием UI.Файлы в этой папке не могут содержать includes.

Пример:

<%@  Language=VBScript %>
<% Option Explicit %>
<% Response.Buffer = true%>
<html>
<head>
<!--#include file="../general/t-head.asp"-->
<!--#include file="../bus/product.asp"-->
<title>Products page</title>
</head>
<body>
<!--#include file="../general/t-begin.asp"-->

   <% 'all your code  %>

<!--#include file="../general/t-end.asp"--> 
</body>
</html>

Ух ты.Меня постоянно удивляет, как много людей ненавидят ASP.В достойных руках это вполне пригодный язык для разработки веб-приложений.

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

У меня, как правило, есть один включаемый файл (initialise.asp или что-то подобное), который сам по себе включает ссылки на несколько библиотек функций (lib_http.asp, lib_mssql.asp или что-то подобное), и все библиотечные функции являются автономными, так что можно не беспокоиться о пересечении переменных.Любые глобальные переменные объявляются и устанавливаются в главном файле.Это означает, что я могу использовать функцию где угодно и в любое время и не беспокоиться о том, где она была определена, она просто существует для использования.А IDE, такие как Visual Studio и Primalscript, имеют возможность "перейти к определению", когда вы обнаруживаете вызов функции, которую вы не распознаете.

Затем любые включения, относящиеся к конкретному сценарию, включаются в сценарий после вызова этого основного файла включения.

Я признаю, что это ресурсоемкий подход, поскольку все функции во всех библиотеках компилируются для каждого вызова скрипта, поэтому метод нуждается в доработке для каждого разрабатываемого вами сайта - решайте, что вызывать через master include, а что более специфично для страницы.Было бы неплохо иметь возможность загружать только то, что вам нужно - но это подход с использованием DLL, и он недоступен для большинства реальных разработок, а также вам пришлось бы взвесить стоимость процессора для компиляции небольших скриптов и загрузки компонентов.

Сжатая структура каталогов необходима и ее легко разработать, но может оказаться сложной задачей разобраться во всем коде существующего сайта и изменить любые ссылки или вызовы mappath.Кроме того, имейте в виду, что некоторые администраторы IIS запрещают '..\' метод обхода каталогов с помощью VBScript, так что тогда все ссылки на файлы должны быть абсолютными путями.

я думаю, вам следует рассмотреть возможность переноса вашего кода из ASP VBScript в библиотеки DLL Visual Basic COM.это избавит вас от необходимости слишком много включать в себя.

Я не знаю способа предотвратить двойное включение, кроме получения сообщения об ошибке, которое есть.Видите ли вы включения, размещенные по всей странице, что затрудняет их обнаружение?

Кстати, работаете ли вы с копией кода и базы данных на сервере разработки?Исходя из моего опыта, первое, что нужно сделать, это как можно скорее отделиться от живого сайта.Хотя поначалу это доставит вам немало хлопот, это даст вам свободу вносить изменения, не портя работу сайта в реальном времени.Легко внести одно крошечное изменение в include- и БАЦ!весь сайт выходит из строя.

Я работал над несколькими проектами, подобными описанным вами, и использовал следующие стратегии:

Полное переписывание - идеально, когда есть время / деньги, но обычно мне звонят, когда что-то пошло не так и результаты нужны как можно скорее.

Небольшие проекты - я открываю все в IDE и просто начинаю искать функции / sub во всех файлах проекта, чтобы получить представление о логике включения.Практически каждый раз все распределено повсюду, поэтому я начинаю перестраивать включаемые файлы, организованные по бизнес-логике.Я также сталкивался со встроенным кодом (необработанным кодом, а не вспомогательными элементами или функциями), добавляемыми во включаемое, поэтому обычно я просто возвращаю код обратно на страницу для последующего рефакторинга.

Более крупные проекты - я использую некоторый код, который у меня есть, чтобы проанализировать includes для строк с заголовками sub / function и сбросить их в текстовый файл, чтобы составить список того, какие подпрограммы где находятся, и сослаться на это.Это пригодится, когда у вас есть тонна включений на каждой странице и вы не можете разобраться в кодовой базе.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top