더 이상 사용되지 않는 코드를 제거하는 모범 사례는 무엇입니까?


9

더 이상 사용되지 않는 방법을 단계적으로 제거해야합니다. [Obsolete]속성을 알고 있습니다. Microsoft에 권장 모범 사례 가이드가 있습니까?

내 현재 계획은 다음과 같습니다.

A. 개발자가 프로젝트에 새로운 참조를 추가해야하기 때문에 새 어셈블리를 만들고 싶지 않으며,이를 수행해야하는 경우 상사와 동료로부터 많은 슬픔을 얻을 것으로 예상됩니다. 또한 여러 어셈블리 버전을 유지 관리하지 않습니다. 최신 버전 만 사용합니다. 이 방법을 변경하려면 배포 프로세스를 변경해야합니다. 이는 큰 문제입니다 (FinalBuilder 대신 TFS로 작업을 수행하고 FinalBuilder를 포기하도록하는 방법을 사람들에게 가르쳐야 함).

B. 오래된 방법을 쓸모없는 것으로 표시하십시오.

C. 구현이 변경되고 있기 때문에 (메소드 서명이 아님) 오버로드를 만드는 대신 메소드의 이름을 바꿔야합니다. 따라서 사용자에게 적절한 방법을 알리기 위해 [Obsolete]속성에 메시지를 추가 할 계획 입니다. 내가하고있는 유일한 변경 사항은 연결 문자열에서 메소드를 분리하는 것이므로이 부분이 나를 귀찮게합니다. 그러나 새 어셈블리를 추가하지 않기 때문에이 문제를 해결할 방법이 없습니다.

결과:

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

답변:


5

Microsoft는 [obsolete] 특성을 사용하여 개발자에게 메서드, 속성 또는 클래스가 더 이상 사용되지 않으며 향후 릴리스에서 변경되거나 전혀 지원되지 않을 수 있음 을 알려줍니다 .

이를 통해 사용자에게 API의 기능이 "퇴거"하고 있음을 알리고 향후 소프트웨어 릴리스에서 해당 참조를 제거 할 수있는 릴리스주기가 최소한 한 번 있습니다.

원래 기능을 유지하는 기간은 전적으로 귀하에게 달려 있습니다. 개발자가 이전 기능에 비해 새로운 기능을 사용하도록 "강력히 권장"하려면 제거주기를 한 번만 추가하면됩니다. 이전 버전과의 호환성을 영구적으로 유지하려는 경우 영구적으로 유지할 수 있습니다.

Brian이 지적했듯이 기본 구현 만 변경하고 메소드 서명은 변경하지 않는 경우이 작업을 전혀 수행하지 않아도됩니다.


Microsoft의 관행은 일반적으로 다음 주요 릴리스에서 더 이상 사용되지 않는 것을 제거하는 것입니다. 반대로 Java는 더 이상 사용되지 않는 것을 제거하지 않으므로 사용자에게 달려 있습니다.
Scott C Wilson

우리는 응용 프로그램 수준 (많은 솔루션을 가진 1 개의 거대한 응용 프로그램)을 넘어서는 어셈블리를 버전 화하지 않습니다. 주어진 어셈블리에 의존하는 솔루션 수가 정의되지 않았다는 사실과 이것을 결합하십시오. 잘 모르는 응용 프로그램을 테스트 할 수 없습니다. 그러나 내가 모르는 응용 프로그램이 손상되도록 변경하면 ... 잘못 내 잘못입니다. 이것이 내가 방법의 이름을 바꾸는 이유입니다. 그래서 내가 지금까지 읽은 것으로부터 이것에 대해 더 좋은 방법은 없습니다.
P.Brian.Mackey

4

구현이 변경되고 있기 때문에 (메소드 서명이 아님) 오버로드를 만드는 대신 메소드의 이름을 바꿔야합니다.

이해가 안 돼요 구현이 변경되었지만 서명이 변경되지 않은 경우 왜 이렇게 하시겠습니까? "이전"메소드가 새롭고 개선 된 구현을 사용하도록하십시오. 이 API를 사용하는 모든 개발자는 기존의 메소드 호출에 대해 정확히 동일한 서명이 생성되고 사용 중단 경고가 표시되는 메소드를 보게 될 것입니다. (이것이 API에서 일어난 시간을 생각할 수 있습니까?)

이 메소드의 기본 구현 변경이 작동하는지 확실하지 않은 경우 구현 변경 전후에 단위 테스트로 동작을 확인하십시오.


좋은 이상입니다. 문제는 테스트 하네스가 없다는 것입니다. 그것은 내가 해결하기를 희망하는 또 다른 문제입니다. 따라서 통합 테스트가 없으므로 권장 사항을 수행 할 수 없습니다. 아직 테스트되지 않은 아직 정의되지 않은 결함이 너무 많습니다.
P.Brian.Mackey

내가 테스트를 언급 한 이유는 API를 소비하는 사람들이 테스트를 수행하고 두 호출 사이의 문제를 파악하는 데 도움이되기를 원했기 때문입니다. 최선의 선택은 코드를 사용하는 개발자를 불에 태우고 새로운 구현을 사용하게하고 철저한 QA를 수행하거나 자체 테스트를하기를 희망하는 것 같습니다.
brian

나는 내 자신을 불에 던질 것이다. 오히려 내가 게시 한 원래 코드를 고수하고 싶습니다. 그렇게하면 아무도 오전 3시에 전화해서 왜 생산 코드가 깨 졌는지 궁금해하지 않습니다. 그런 다음 개발자가 경고 플래그를 겪고 고칠 때 코드 노후화를 해결해야합니다. 그들이 그 시점에서 그것을 고치지 않으면 연결 문자열이 경고 플래그를 수리하지 않은 결함이 생길 때 실패합니다.
P.Brian.Mackey

새 코드를 작성할 때마다 문제가 발생할 위험이 있습니다. 테스트를 통해 두려워하지 않고 리팩토링 할 수 있습니다. 두려움은 마음을 죽이는 사람입니다. 게다가 당신은 피할 수없는 것을 늦추고 있습니다; 그들은 지금부터 몇 번의 반복에서 전화에 "2"를 추가하고 작동하지 않으면 동일한 전화를받을 것입니다.
brian
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.