重構「包含文件地獄」

在ASP經典項目中加快代碼庫速度真的讓生活變得困難的一件事是包含文件的情況有點亂。我有時會發現我正在尋找的函數被包含在一個完全不相關的包含文件中。有沒有人有任何關於如何重構這個建議，以便如果他們需要找到它，可以更容易地知道函數的位置？重構「包含文件地獄」

編輯：有一件事我忘了問：vbscript是否有任何防止文件被包含兩次的機制？ Sorta像C＃中的＃ifndef？

來源

2008-09-27 Jason Baker

在接管傳統的ASP應用程序時，您可以做幾件基本的事情，但最終可能會後悔做這些事情。

消除重複的包含文件。我見過的每個經典ASP應用程序都有5個「login.asp」頁面和7個「datepicker.js」文件等等。搜索並刪除所有重複項，然後根據需要更改應用程序其餘部分的引用。在刪除文件時，要小心地對每個文件進行差異檢查 - 通常複製的文件會有細微的差異，因爲原作者會複製它，然後只更改副本。對於Evolution來說這是一件好事，但不是代碼。
創建合理的文件夾結構並將所有文件移入其中。這一點很明顯，但這是你最後悔的一個。無論應用程序中的鏈接是相對的還是絕對的，您都必須更改其中的大部分。
將所有包含文件合併成一個大文件。然後，您可以對所有功能進行邏輯重新排序，並將其分解爲單獨的，明智命名的文件。然後，您必須逐頁瀏覽應用程序並找出每個頁面上的包含語句需要的內容（或者堅持使用一個文件，並將其包含在每個頁面中 - 我不記得是否包含這在ASP中是一個好主意）。我無法理解這裏涉及的痛苦程度，這是假設現有的包含文件不會大量使用同名的全局變量。

我不會這樣做。爲了解釋Steve Yegge（我認爲），「經典的ASP應用程序沒有問題，無法通過總重寫修復」。我對此非常認真 - 我認爲在這個世界上，與維護一個ASP應用程序相比，程序員的時間浪費更大，而隨着ASP越來越過時，問題會變得更糟。

來源

2008-09-27 15:19:59 MusiGenesis

我希望這是我的一個選擇。 :( 不幸的是，我沒有太多的選擇 – 2008-09-27 15:23:43

我認爲你應該考慮將你的代碼從ASP VBScript轉移到Visual Basic COM DLL。這會讓你有更多的包容。

來源

2008-09-27 15:08:53 cruizer

爲什麼反對票？ COM組件將減少包含併爲.NET遷移提供路徑？ – jwmiller5 2008-12-17 16:59:49

COM組件真的很難管理，更新，版本控制等。 – 2011-02-01 20:03:25

@MusiGenisis子彈點列表是從善如流，但我不同意 -

。「我不會做任何的這個套用史蒂夫·耶格（我認爲），」有沒有錯一個經典的ASP應用程序，無法通過全部重寫來修復「。我對此非常認真 - 我認爲在這個世界上，程序員的時間不會比維護ASP應用程序更浪費時間，問題只是隨着ASP越來越過時，情況變得更糟。「

一切都很好，但如果它是一個可觀的遺留應用程序做完整的重新寫入通常是不可能的，由於缺乏開發人員的時間/資源。

我們有一個相當大的經典ASP應用程序，這些應用程序多年來一直在增長手臂和腿部，這並不美觀，但確實滿足了業務需求。我們沒有時間花費接下來的六個月來完成重寫，這很好，但不可能。我們的方法是 -

在需要新功能的地方，它在ASP.NET中實現。這發生在95％的時間。 5％的邊緣情況通常是因爲新應用程序代碼觸及舊應用程序需要我們執行大量經典ASP重新工作，導致應用程序更加脆弱。
在功能發生變化的地方，我們會評估我們是否能夠以最小的影響重構ASP.NET。如果這不可行，那麼我們將在經典的ASP中實現這一改變，並整理現有的代碼。簡化包含文件嵌套，用更多的跨瀏覽器友好代碼替換JavaScript，這種事情。

在回答關於＃ifndef's的問題時，恐怕沒有等價物。

來源

2008-09-27 16:01:20 Kev

哇。它讓我驚訝地發現，有多少人對ASP抱有仇恨。在體面的手中，它是設計Web應用程序的完美語言。

但是，我會承認，在ASP中管理包含文件的方式可能有點讓人頭疼 - 因爲（取決於您如何使用它們），即使您不使用它們也必須加載和解析一半的功能包含在內。

我往往有一個包含文件（initialise.asp或類似），其本身包含指向幾個函數庫（lib_http.asp，lib_mssql.asp或類似）和所有的庫函數是自包含的，所以沒有對交叉變量擔心。任何全局變量都在主文件中聲明和設置。這意味着我可以隨時隨地使用某個功能，而不用擔心它定義在哪裏，只是在那裏使用而已。而像Visual Studio和Primalscript這樣的IDE可以在你找到一個你不認識的函數的調用時「跳到定義」。

然後，在調用此主包含文件後，腳本中包含任何腳本特定的包含。

我承認，這是一種渴望內存的方法，因爲所有庫中的所有函數都是爲每個腳本調用編譯的，所以該方法需要針對您開發的每個站點進行細化 - 決定通過主函數調用哪些include和什麼是更具體的頁面。能夠只加載你所需要的是很好的 - 但這是DLL方法，並且不適用於大多數現實世界的開發，並且你還必須權衡編譯小腳本的處理器成本和加載組件。

一個簡潔的目錄結構是必需的，很容易開發，但它可能是一件瑣碎的事情，可能會涉及現有站點中的所有代碼並更改任何鏈接或mappath調用。此外，請注意某些IIS管理員不允許通過VBScript遍歷目錄的方法，因此所有文件引用都必須是絕對路徑。

來源

2008-09-29 09:44:35

使用一個文件到全局標題和包含（讓它命名爲t-head.asp）。該文件包含在所有的asp文件中。
使用一個文件製作網站可視化全局標題（徽標，菜單等）並將其包含在後面。讓我們稱之爲t開始。asp
使用一個文件來製作站點的可視全局頁腳（版權，谷歌分析等），並關閉在t-begin.asp中打開的所有div或表格。讓我們打電話給這個文件t-end.asp
使用一個文件夾放置業務邏輯文件，稱爲BUS。該文件夾中的文件不能包含。文件中的每個函數都必須以邏輯單元的名稱開頭（IE：products.asp中的所有函數必須以product_ *開頭）
使用一個文件夾放置一些稱爲UI的重用UI代碼。該文件夾中的文件不能包含。

例子：

<%@ 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>

來源

2008-09-29 11:49:41

我不知道的方式，以避免雙重包容，比得到一個錯誤信息等。你是否看到包含在整個頁面中，這使得它們難以辨認？

就像旁邊一樣，你是在開發服務器上使用代碼和數據庫的副本嗎？根據我的經驗，首先要做的就是把你自己從現場直接分開。雖然最初的麻煩，它會給你自由做出修改而不會搞亂現場。在包含和BAM中做一個小小的改變很容易！整個網站都崩潰了。

我已經通過了幾個項目，如你所描述的工作，並使用了以下策略：

完全重寫 - 完美的，當有時間/錢，但通常我得到的電話時出了問題和結果是儘快需要的。

更小的項目 - 我打開IDE中的所有內容，並開始搜索函數/子文件的所有項目文件，以建立包含邏輯的知識。每次都差不多，每件事都隨處可見，所以我開始重新構建由業務邏輯組織的包含。我還運行了內嵌代碼（原始代碼，不是subs或函數），所以我通常會把代碼放回到頁面中以供稍後重構。

更大的項目 - 我將使用一些代碼來解析包含子/函數頭的行，並將它們轉儲到文本文件以構建哪些例程在哪裏並引用它們的列表。當你在每個頁面上有大量的包含內容，並且無法圍繞代碼庫時，這會派上用場。

來源

2008-10-01 03:02:13 user14094

重構「包含文件地獄」

回答

相關問題