ASP Classic에서 .NET으로 마이그레이션 및 문제 완화

https://stackoverflow.com/questions/31192

09-06-2019
|

문제

우리는 .NET 3.5에서 사이트의 고객 대상 섹션을 재 설계하는 중입니다. 지금까지 잘 진행되고 있으며 동일한 워크 플로와 저장 프로 시저를 사용하고 있습니다. 대부분의 경우 가장 큰 변경 사항은 UI, ORM (사전에서 LINQ로), 그리고 분명히 언어입니다. 지금까지 대부분의 페이지는 사소한 것이었지만 지금은 가장 무거운 워크 플로 페이지에서 작업하고 있습니다.

제안 수락 섹션의 기본 페이지는 1500 줄로, 그 중 약 90 %가 ASP이고, 포함 할 함수 호출에 또 다른 1000 줄이있을 것입니다. 우리가 이런 보석으로 작업하고 있기 때문에 1500 줄도 약간 속이는 것 같아요 라코 디스

지금까지 사용해온 표준 관행은 앱에 익숙해지기 위해 한 시간 정도 정도 앱을 읽고 주석 처리 된 / 더 이상 사용되지 않는 코드를 제거하는 것입니다. 그런 다음 깊이 우선 방식으로 작업합니다. 맨 위에서 시작하여 aspx.cs 파일의 코드 세그먼트를 복사하고 재 작성을 시작하여 특히 ORM을 활용하기 위해 명확한 리팩토링을 수행합니다. 우리가 가지고 있지 않은 함수 호출을 받으면 정의를 작성하겠습니다.

모든 것을 코딩 한 후 리팩토링 / 테스트를 몇 번 수행하겠습니다. 이 프로세스를 좀 더 쉽고 효율적으로 만드는 방법에 대한 팁이있는 사람이 있는지 궁금합니다.

해결책

저를 믿으세요. 저는 여러분이 어디에서 왔는지 정확히 알고 있습니다. 저는 현재 ASP 클래식에서 .NET으로 대규모 앱을 마이그레이션하고 있습니다. 그리고 저는 여전히 ASP.NET을 배우고 있습니다! : S (예, 무섭습니다!)

내가 염두에 둔 주요 사항은 다음과 같습니다.

나는 ASP 고전적인 결합의 양이 엄청나게 많기 때문에 현재의 디자인에서 멀리 벗어나지 않는다 (즉, "이 모든 것을 뜯어 내고 ASP.NET을 마법처럼 만들 수는 없다!). 당연히 자신이 있다면 부츠를 채우세요 :) 이것은 항상 나중에 리팩토링 될 수 있습니다.
테스트, 테스트 및 추가 테스트로 모든 것을 백업하세요! TDD에 들어 가려고 정말 열심히 노력하고 있지만 기존 앱을 테스트하기가 매우 어렵 기 때문에 클래식 덩어리를 제거하고 .NET으로 교체 할 때마다 가능한 한 많은 녹색 조명 테스트를 받도록합니다.

많은 연구를하세요. 클래식과 .NET 사이에 몇 가지 주요 변경 사항이 있으며 때로는 여러 줄의 코드가 될 수 있고 클래식에 포함되는 것은 몇 줄의 코드로 달성 할 수 있습니다. 생각 .. 몇 번이나 힘들게 배웠습니다 : D
코드로 Jenga 를 재생하는 것과 매우 유사합니다. :)
프로젝트에 행운을 빕니다. 질문이 더 있으면 질문 해주세요. :)

다른 팁

<인용구>

모든 것을 코딩 한 후 리팩토링 / 테스트를 몇 번 수행하겠습니다.이 프로세스를 좀 더 쉽고 효율적으로 만드는 방법에 대한 팁이 있는지 궁금합니다.

잘못했습니다

일반적으로 저는 TDD의 팬은 아니지만 리팩토링의 경우 정말 갈 길입니다.

보고있는 비트가 실제로 무엇을하고 있는지 확인하는 몇 가지 테스트를 먼저 작성하세요.그런 다음 리팩터링하십시오.이것은 단순히 '아직 작동하는 것 같습니다'보다 훨씬 더 신뢰할 수 있습니다.

이것의 또 다른 큰 이점은 페이지 아래쪽이나 공유 라이브러리 등에서 리팩토링 할 때 어려운 방법을 찾는 대신 테스트를 다시 실행할 수 있다는 것입니다.관련이없는 것처럼 보이는 변경이 실제로 관련이 있었습니다

재 작성하지 않고 기존 ASP에서 3.5를 사용하는 ASP로 전환 하시겠습니까?Skillz.일부 레거시 ASP @work를 처리해야했고 파싱하고 다시 작성하는 것이 더 쉽다고 생각합니다.

1500 줄 ASP 페이지? 파일을 포함하라는 호출이 많습니까? 말하지 마세요. 함수에는 어떤 include 파일이 구현되어 있는지 알려주는 명명 규칙이 없습니다.

당신은 꽤 확고한 접근 방식을 가지고있는 것 같습니다. 고통을 완화 할 수있는 마법적인 방법이 있는지 잘 모르겠습니다. 전환 작업 후에도 앱의 아키텍처는 여전히 지저분하고 UI가 많으며 (예 : 실행중인 워크 플로의 코드 숨김) 아마도 유지 관리가 상당히 어려울 수 있지만 수행중인 리팩토링이 확실히 도움이 될 것입니다.

앱을 너무 많이 확장 할 의도가없고 앱 유지 관리, 복잡한 워크 플로 기반 업그레이드를 주로 담당하지 않는 한 처음부터 다시 작성하는 것과 비교하여 수행중인 업그레이드의 무게를 측정했으면합니다. 당신과 같은 앱은 처음부터 다시 작성하는 것보다 저렴하고 더 나은 선택 일 수 있습니다. ASP.NET은 최소한 클래식 ASP보다 성능과 확장 성을 향상시킬 수있는 더 나은 기회를 제공해야합니다. 귀하의 질문에 따르면 어쨌든 그 논의 과정이 너무 늦었다 고 생각합니다.

행운을 빕니다!

일을 잘 처리하신 것 같습니다.나는 많은 사람들이 직선 음역을 시도하는 것을 보았습니다.ASP.Net이 클래식 ASP와 많이 다르기 때문에 ASP.Net의 작동 방식을 잘 이해하고 있어야합니다.

더 큰 파일의 경우 먼저 더 높은 수준의보기를 얻으려고합니다.예를 들어, 제가 알아 차린 한 가지는 Classic ASP가 함수 호출에 대해 끔찍하다는 것입니다.일부 코드를 읽고 구현 위치에 대한 단서가없는 함수 호출을 찾을 수 있습니다.결과적으로 클래식 ASP 코드는 이러한 불쾌한 점프를 피하기 위해 긴 함수와 스크립트를 사용하는 경향이 있습니다.40 페이지까지 출력되는 기능을 본 기억이납니다!그렇게 많은 코드를 직접 파싱하는 것은 재미가 없습니다.

ASP.Net을 사용하면 함수 호출을 쉽게 따라갈 수 있으므로 큰 코드 블록을 여러 개의 작은 함수로 분할하여 시작할 수 있습니다.

<인용구>

말하지 마세요-기능이 알려주는 명명 규칙이 파일을 포함하는 당신은 그들의 구현 ... 다시 가져옵니다 추억 (떨림) ...

어떻게 추측하셨습니까? ;) <인용구>

업그레이드에 무게를 두셨기를 바랍니다. 당신은 단지 재 작성에 반대하고 있습니다 처음부터-당신이 아닌 한 앱을 너무 많이 확장하려고 그리고 당신은 주로 책임이 없습니다 앱 유지, 업그레이드 당신과 같은 복잡한 워크 플로우 기반 앱 더 저렴하고 더 좋을 수 있습니다. 처음부터 다시 쓰는 것보다 선택. ASP.NET은 더 나은 것을 제공해야합니다 성능 향상 기회 그리고 확장 성, 적어도 클래식 ASP. 당신의 질문에서 너무 늦었다 고 상상해보십시오 어쨌든 그 토론을위한 과정.

이것은 우리가 이야기 한 내용입니다. 타이밍 (경쟁사 사이트를이기려고 시도)과 리소스 (기본적으로 두 명의 개발자)를 기반으로 궤도에서 사이트를 핵폭탄하지 않는 것이 합리적이었습니다. 실제로 예상했던 것보다 훨씬 나아졌습니다. 우리는 계획 단계부터이 코드가 우리에게 가장 큰 문제를 줄 것이라는 것을 알고있었습니다. 관련된 고전적인 ASP 페이지의 개정 내역을 볼 수 있습니다. 이것은 유혈입니다. <인용구>

더 큰 파일의 경우 먼저 더 높은 수준의보기. 예를 들면 제가 알아 차린 것은 Classic ASP는 함수 호출에 대해 끔찍했습니다. 당신은 일부 코드를 읽고 단서없이 함수 호출 찾기 어디에 구현 될 수 있는지. 그 결과 클래식 ASP 코드는 긴 기능과 스크립트를 그 불쾌한 점프를 피하십시오. 나는 기억해 인쇄 된 함수보기 40 페이지! 직접 파싱 그렇게 많은 코드는 재미가 없습니다.

실제로 레거시 코드로 작업하는 것에 대한 불만이 있었기 때문에 시스템에 대해 상당히 높은 수준의 이해를 가지고 있습니다. 함수 길이에 대해 맞습니다. 새 사이트의 aspx 페이지 / 도우미 클래스 / ORM보다 3 ~ 4 배 긴 루틴 (대부분은 훨씬 더 작은 것으로 리팩토링했습니다)이 있습니다.

예전에 ASP에서 이식 된 .Net 앱을 발견했습니다..aspx 페이지는 완전히 비어있었습니다.UI를 렌더링하기 위해 개발자는 코드 뒤에서 StringBuilder를 사용한 다음 response.write를 수행했습니다.이것은 잘못된 방법입니다!

<인용구>

전역 선언을 제외하고 페이지 뒤의 코드가 비어 있었고 VBScript가 ASPX에 남아있었습니다.

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

제휴하지 않습니다 StackOverflow