사람들이 왜 메소드의 #region 태그에 강력하게 반대합니까?

나는 메소드를 짧게 유지하는 것에 대해 많은 것을 듣고 많은 프로그래머들이 메소드 내에서 #region 태그를 사용하는 것이 너무 길어서 여러 메소드로 리팩토링되어야한다는 확실한 신호라고 들었다. 그러나 메소드 내에서 #region 태그로 코드를 분리하는 것이 여러 메소드로 리팩토링하는 우수한 솔루션 인 경우가 많이 있습니다.

계산을 세 개의 별개의 단계로 분리 할 수있는 방법이 있다고 가정합니다. 또한 이러한 각 단계는 이 방법 의 계산에만 관련 되므로 새로운 방법으로 추출하면 코드를 재사용 할 수 없습니다. 그렇다면 각 단계를 자체 방법으로 추출하면 어떤 이점이 있습니까? 내가 알 수있는 한, 우리가 얻는 모든 것은 가독성과 각 단계에 대한 별도의 가변 범위입니다 (특정 단계의 수정이 실수로 다른 단계를 파괴하지 않도록 도와줍니다).

그러나 각 단계를 자체 방법으로 추출하지 않고도이 두 가지를 달성 할 수 있습니다. 지역 태그를 사용하면 코드를 읽을 수있는 형식으로 축소 할 수 있으며 (코드를 확장하고 검사하기로 결정한 경우 더 이상이 파일에서 자리를 떠날 필요가 없다는 추가 이점이 있음) 각 단계를 {}작업 할 자체 범위를 만듭니다.

이 방법으로 얻는 이점은 실제로 네 번째 방법의 내부 작업에만 관련된 세 가지 방법으로 클래스 수준 범위를 오염시키지 않는다는 것입니다. 긴 메소드를 일련의 짧은 메소드로 즉시 리팩토링하는 것은 조기 최적화와 동등한 코드 재사용과 같습니다. 많은 경우에 발생하지 않는 문제를 해결하기 위해 추가 복잡성을 도입하고 있습니다. 나중에 코드 재사용 기회가 발생하면 언제든지 단계 중 하나를 자체 방법으로 추출 할 수 있습니다.

생각?

신경 써야 할 것은 코드를 재사용 할 수있는 것이 아니라 사용하는 것입니다. 수행해야 할 변환이있는 경우 원숭이는 사용 가능한 코드를 재사용 가능한 코드로 변환 할 수 있습니다.

"나는 여기서 만 필요하다"라는 주장은 가난하다. 설명하는 기술을 헤드 라인 기술 이라고하며 일반적으로 눈살을 찌푸립니다.

1. 영역을 테스트 할 수는 없지만 실제 메서드를 격리하여 테스트 할 수 있습니다.
2. 영역은 구문 요소가 아닌 주석입니다. 최악의 경우 지역과 블록의 중첩은 서로 모순됩니다. 항상 사용하는 언어의 구문 요소를 사용하여 구조의 의미를 나타내도록 노력해야합니다.
3. 메소드를 리팩토링 한 후에는 더 이상 텍스트를 읽기 위해 접기가 필요하지 않습니다. 터미널, 메일 클라이언트, VCS 웹보기 또는 diff-viewer와 같이 접지 않는 도구에서 소스 코드를보고있을 수 있습니다.
4. 방법으로 리팩토링 한 후 결과 방법은 최소한 영역에서만큼 우수하며 개별 부품을 이동하는 것이 더 간단합니다.
5. 단일 책임 원칙 (Single Responsibility Principle)은 모든 부서에 하나의 작업과 하나의 작업 만 있어야한다고 제안합니다. "main"메소드의 임무는 "helper"메소드를 작성하여 원하는 결과를 얻는 것입니다. "도우미 (helper)"방법은 분리 된 이산적이고 간단한 문제를 해결합니다. 이러한 모든 메소드를 포함하는 클래스는 하나의 태스크 만 수행하고 해당 태스크와 관련된 메소드 만 포함해야합니다. 따라서 도우미 메서드는 클래스 범위에 속하거나 코드가 처음에는 클래스에 없어야하지만 적어도 일부 전역 메서드에 있거나 더 나은 방법으로 삽입 되어야합니다 .

관련성 : 코드 폴딩에 대한 Jeff Atwoods의 생각

문제가되는 메소드의 영역이 아니라 메소드를 영역에 넣을 필요가있는 경우입니다.

200-300 라인 메소드를 많이 디버깅해야 했으므로 다른 사람에게 원하지 않는다고 말할 수 있습니다. 자신의 코드를 작성하고 돌보고 있다면 괜찮습니다. 원하는대로하십시오. 그러나 일단 다른 사람이 그것을 본 후에는 방법이 무엇을하고 있는지 즉시 분명해야합니다.

"먼저 물건을 얻은 다음 주변을 지저분하게하고, 윙윙 거리는 소리가 필요한 경우, 그렇지 않으면 파란색인지 확인하고 코페르니쿠스 값을 반전시킵니다. 그런 다음 두 번째 것이 첫 번째 것보다 크면 주스 상자를 가져 와서 삽입해야합니다 ... "

아니요, 충분하지 않습니다. 원하는 모든 영역으로 나누지 만 생각하면서 여전히 머리를 흔들고 있습니다.

메소드를 분석하면 많은 이점이 있습니다.

• 방법의 이름을 통해서도 발생하는 상황에 대한 명확한 이해. 그리고 당신은 잘못된 방법이 완전히 문서화 할 수 없음 - 문서 블록 (히트를 추가 ///)하고, 설명, 매개 변수, 반환 유형을 입력하고, 또한 exception, example, remarks세부 사항에 그 시나리오를 노드. 그것이 어디로 가고, 그것이 바로 그 일입니다!
• 부작용이나 범위 지정 문제가 없습니다. 을 사용하여 하위 범위에서 모든 변수를 선언한다고 말할 수도 {}있지만 '속임수'가 아닌지 확인하려면 모든 방법을 확인해야합니까? 이다 dodgyObject나는이 지역에서 사용되는 유일한 때문에 여기에 사용하고, 또는 다른 곳에서 왔는가? 내가 내 방법을 사용했다면 그것이 나에게 전달되었는지 또는 내가 직접 만들 었는지 (또는 오히려 만들 었는지) 쉽게 알 수 있습니다.
• 내 이벤트 로그에 예외가 발생한 메소드가 나와 있습니다. 예, 행 번호로 문제가되는 코드를 찾을 수 있지만 메소드 이름 (특히 이름을 올바르게 지정한 경우)을 아는 것은 무슨 일이 있었는지 그리고 무엇이 잘못되었는지. "오, TurnThingsUpsideDown방법이 실패했습니다-아마도 나쁜 것을 돌리는 동안 실패했을 것입니다"는 "오, DoEverything방법이 실패했습니다-50 가지가 있었을 수 있습니다. .

이것은 모든 재사용 성 또는 즉흥성 문제 이전입니다. 적절하게 분리 된 메소드는 재사용을 용이하게하고, 수행하지 않는 메소드 (너무 느리고 버그가 많으며 종속성 변경 등)를 쉽게 대체 할 수 있습니다. 이 거대한 방법 중 하나를 리팩토링 해 본 적이 있습니까? 변경하는 내용이 다른 영향을 미치지 않는다는 것을 알 방법이 없습니다.

논리를 합리적인 크기의 방법으로 올바르게 캡슐화하십시오. 나는 그들이 쉽게 벗어날 수 있다는 것을 알고 있으며, 그 시점에서 한 번 다시 디자인 할 가치가 없다고 주장하는 것이 또 다른 문제입니다. 하지만 당신은 거기에 전혀 해를 끼치없고 적어도 사실에 동의해야합니다 잠재적 제대로 캡슐화하는 데에서 이익을 깨끗하게 작성하고 간단하게 방법을 설계합니다.

분석법이 3 개의 개별 단계로 분리 될 수있을 정도로 복잡하다면, 그것들은 3 개의 분리 된 방법 일뿐 아니라, 실제로 그 계산에 전념하는 별도의 클래스 여야합니다.

"하지만 그때 내 수업에는 단 하나의 공개 방법이 있습니다!"

당신 말이 맞아요, 아무 문제가 없습니다. 단일 책임 원칙의 아이디어는 수업이 한 가지 일을한다는 것 입니다.

클래스는 세 가지 메소드 각각을 차례로 호출하고 결과를 리턴 할 수 있습니다. 한가지

보너스로 이제는 더 이상 개인용 메서드가 아니기 때문에 메서드를 테스트 할 수 있습니다.

그러나 한 클래스를 신경 쓰지 마십시오 . 실제로 네 가지 가 있어야합니다 : 메소드의 각 조각마다 하나씩, 세 가지 각각을 종속성으로 가져 와서 올바른 순서로 호출하여 결과를 반환하는 것.

이를 통해 수업을 더욱 테스트 할 수 있습니다. 또한이 세 가지 중 하나를 쉽게 변경할 수 있습니다. 이전 클래스에서 상속받은 새 클래스를 작성하고 변경된 동작을 대체하십시오. 또는 세 조각 각각의 동작에 대한 인터페이스를 작성하십시오. 하나를 대체하려면 해당 인터페이스를 구현하는 새 클래스를 작성하고 종속성 주입 컨테이너 구성에서 이전 클래스를 대체하십시오.

뭐? 의존성 주입을 사용하지 않습니까? 글쎄, 당신은 아마도 단일 책임 원칙을 따르지 않기 때문에 아마도 필요성을 보지 못했을 것입니다. 일단 시작하면, 각 클래스에 종속성을 부여하는 가장 쉬운 방법은 DI 컨테이너를 사용하는 것입니다.

편집 :

좋아, 리팩토링 질문을 따로하자. 목적은 #region코드를 숨기는 것인데, 이는 일반적으로 일반적인 상황에서 편집 할 필요가없는 코드를 의미합니다. 생성 된 코드 가 가장 좋은 예입니다. 일반적으로 편집 할 필요가 없으므로 영역에 숨겨져 있어야합니다. 필요한 경우 지역을 확장하면 "용이 될 것"스타일의 경고 메시지가 표시됩니다.

그러므로 내가 말을 #region해야 하지 하는 방법의 중간에 사용. 메소드를 열면 코드를보고 싶습니다. #region을 사용하면 필자가 필요하지 않은 또 다른 수준의 숨김이 생겨서 문제가됩니다. 메서드를 펼치면 여전히 코드를 볼 수 없습니다.

사람들이 메소드의 구조를보고 걱정하고 리팩토링 거부하는 경우 다음과 같이 배너 주석을 추가하십시오.

//
// ---------- COMPUTE SOMETHING OR OTHER ----------
//

이를 통해 코드를 탐색하는 사람이 #region태그 확장 및 축소를 처리하지 않고도 메소드의 개별 부분을 볼 수 있습니다.

나는 당신이 주장하는 예가 YAGNI (당신이 그것을 필요로하지 않을 것)에 관한 것이 아니라 쉽게 유지할 수있는 적절한 품질 코드를 작성하는 것에 관한 것이라고 생각합니다.

가장 초기의 프로그래밍 과정에서 우리는 방법이 700 LOC 길이라면 아마도 너무 커서 아마도 시도하고 디버깅하는 데 큰 고통이 될 것임을 배웁니다.

둘째, 방법 D 내에서만 사용되는 방법 A, B 및 C를 작성하면 D와 독립적으로 AB 및 C를 더 쉽게 단위 테스트 할 수 있으므로 4 가지 방법 모두에서보다 강력한 단위 테스트가 가능합니다.

계산을 세 개의 별개의 단계로 분리 할 수있는 방법이 있다고 가정합니다. 또한 이러한 각 단계는이 방법의 계산에만 관련되므로 새로운 방법으로 추출하면 코드를 재사용 할 수 없습니다. 그렇다면 각 단계를 자체 방법으로 추출하면 어떤 이점이 있습니까? 내가 알 수있는 한, 우리가 얻는 모든 것은 가독성과 각 단계에 대한 별도의 가변 범위입니다 (특정 단계의 수정이 실수로 다른 단계를 파괴하지 않도록 도와줍니다).

두 가지 이점이 있습니다. 그러나 어쨌든 중요한 것은 디버깅 가능성 입니다. 해당 코드를 추적해야하는 경우 세 섹션 중 두 섹션을 넘어서서 관심있는 섹션 만 추적하는 것이 훨씬 간단합니다. 더 작은 방법으로 리팩토링하면 가능합니다. 지역 태그는 그렇지 않습니다.

내 개인적인 규칙은 방법이 하나의 화면보다 길면 (40 줄) 너무 길다는 것입니다. 수업이 500 줄보다 길면 너무 큽니다. 때때로이 규칙을 때로는 여러 번으로 나누기도하지만 일반적으로 1 년 안에 후회합니다.

대부분의 경우 20 ~ 30 줄의 방법조차 조금 길어지고 있습니다. 따라서 메소드에서 영역을 사용하는 것은 일반적으로 나쁜 생각입니다. 단순히 20 ~ 30 줄의 영역을 여러 하위 영역으로 축소하는 것은 의미가 없기 때문입니다.

이 정의로 긴 함수를 분류하면 두 가지 이상의 이점이 있습니다.

1. 이러한 하위 기능이 수행하는 작업에 이름을 지정하면 현재 생각을 명확하게하고 이후 관리자의 작업을 단순화 할 수 있습니다.

2. 더 작은 함수로 분해하면 더 작은 함수에 필요한 매개 변수 만 전달해야하므로 필요한 데이터 범위와 수정 범위는 매우 명확합니다. 이것은 당신이 백 가지 다른 리프 함수에서 객체 상태에 액세스하고 수정하지 않는다고 가정합니다.

내 경험상 이러한 규칙은 일반적인 실수없이 작성하기 쉬우 며 미묘한 동작을 중단하지 않고 나중에 이해하고 수정할 수있는 코드를 만듭니다. 코드를 이해 / 수정 해야하는 사람이 다른 사람이거나 내가 모든 것을 잤고 잊어 버린 사람인지 여부는 중요하지 않습니다.

따라서 방법의 영역은 지속 불가능한 관행이 적용되고 있음을 나타내는 "코드 냄새"라고 생각합니다. 언제나 그렇듯이 예외 가 있을 수는 있지만 거의 논의 할 가치가없는 경우가 드물게 발생합니다.

우리는 다시 간다 ... 여기 에 같은 토론으로 끝난 프로그래머 들에 대한 다른 많은 주제가 있습니다 .

짧은 함수와 관련된 매우 흥미로운 주장을 지적합니다. 그것은 대중적인 진술이 아니지만, 나는 이것에 당신과 함께 있습니다 . 이전에 자주 논의한 후에는 일반적으로 적절한 캡슐화에 초점을 맞추는 지 테스트 중심 개발을 최대한 활용하는지에 대한 논의가 시작된다고 생각합니다. 이것들은 또 다른 거룩한 전쟁으로 판명되는 것처럼 보이는 두 가지 주요 경쟁자이며, 우리가 힘이 약한쪽에 있다고 두려워합니다.

그러나 ...

내 생각에 해결책은 분명히 지역의 '단계'를 감싸지 않습니다. 코드 폴딩은 깔개 밑의 코드를 청소하는 데 사용됩니다. 코드를 그대로 두십시오. 나중에 리팩토링하고 싶을 수도 있습니다. 그것을 질문의 주장과 관련 짓기 위해 : 코드가 보이지 않으면 어떻게 코드 재사용 기회를 볼 수 있습니까? 코드의 긴 세그먼트는 정확히 리팩터링하려는 눈의 가시입니다.

지역을 적절히 대체하기 위해 Alex Papadimoulis 가 주석에 이름을 붙일 때 코드 단락 을 사용하는 것이 좋습니다 . 실제로 이미 비슷한 접근법을 사용 중일 수 있습니다. 주석 헤더가있는 코드 블록으로 전체 블록의 기능을 설명합니다. 함수를 읽을 수는 있지만 일반적으로 간격이있는 영어 문장을 사용할 수 있으며 캡슐화를 잃지 않습니다.

일반적으로을 사용하는 것보다 코드를 리팩터링하는 것이 낫다는 데 동의하지만 #region항상 가능하지는 않습니다.

그 진술을 뒷받침하기 위해 예를 들어 보겠습니다.

class Foo : IComparable
{
  private String name;
  private int foo;
  private Bar bar;

  public int CompareTo(Foo other)
  {
#region Ascending on name
     if (this.name < other.name) return -1;
     if (this.name > other.name) return 1;
#endregion
#region Usual order on bar
     int compBar = bar.compareTo(other.bar);
     if (compBar != 0) return compBar;
#endregion
#region Descending on foo
     if (this.foo > other.foo) return -1;
     if (this.foo < other.foo) return 1;
#endregion
     return 0; // equal
  }

순서를 변경하거나 추가 필드가 클래스에 추가 될 때 확장하기 위해 영역을 쉽게 조정할 수 있습니다. 어쨌든 주문이 어떻게 작동하는지 신속하게 보려면 주석이 필요합니다. 그리고 무엇보다도 :이 경우 리팩토링이 가독성에 어떻게 도움이되는지 알지 못합니다.

그러나 이러한 예외는 거의 없습니다. 일반적으로 다른 답변들과 마찬가지로 리팩토링도 가능합니다.

왜 특정 사람들이나 팀이 사용하지 않기로 결정했는지에 대한 답이 하나도 없다고 생각 #region하지만 몇 가지를 나열해야한다면 이것이 내가 본 가장 큰 이유 일 것입니다.

• 지역의 이름과 순서는 코드의 순서와 구성을보다 명확하게하여 경합 및 자전거 흘림의 원인이 될 수있는 특정 스타일을 적용합니다.
• 대부분의 개념은 소수의 영역에 정확하게 맞지 않습니다. 일반적으로 액세스 수정 자 public , private 다음 멤버 유형 (예 : 메서드, 속성, 필드) 으로 영역으로 시작 하지만 해당 수정 자에 해당하는 생성자, 이러한 모든 정적 요소, 보호 멤버, 내부 멤버, 보호 된 내부 멤버, 암시 적 인터페이스 멤버, 이벤트 등입니다. 결국 세분화 된 분류로 인해 각 지역에 단일 또는 메서드가있는 가장 잘 설계된 클래스를 갖게됩니다.
• 실용성을 유지할 수 있고 사물을 3 ~ 4 개의 고유 한 유형의 영역으로 만 그룹화하면 효과가있을 수 있지만 실제로 어떤 가치가 추가됩니까? 클래스를 잘 디자인하고 있다면 실제로 코드 페이지를 살펴볼 필요가 없습니다.
• 위에서 언급했듯이 영역이보기 흉한 코드를 숨겨서 문제보다 덜 문제가 될 수 있습니다. 눈의 통증을 유지하면 문제를 해결하는 데 도움이 될 수 있습니다.