레거시 애플리케이션에서 코 히어 런트 아키텍처 시작

대규모 Asp.Net 기반 웹 사이트에 대한 책임이 있습니다. 현재 웹 사이트 (웹 응용 프로그램 아님), 일부 Windows 서비스 및 여러 클래스 라이브러리입니다.

데이터 계층은 리팩토링되지 않은 레거시 인라인 SQL의 인스턴스뿐만 아니라 LLBLGEN 과 Linq To LLBGen 의 혼합을 사용합니다 .

일부 관리자 유형 구현이 있지만 대부분의 경우 응용 프로그램은 Smart UI 안티 패턴을 나타냅니다 (예 : 클래스 뒤 코드에서 너무 많은 비즈니스 논리)

사이트의 트래픽은 합리적으로 높고 성능은 좋지만 개발 능력은 약 10 명으로 증가하고 있으며, 기존 미들웨어 위에는 계층화 된 디자인이 필요하다는 것이 점점 분명 해지고 있습니다.

내 질문은 어디서부터 시작해야합니까? 우리는 10 년의 코드 (일부는 여전히 실제로 ASP Classic에서 마이그레이션 한 것), 다양한 접근 방식 및 스타일을 가지고 있습니다.

전체 코드베이스를 리팩토링하는 것은 현실적이지 않으며 아마도 바람직 하지 않습니다.

나는 이것이 새로운 상황이 아니라는 것을 알고 있습니다.이 문제에 접근하는 방법에 대한 유용한 아이디어 나 개념이 있습니까?

나는 비슷한 상황에서 일하고 있으며 다음과 같은 조언을 해줄 수 있습니다.

1. 기술 부채 를 줄여야 합니다. 지금. 왜? 기술 부채는 금융 부채와 같습니다. 당신은 그것에 관심을 지불 할 것입니다.
2. 전체 코드베이스를 리팩토링하는 것은 불가능하기 때문에 스스로에게 물어보십시오. 단순히 너무 많은 일입니까? 왜?
3. 기술 부채를 적시에 줄일 계획을 세우십시오. 예를 들어, 규칙을 " 팀이 만지는 모든 코드는 새로운 표준으로 수정 / 리팩터링 "해야합니다. 일반적으로 단위 테스트를 작성하고 코드를 올바른 레이어로 이동해야합니다. 이렇게하면 엄청나게 비싸고 저렴한 "리팩토링"프로젝트에 의존하지 않고 많은 코드를 수정할 수 있습니다.
4. 쓰레기를 감싸십시오. 디커플링과 아키텍처의 핵심은 디커플링입니다. 코드베이스를 어떻게 든 분할 할 수 있다면 더 작은 비트를 리팩토링 할 수 있습니다.
5. 기술 부채를 더 늘리지 마십시오. 기술 부채를 더 늘리지 마십시오. 기술 부채를 더 늘리지 마십시오. 하지 마라...

전체 코드베이스를 리팩토링하는 것은 바람직하지 않습니다. 리팩토링은 개발을 더 매끄럽게 만들기 위해 새로운 개발에 앞서 수행하는 작업입니다. 코드베이스의 모든 코드를 수정하지 않으려는 경우 리팩토링은 비효율적 인 시간 사용을 증명할 것입니다.

Sklivvz가 말한 것 외에도 몇 가지 조언 :

1. 코드를 자주 수정하고 자주 수정되지 않는 섹션으로 구분하십시오. 자주 수정되는 섹션 만 새 아키텍처로 완전히 가져와야합니다. 가능한 한 적은 변경 사항을 사용하거나 변경하지 않는 경우 변경 사항을 사용하지 않고 자주 수정되지 않은 코드를 새 아키텍처와 통합하십시오. 전체 다시 쓰기의 유혹에 저항하십시오. 기존 코드가 추악하더라도 작동한다는 것을 이해하십시오.

2. 리팩토링 목표가 무엇인지 알아보십시오. 사이트에 컨텐츠를 쉽게 가져올 수 있도록 하시겠습니까? 많은 버그가 있고 사용자 인식 품질을 향상 시키려고합니까? 기능 개발 시간을 줄이고 싶습니까? 아니면 주로 더 나은 UX를 원하십니까? 아키텍처는 설정 한 목표를 달성하기 위해 코드를 쉽게 리팩토링해야합니다. 리팩토링의 주요 수혜자는 사용자 / 고객 / 비즈니스 여야 함을 잊지 마십시오. 더 깨끗한 코드는 그 자체로는 목표가 아니며, 목적을 달성하기위한 방법이며, 목적은 사용자를 포함합니다.

3. 가능한 한 많은 참조 아키텍처를 찾아서 복사하는 것을 두려워하지 마십시오. 바퀴를 재발 명하지 마십시오. 다른 사람이 자신과 같은 사이트에 적합한 아키텍처를 가지고 있다면 배우십시오.

4. 사람들의 관리 측면에 대해 생각하십시오. 내 자신의 마이그레이션 프로젝트에서 가장 어려운 부분은 사람들이 새로운 방식을 배우고 고수하도록 만드는 것이 었습니다. 참조 구현과 팀의 모든 사람에게 (구식과 신식 모두에게) 아키텍처를 가르치는 방법이 필요합니다. 변화에 대한 저항을 줄이려면 의사 결정을하기 전에 팀의 모든 사람의 의견을 구하십시오. 새로운 디자인이 실제로 개발자의 개인적인 관점에서 사물을 향상시키고 깊이를 느끼지 않는 큰 도약이 아닌지 확인하십시오.

오래된 코드베이스를 처리하려고 할 때 가장 많이 본 것은 촬영 대상을 계속 변경하지 않는 것입니다. 즉, 원하는 아키텍처를 파악한 다음 계획을 세우십시오! 내 마지막 입장에서 큰 문제 중 하나는 코드베이스가 시간이 지남에 따라 어떻게 보일지에 대한 여러 가지 아이디어를 가지고 있다는 것입니다. 새로운 아이디어가 시도 될 때마다 일부 코드는 변환되었고, 일부는 변환되지 않았으며, 다른 누군가는 '더 나은'아이디어를 가졌습니다. 시간이 지남에 따라 점점 일관성이 떨어지고 결국 폐기되었습니다.

레거시 소프트웨어 리엔지니어링에 대한 훌륭한 무료 서적 / pdf가 있습니다 : http://scg.unibe.ch/download/oorp/

제목에는 OO가 있지만 대부분의 아이디어는 모든 소프트웨어에 적용됩니다. 구조 조정 중 시스템의 다른 부분을 처리하는 방법과 그 밖의 주제를 다루는 방법에 대해 설명합니다.

일관성있는 아키텍처가없는 경우 경영진이 문제를 이해 / 관리하지 않기 때문입니다. 코드 만 작성하면됩니다. 새 코드를 작성할 때 새 아키텍처를 도입해야합니다.

실제로 심각한 버그가 발생하기 시작하거나 확장 할 수 없거나 요구 사항에 맞지 않는 경우에만 아키텍처를 다시 설계해야합니다.

나는 기본적으로 관리자가 실제로 관심을 갖는 문제에 대해서만 관심을 기울이고 있으며, 지식이 있으면 관심을 가질만한 문제는 아닙니다.

재건축을 경영진에게 판매 할 수 있다면 테스트부터 시작하십시오. 그들이 테스트에 투자하고 싶지 않다면, 당신의 노력은 문제를 일으킬 것입니다.