기존의 지저분한 웹앱을 우아한 MVC로 마이그레이션하는 가장 좋은 방법은 무엇입니까?[닫은]

Question

저는 한 달쯤 전에 새로운 회사에 입사했습니다.회사는 규모가 다소 작으며 "스타트업" 느낌이 꽤 강합니다.저는 3명으로 구성된 팀에서 Java 개발자로 일하고 있습니다.회사는 주로 비즈니스/비즈니스 유형의 사람들이 서로 통신하는 데 사용할 수 있는 서비스를 판매합니다.

제가 지금까지 작업했고 앞으로 작업할 주요 작업 중 하나는 회사의 기본 웹사이트입니다. 이 웹사이트에서는 서비스가 판매되고, 기존 사용자는 로그인하여 서비스를 확인하고 청구서를 지불하며, 신규 사용자는 평가판에 등록할 수 있습니다. , 등.현재 이것은 회사 자체가 작성한 지속성 계층을 통해 수행되는 데이터베이스에 대한 액세스와 함께 Tomcat에 배포된 JSP 애플리케이션입니다.

여기에서 반복적으로 점점 더 커지는 좌절감은(그리고 저는 이 일에 전반적으로 매우 만족하므로 이 글은 "아, 내 일이 마음에 들지 않습니다" 유형의 게시물이 아닙니다) 더 큰 디자인이나 디자인이 부족하다는 것입니다. 이 웹 애플리케이션의 아키텍처입니다.이 앱은 수십 개의 JSP 페이지로 구성되어 있으며 서블릿이나 Bean 또는 다른 종류의 프레임워크에는 로직이 거의 없습니다.많은 JSP 페이지는 수천 줄의 코드로 구성되어 있습니다. jsp:include 다른 JSP 페이지에서는 비즈니스 로직이 HTML과 혼합되고, 자주 사용되는 코드 조각(예: 웹 서비스 연결 획득)은 재사용되지 않고 잘라내어 붙여넣는 등의 작업을 수행합니다.즉, 응용 프로그램이 엉망입니다.

회사 내에서는 이 사이트를 MVC에 더 잘 맞도록 재설계하려는 노력이 있었습니다.내 생각에 개발자들과 고위 관계자들은 스파게티 코드의 현재 패턴이 지속 가능하지 않거나 사용자를 위해 더 많은 기능을 추가하기 위해 쉽게 확장 가능하지 않다는 것을 깨닫기 시작했다고 생각합니다.상위 관리자와 개발자는 완전히 다시 작성하는 것을 경계합니다(기존 기능을 다시 작성하는 데 몇 주 또는 몇 달이 걸릴 수 있으므로 그럴 만한 이유가 있습니다). 그러나 우리는 (천천히) 다시 작성하는 것에 대해 몇 가지 논의를 했습니다. 사이트의 특정 영역을 새로운 프레임워크에 작성합니다.

애플리케이션과 코드베이스를 이러한 방향으로 이동할 수 있는 가장 좋은 전략은 무엇입니까?개발자로서 내가 직장에 들어와 모든 사람에게 자신이 작성한 내용이 쓰레기라고 말하는 멍청한 신입생처럼 보이지 않고 이 일을 신속하게 진행하는 데 어떻게 도움을 줄 수 있습니까?이런 일을 겪었을 때 자신의 업무 경험에서 사용한 입증된 전략이나 경험이 있습니까?

Answer 1

가장 좋은 방법은 진행하면서 천천히 리팩토링하는 것입니다.너무 많은 비즈니스 규칙이 묻혀 있는 것을 처음부터 완전히 시작하는 데 필요한 리소스를 보유한 사람은 거의 없습니다.경영진은 교체한 앱보다 버그가 더 많은 앱을 개발하는 데 몇 달을 소비하는 것을 정말 싫어합니다.

별도의 앱을 처음부터 구축할 기회가 있다면 거기에 있는 모든 모범 사례를 활용하고 이를 사용하여 얼마나 효과적인지 보여주세요.가능하다면 이러한 아이디어를 점차적으로 기존 애플리케이션에 통합하세요.

Answer 2

먼저 Michael Feather의 Working 사본을 선택하세요. 레거시 코드로 효과적으로.그런 다음 기존 코드를 가장 잘 테스트하는 방법을 식별합니다.최악의 경우는 단지 높은 수준의 회귀 테스트(또는 전혀 없음)에만 갇혀 있고 운이 좋다면 단위 테스트가 있을 것이라는 것입니다.그런 다음 동시에 새로운 비즈니스 기능을 추가하는 동시에 느리고 꾸준한 리팩토링을 수행하는 경우입니다.

Answer 3

내 경험에 따르면 앱의 "우아함"은 일반적으로 무엇보다 데이터베이스 디자인과 더 관련이 있습니다.당신이 가지고 있다면 엄청난 잘 정의된 저장 프로시저 인터페이스를 포함한 데이터베이스 디자인을 사용하면 어떤 플랫폼을 사용하든 좋은 애플리케이션 코드가 따르는 경향이 있습니다.당신이 가지고 있다면 가난한 데이터베이스 디자인에서는 어떤 플랫폼을 사용하든 데이터베이스에 대해 지속적으로 보상을 해야 하기 때문에 우아한 애플리케이션 코드를 구축하는 데 매우 어려움을 겪게 됩니다.

물론 사이에는 공간이 충분합니다. 엄청난 그리고 가난한, 하지만 내 요점은 좋은 애플리케이션 코드를 원한다면 데이터베이스가 제대로 작동하는지 확인하는 것부터 시작해야 한다는 것입니다.

Answer 4

이미 '작동' 중인 항목을 다시 작성하는 것이 가치가 있다고 경영진을 설득하기 어렵기 때문에 유지 관리 모드에만 있는 애플리케이션에서는 수행하기가 더 어렵습니다.나는 여러분이 작업할 수 있는 모든 새로운 코드에 MVC의 원칙을 적용하는 것부터 시작하겠습니다.비즈니스 로직을 모델과 유사한 것으로 옮기고 모든 레이아웃/뷰 코드를 한 곳에 두십시오)

MVC의 새로운 코드에 대한 경험이 쌓이면 기존 코드도 일치하도록 미묘하게 변경할 수 있는 기회를 볼 수 있습니다.매우 느린 프로세스일 수 있지만 이러한 방식의 이점을 보여줄 수 있다면 다른 사람들을 설득하고 전체 팀을 동참시킬 수 있을 것입니다.

Answer 5

나는 느린 리팩토링 접근 방식에 동의합니다.예를 들어 복사하여 붙여넣은 코드를 적절한 Java 패러다임(클래스, 아마도?)에 추출합니다.아니면 기존 라이브러리를 사용하는 것이 더 낫습니까?).코드가 매우 깨끗하고 간결하지만 전반적인 아키텍처 전략이 여전히 부족한 경우 그 다음에 전체 아키텍처에 훨씬 더 쉽게 맞출 수 있습니다.

Answer 6

가장 좋은 방법은 코드를 인쇄해서 구겨서 버리는 것입니다.종이를 재활용하지도 마세요.

1,000줄 이상의 JSP로 작성된 애플리케이션이 있습니다.그것은 아마도 끔찍한 도메인 모델을 가지고 있을 것이고(만약 그것이 하나라도 있다면) 프레젠테이션과 비즈니스 로직을 혼합하는 것이 아니라 그것을 혼합하고 거기 앉아서 몇 시간 동안 계속 저어줍니다.형편없는 코드를 꺼내서 MVC 컨트롤러 클래스로 이동하고 여전히 옳은 일을 할 수 있는 방법은 없습니다. 빈약한 도메인 모델이나 데이터베이스 호출과 같은 기능이 있는 MVC 앱으로 끝날 것입니다. 컨트롤러 코드에서는 여전히 실패하고 있습니다.

올바른 작업을 수행하는 새로운 앱을 사용해 본 다음 두 앱이 서로 통신하도록 할 수 있지만 이는 그 자체로 새로운 복잡성입니다.또한 처음부터 시작했을 때와 동일한 양의 작업을 수행하게 될 가능성이 높지만 이것이 더 나은 접근 방식이라고 상사를 설득하는 것이 더 쉬울 수도 있습니다.

Answer 7

반복적으로 리팩터링합니다.또한 새 프레임워크의 가치를 보여주는 방법으로 새 ​​프레임워크에서 완전히 수행할 수 있는 새로운 기능을 찾아보세요.

Answer 8

내 제안은 다른 JSP를 가져올 필요가 없거나 가져오기가 거의 없는 희귀한 페이지를 찾는 것입니다.가져온 각 JSP를 블랙박스로 처리하고 해당 페이지를 중심으로 이러한 페이지를 리팩토링합니다(반복적으로 각 변경 사항을 테스트하고 계속하기 전에 작동하는지 확인).이러한 항목이 정리되면 최종적으로 가져오기를 리팩토링할 때까지 점점 더 많은 가져오기가 포함된 페이지를 계속 찾을 수 있습니다.

리팩토링 시 페이지에 제공되지 않은 리소스에 액세스하려고 시도하는 부분을 기록하고 이를 컨트롤러로 가져가려고 합니다.예를 들어, 데이터베이스에 액세스하는 모든 것은 컨트롤러 내부에 있어야 하며 컨트롤러가 전달을 통해 제공하는 정보의 표시를 JSP가 처리하도록 해야 합니다.이러한 방식으로 각 페이지에 대해 여러 서블릿 또는 서블릿과 같은 것을 개발하게 됩니다.이 리팩토링을 위해 전면 컨트롤러 기반 프레임워크를 사용하는 것이 좋습니다(개인 경험으로는 Spring과 해당 컨트롤러 인터페이스를 권장함). 그러면 각 컨트롤러가 별도의 서블릿이 아니라 적절하게 매핑된 단일 서블릿에서 위임됩니다.

컨트롤러의 경우 데이터베이스 적중을 단편적으로 시도하는 것보다 한 번에 모두 수행하는 것이 좋습니다.사용자는 일반적으로 페이지 로드를 허용할 수 있지만 렌더링 코드가 중단되어 클라이언트가 다른 페이지를 읽으려고 하는 동안 데이터를 제공하지 않는 대신 모든 데이터베이스 데이터가 렌더링 코드에 제공되면 페이지 출력이 훨씬 빨라집니다. 데이터베이스의 데이터 조각.

나는 당신의 고통을 느끼며 이 노력에 행운이 있기를 바랍니다.이제 Spring Webflow를 남용하는 애플리케이션을 유지해야 한다면 이는 또 다른 이야기가 됩니다. :)