Refactororing "파일 포함"

https://stackoverflow.com/questions/143745

02-07-2019
|

문제

ASP 클래식 프로젝트의 코드베이스 속도를 높이기 위해 인생이 어려워지는 한 가지는 파일 포함 상황이 일종의 혼란이라는 것입니다. 때로는 완전히 관련이없는 포함 파일에 포함 된 기능을 찾습니다. 기능을 찾아야 할 경우 기능이 어디에 있는지 더 쉽게 알 수 있도록이를 리팩터링하는 방법에 대한 조언이 있습니까?

편집하다: 내가 묻는 것을 잊어 버린 한 가지 : vbscript에 파일이 두 번 포함되는 것을 방지하기위한 어떤 종류의 메커니즘이 있습니까? #ifndef 's From C?

해결책

클래식 ASP 응용 프로그램을 인수 할 때 할 수있는 몇 가지 기본 사항이 있지만 아마도 그 일을 후회하게 될 것입니다.

중복 포함 파일을 제거하십시오. 내가 본 모든 클래식 ASP 앱에는 5 개의 "login.asp"페이지와 7 "datepicker.js"파일 등이 있습니다. 모든 복제물을 사냥하고 제거한 다음 필요에 따라 앱의 나머지 부분에서 참조를 변경하십시오. 제거 할 때 각 파일에서 Diff 확인을주의하십시오. 종종 복제 된 파일은 원래 작성자가 복사 한 다음 사본 만 변경했기 때문에 약간의 차이가 있습니다. 이것은 진화에게는 좋은 일이지만 코드에는 그리 많지 않습니다.
합리적인 폴더 구조를 만듭니다 그리고 모든 파일을 그것으로 이동하십시오. 이것은 분명하지만, 당신이 가장 후회할 것입니다. 응용 프로그램의 링크가 상대적이든 절대적이든, 대부분의 링크를 변경해야합니다.
모든 포함 파일을 하나의 큰 파일로 결합하십시오.. 그런 다음 모든 기능을 논리적으로 다시 주문하고 별도의 현명하게 이름 지정된 파일로 나눌 수 있습니다. 그런 다음 페이지별로 앱 페이지를 방문하여 각 페이지에 포함 된 문장이 무엇인지 파악해야합니다 (또는 하나의 파일을 사용하고 모든 페이지에 포함시킵니다. ASP의 좋은 생각입니다). 나는 여기에 관련된 통증 수준을 이해할 수 없으며, 기존 포함 파일이 동성 글로벌을 크게 사용하지 않는다고 가정합니다.

나는 이것을하지 않을 것이다. Steve Yegge를 역설하기 위해 (생각합니다), "총 재 작성로 수정할 수없는 클래식 ASP 응용 프로그램에는 아무런 문제가 없습니다.". 나는 이것에 대해 매우 진지합니다 - 나는 ASP 앱을 유지하는 것 보다이 세상에서 프로그래머의 시간을 낭비한다고 생각하지 않으며, ASP가 점점 더 오래 걸리면 문제가 악화됩니다.

다른 팁

@musigenisis Bullet Point 목록은 따라야 할 좋은 조언이지만 동의하지 않을 것입니다.

"나는 이것을하지 않을 것입니다. Steve Yegge를 역설하기 위해 (나는 생각합니다),"전체 재 작성로 고칠 수없는 클래식 ASP 응용 프로그램에는 아무런 문제가 없습니다. " '이 세상에서 ASP 앱을 유지하는 것보다 프로그래머의 시간 낭비가 더 크다고 생각하며 ASP가 점점 더 오래 걸리면 문제가 악화됩니다. "

모두 매우 잘하지만, 개발자 시간/자원이 부족하여 완전한 재 작성을 수행하는 상당한 레거시 앱이라면 종종 불가능합니다.

우리는 수년에 걸쳐 팔과 다리가 자란 상당히 큰 클래식 ASP 앱을 보유하고 있습니다. 예쁘지는 않지만 비즈니스 요구에 부응합니다. 우리는 다음 6 개월 동안 완전한 재 작성을 할 시간이 없지만 좋을 것입니다. 우리의 접근 방식은 -

새로운 기능이 필요한 경우 ASP.NET에서 구현됩니다. 이것은 시간의 95%가 발생합니다. 5% 에지 케이스는 일반적으로 새로운 앱 코드가 오래된 앱에 닿는 많은 포인트가 있다는 것입니다.
기능이 변경되는 경우 최소한의 영향으로 ASP.NET에 리팩터를 리팩터링 할 수 있는지 평가합니다. 이것이 불가능하다면, 우리는 클래식 ASP의 변경을 구현하고 기존 코드를 정리하기를 간단하게 진행할 때 우리는 파일 중첩을 단순화하고, 더 많은 크로스 브라우저 친화적 코드로 JavaScript를 대체하는 것입니다.

#ifndef에 대한 귀하의 질문에 대한 답변으로, 동등한 것은 없습니다.

글로벌 제목에 하나의 파일을 사용하고 포함하십시오 (t-head.asp를 이름으로 지정하십시오). 이 파일은 모든 ASP 파일에 포함되어 있습니다.
하나의 파일을 사용하여 사이트 시각적 글로벌 헤더 (로고, 메뉴 등)를 만들고 바로 뒤에 포함시킵니다. t-begin.asp라고 부릅니다
하나의 파일을 사용하여 사이트를 Visual Global 바닥 글 (저작권, Google 웹 로그 분석 등)으로 만들고 t-begin.asp에 열린 모든 div 또는 테이블을 닫습니다. 이 파일 t-end.asp를 호출하자
하나의 폴더를 사용하여 버스라는 비즈니스 로직 파일을 넣으십시오. 이 폴더의 파일에는 포함 할 수 없습니다. 파일 내부의 모든 기능은 로직 유닛의 이름으로 선행되어야합니다 (즉, 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>

우와. 얼마나 많은 사람들이 ASP에 대한 증오를 가지고 있는지 끊임없이 놀라게합니다. 괜찮은 손에 그것은 웹 응용 프로그램을 설계하기에 완벽하게 유능한 언어입니다.

그러나 ASP에서 파일을 포함하는 방법은 약간의 뇌실이 될 수 있음을 인정할 것입니다. (사용 방법에 따라) 포함 된 기능의 절반을 사용하지 않더라도로드하고 구문 분석해야하기 때문입니다. 이내에.

파일을 포함하는 경향이 있습니다 (initialise.asp 또는 여러 기능 라이브러리에 대한 링크가 포함 된 그러한 것 (일부) (lib_http.asp, lib_mssql.asp 또는 이와 유사) 및 모든 라이브러리 기능은 자체 포함되므로 교차 변수에 대해 걱정할 필요가 없습니다. 모든 글로벌 VAR은 마스터 파일로 선언되고 설정됩니다. 즉, 언제 어디서나 기능을 사용할 수 있으며 어디에서나 정의 된 위치에 대해 걱정하지 않으며 사용하기 위해서만 있습니다. Visual Studio 및 Primalscript와 같은 IDE는 인식하지 못하는 기능을 호출 할 때 "정의로 점프"할 수 있습니다.

그런 다음이 스크립트 별 포함 내용은이 마스터에 대한 호출 후 파일을 포함한 후 스크립트에 포함됩니다.

모든 라이브러리의 모든 기능이 모든 스크립트 호출에 대해 컴파일되므로 이것은 메모리 헝가리 접근법임을 인정하므로,이 방법은 개발 한 각 사이트에 대해 정제해야합니다. -특정한. 필요한 것을로드 할 수있는 것이 좋을 것입니다. 그러나 이것이 DLL 접근 방식이며 대부분의 실제 개발에 대해 사용할 수 없으며 소규모 스크립트 대 컴파일하는 프로세서 비용을 평가해야합니다. 로딩 구성 요소.

간결한 디렉토리 구조는 필수적이고 쉽게 개발되었지만 기존 사이트의 모든 코드를 통해 링크를 변경하거나 링크 또는 Mappath 호출을 변경할 수 있습니다. 또한 일부 IIS 관리자는 '..\' vbscript를 통한 디렉토리를 가로 지르는 방법이므로 모든 파일 참조는 절대 경로 여야합니다.

코드를 ASP vbscript에서 Visual Basic Com DLL으로 이동하는 것을 고려해야한다고 생각합니다. 그것은 너무 많은 포함을 가지고있는 당신에게 편한 것입니다.

오류 메시지를받는 것 외에는 이중 포함을 방지하는 방법을 모릅니다. 당신은 페이지 전체에 배치 된 것을 포함하여 그것을 발견하기가 어렵습니까?

옆으로, 개발 서버의 코드 사본과 데이터베이스를 사용하고 있습니까? 내 경험에서 가장 먼저해야 할 일은 살아있는 사이트와 최대한 빨리 자신을 분리하는 것입니다. 처음에는 번거 로움이 있지만 라이브 사이트를 엉망으로 만들지 않고 자유롭게 변경할 수 있습니다. 포함과 BAM에서 작은 변화를 쉽게 만드는 것은 쉽습니다! 전체 사이트가 다운됩니다.

나는 당신이 설명하고 다음 전략을 사용했던 것과 같은 몇 가지 프로젝트를 수행했습니다.

완전한 재 작성 - 시간/돈이있을 때 완벽하지만 일반적으로 무언가 잘못되었을 때 전화를 받고 결과가 빨리 필요합니다.

소규모 프로젝트 - IDE의 모든 것을 열고 포함 논리에 대한 지식을 구축하기 위해 Functions/Sub의 모든 프로젝트 파일을 검색하기 시작합니다. 거의 매번 모든 것이 어디에나 퍼져 나가기 때문에 비즈니스 로직으로 구성된 포함을 재건하기 시작합니다. 또한 Inline Code (Subs 또는 Functions가 아닌 RAW 코드)을 통해 실행되므로 포함 된 상태로 실행되므로 나중에 리팩토링을 위해 코드를 페이지로 다시 가져옵니다.

더 큰 프로젝트 - 하위/기능 헤더가있는 라인에 포함 된 포함을 구문 분석하기 위해 주위에 놓은 코드를 사용하고 텍스트 파일에 덤프하여 어디에 있는지 목록을 작성하고 참조 할 것입니다. 이것은 각 페이지에 수많은 포함이 있고 코드베이스 주위에 머리를 얻을 수 없을 때 편리합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow