레거시 코드를 효과적으로 사용하는 데있어 중요한 점은 무엇입니까? [닫은]

레거시 코드로 효과적으로 작업하기 책 이 몇 번 권장되는 것을 보았습니다 . 이 책의 핵심은 무엇입니까?

단위 / 통합 테스트를 추가 한 다음 리팩토링하는 것보다 레거시 코드를 처리하는 데 더 많은 것이 있습니까?

레거시 코드의 주요 문제점은 테스트가 없다는 것입니다. 따라서 일부를 추가해야합니다 (그리고 더 ...).

@mattnz가 지적했듯이 이것은 자체적으로 많은 작업이 필요합니다. 그러나 레거시 코드의 특별한 문제는 테스트 할 수 있도록 설계되지 않았다는 것입니다 . 따라서 일반적으로 스파게티 코드의 복잡한 혼란은 단위 테스트를 위해 작은 부품을 분리하는 것이 매우 어렵거나 완전히 불가능합니다. 따라서 단위 테스트 전에 코드 를 더 리팩토링하여 테스트 할 수 있도록해야합니다 .

그러나 안전하게 리팩토링하려면 변경 사항으로 인해 아무런 문제가 없는지 확인하기위한 단위 테스트 가 있어야합니다 . 이것은 레거시 코드의 핵심입니다.

이 책은 첫 번째 단위 테스트를 가능하게하기 위해 코드를 최소한의, 가장 안전하게 변경하여이 문제를 해결하는 방법을 알려줍니다. 이것들은 디자인을 더 좋게 만드는 것이 아니라 단위 테스트를 가능하게하기위한 것입니다. 실제로, 때로는 디자인이 더 나쁘거나 복잡해집니다. 그러나 테스트를 작성할 수 있으며 단위 테스트가 완료되면 디자인을 더 자유롭게 만들 수 있습니다.

코드를 테스트 할 수 있도록하는 많은 트릭이 있습니다. 일부는 명백하고 일부는 전혀 아닙니다. 책을 읽지 않고는 내가 생각한 적이없는 방법이 있습니다. 그러나 더 중요한 것은 Feathers 가 코드 단위를 정확하게 테스트 할 수있게 만드는 이유를 설명한다는 것 입니다. 의존성을 줄이고 코드에 장벽을 도입해야하지만 두 가지 이유가 있습니다.

• 감지 -코드 실행의 영향을 확인하고 확인하기 위해
• 분리 -먼저 특정 코드를 테스트 하네스로 가져 오기 위해.

의존성을 안전하게 절단하는 것은 까다로울 수 있습니다. 인터페이스, 모의 및 의존성 주입을 소개 하는 것은 목표로 깨끗하고 훌륭합니다.이 시점에서 반드시 안전하지는 않습니다. 따라서 때때로 우리는 일반적으로 DB에 직접 요청을 시작하는 몇 가지 메소드를 무시하기 위해 테스트중인 클래스를 서브 클래스 화해야합니다. 다른 경우에는 테스트 환경에서 종속성 클래스 / jar를 가짜 클래스로 바꿔야 할 수도 있습니다 ...

나에게 깃털이 가져 오는 가장 중요한 개념은 솔기 입니다. 이음새는 코드 자체를 수정하지 않고 프로그램의 동작을 변경할 수있는 코드의 한 장소입니다 . 코드에 이음새를 작성하면 테스트중인 코드를 분리 할 수 있지만 직접 수행하기 어렵거나 불가능한 경우에도 테스트중인 코드의 동작 을 감지 할 수 있습니다 (예 : 호출이 다른 객체 또는 하위 시스템을 변경하기 때문에) 테스트 방법 내에서 직접 쿼리 할 수없는 상태).

이 지식을 통해 가장 복잡한 코드 더미에서 테스트 가능성의 씨앗을 발견하고 최소한의 방해가되지 않는 가장 안전한 변경 사항을 찾을 수 있습니다. 다시 말해, 눈에 띄지 않고 코드를 깨뜨릴 위험이있는 "명확한"리팩토링을 피하는 것 입니다. 아직 이를 감지하기위한 단위 테스트가 없기 때문 입니다.

레거시 코드를 효과적으로 사용 하는 핵심 요점을 얻는 빠른 방법

• 책 2 년 전에 작성된 Michael Feathers의 12 페이지 PDF를 읽으십시오 .
• Michael Feathers의 프레젠테이션 : 68 개 슬라이드
• Michael Feathers와의 팟 캐스트 인터뷰를 듣습니다. 예를 들어이 30 분 Hanselminutes 에피소드 .

저는 수백만 줄의 코드로 코드 작업을했으며 일부는 1980 년대로 거슬러 올라갑니다. 소프트웨어 일 뿐이므로 몇 가지 단위 테스트를 작성하기 만하면됩니다. 따라서 리팩터링하여 리팩터링하여 훨씬 향상시킬 수 있습니다.

여기서 핵심 단어는 단지-레거시 시스템에서 일하는 사람은 물론 프로그래머의 어휘에 속하지 않는 4 글자 단어입니다.

1 시간 분량의 개발 노력을 테스트하기 위해 단위 테스트를 작성하는 데 얼마나 걸립니까? 토론을 위해 한 시간 더 이야기합시다.

20 만년 된 레거시 시스템에 얼마나 많은 시간이 투자됩니까? 20 년 동안 20 시간에 2000 시간 / 연간 20 명의 개발자가 있다고 가정 해 봅시다. 이제 새로운 컴퓨터와 새로운 도구를 가지고 있고 처음에 $ % ^^을 (를) 썼던 사람들보다 훨씬 영리합니다. 10 대 가치가 있다고합시다. 당신은 40 남자 년을 가지고 있습니까?

따라서 귀하의 질문에 대한 답변은 훨씬 더 있습니다. 예를 들어, 1000 줄의 루틴 (5000 개가 넘는 행이 있음)은 지나치게 복잡하며 스파게티 조각입니다. 100 줄의 루틴과 20 줄의 도우미로 리팩토링하는 데 며칠이 걸릴 것입니다. 잘못된. 그 1000 줄에는 100 개의 버그 수정이 숨겨져 있으며 각각은 문서화되지 않은 사용자 요구 사항 또는 모호한 경우입니다. 원래 100 줄 루틴이 작업을 수행하지 않았기 때문에 1000 줄입니다.

"마음 이 나지 않으면 고치지 마십시오 "라는 마음가짐으로 작업해야합니다 . 고장이 났을 때, 고칠 때 실수로 다른 것을 바꾸지 않도록 조심해야합니다. "broke"에는 시스템과 사용에 따라 유지 관리 할 수 ​​없지만 올바르게 작동하는 코드가 포함될 수 있습니다. "내가 망쳐 서 악화 시키면 어떻게 될까?"라고 물어보십시오. 언젠가는 당신이 상사에게 상사에게 왜 그렇게했는지 말해야하기 때문입니다.

이 시스템은 항상 더 나아질 수 있습니다. 당신은 일을 할 수있는 예산과 일정을 가질 것입니다. 당신이하지 않으면-가서 하나를 만드십시오. 시간과 돈이 다 ​​떨어지면 더 나은 상태를 유지하지 마십시오. 기능을 추가하고 조금 더 나아질 시간을 내십시오. 버그 수정-다시 약간의 시간을 투자하여 더 나아지게하십시오. 처음 시작할 때보 다 더 나쁘게 전달하지 마십시오.

이 책에서 가져 가야 할 두 가지 핵심 사항이 있습니다.

1. 레거시 코드는 테스트 범위가없는 코드입니다.
2. 레거시 코드를 변경해야 할 때마다 적용 범위가 있는지 확인해야합니다.

다른 응답자들이 지적했듯이 기존 레거시 코드를 사전에 업데이트하려고 시도하는 것은 바보의 일 입니다. 대신 새 기능이나 버그 수정을 위해 레거시 코드를 변경해야 할 때마다 레거시 상태를 제거하십시오.

간단히 말해서 테스트와 리팩토링을 추가하는 것이 전부입니다.

그러나이 책은 안전하게 테스트하고 리팩토링하기 매우 어려운 코드를 사용하여 다양한 기술을 제공합니다.