기능이 너무 긴 경우는 언제입니까? [닫은]

35 줄, 55 줄, 100 줄, 300 줄? 언제 분해해야합니까? 나는 60 줄 (주석 포함)이있는 기능을 가지고 있기 때문에 묻고 그것을 분리하는 것에 대해 생각하고있었습니다.

long_function(){ ... }

으로:

small_function_1(){...}
small_function_2(){...}
small_function_3(){...}

함수는 long_function 외부에서 사용되지 않으므로 더 작은 함수를 만들면 더 많은 함수 호출 등을 의미합니다.

함수를 더 작은 함수로 분리 할 때는 언제입니까? 왜?

1. 메소드는 하나의 논리적 인 일만해야합니다 (기능에 대해 생각하십시오)
2. 한 문장으로 방법을 설명 할 수 있어야합니다
3. 디스플레이 높이에 맞아야합니다.
4. 불필요한 오버 헤드를 피하십시오 (명백한 설명은 ...)
5. 작은 논리 기능에 대한 단위 테스트가 더 쉽습니다.
6. 다른 클래스 나 메소드가 함수의 일부를 재사용 할 수 있는지 확인
7. 클래스 간 과도한 커플 링을 피하십시오
8. 깊이 중첩 된 제어 구조를 피하십시오

답변에 대해 모두 감사 합니다. 목록을 편집 하고 정답 에 투표하십시오.

나는 그 아이디어를 염두에두고 리팩토링하고 있습니다 :)

그것에 대한 진짜 어렵고 빠른 규칙은 없습니다. 일반적으로 나는 "한 가지 일"을하는 방법을 좋아한다. 따라서 데이터를 가져 와서 해당 데이터로 무언가를 한 다음 디스크에 쓰는 경우, 잡아서 분리하고 별도의 방법으로 쓰면 "주요"방법에 "뭔가"가 포함됩니다.

"뭔가를하는"것은 여전히 ​​몇 줄이 될 수 있으므로 여러 줄이 올바른 메트릭인지 확실하지 않습니다. :)

편집 : 이것은 지난 주 직장에서 우송 한 한 줄의 코드입니다 (요점을 증명하기 위해. : 그것은 습관이 아닙니다 :))-나는 내 방법 으로이 나쁜 소년들 중 50-60을 원하지 않을 것입니다 :디

return level4 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3) && (r.Level4 == (int)level4)).ToList() : level3 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3)).ToList() : level2 != null ? GetResources().Where(r => (r.Level2 == (int)level2)).ToList() : GetAllResourceList();

다음은 함수가 너무 길다는 것을 나타내는 빨간색 플래그 (특별한 순서가 아님) 목록입니다.

1. 깊게 중첩 된 제어 구조 : 예를 들어 복잡한 조건을 가진 중첩 된 if 문으로 for-loops 3 레벨 깊이 또는 심지어 2 레벨 깊이.

2. 상태 정의 매개 변수가 너무 많음 : 상태 정의 매개 변수로 , 함수를 통한 특정 실행 경로를 보장하는 함수 매개 변수를 의미합니다. 이러한 유형의 매개 변수를 너무 많이 얻으면 조합 경로가 엄청나게 커집니다 (일반적으로 # 1과 함께 발생 함).

3. 다른 방법으로 복제 된 논리 : 코드 재사용이 불량하면 모 놀리 식 절차 코드에 크게 기여합니다. 이러한 논리 중복 은 매우 미묘 할 수 있지만 일단 리팩토링되면 최종 결과는 훨씬 더 우아한 디자인이 될 수 있습니다.

4. 과도한 클래스 간 커플 링 : 적절한 캡슐화가 없기 때문에 다른 클래스의 친밀한 특성과 관련된 기능으로 인해 기능이 길어집니다.

5. 불필요한 오버 헤드 : 명확하게 중첩 된 클래스, 전용 중첩 클래스 변수에 대한 불필요한 게터 및 세터 및 비정상적으로 긴 함수 / 변수 이름을 나타내는 주석은 모두 관련 함수 내에 구문 적 노이즈를 생성하여 결국 길이를 늘릴 수 있습니다.

6. 거대한 개발자 급 디스플레이는 그것을 표시하기에 충분히 크지 않습니다 : 실제로 오늘날의 디스플레이는 높이에 가까운 곳의 기능이 너무 길어질 정도로 충분히 큽니다. 그러나 그것이 더 크면 이것은 잘못된 것입니다.

7. 즉시 함수의 목적을 확인할 수 없습니다 : 실제로 한 번 더 나아가, 어떻게 당신은 하나의 문장이 목적을 요약하거나 엄청난 두통이 일어날 수없는 경우, 그 목적을 결정,이 단서해야한다.

결론적으로, 모 놀리 식 함수는 광범위한 결과를 가져올 수 있으며 종종 주요 설계 결함의 증상입니다. 읽는 것이 절대적으로 즐거운 코드를 발견 할 때마다 우아함이 즉시 드러납니다. 그리고 무엇을 추측하십시오 : 함수의 길이 는 종종 매우 짧습니다.

이 페이지에서 "한 가지 일만"만트라에 큰 경고가 있다고 생각합니다. 때때로 한 가지 일을하는 것은 많은 변수를 저글링합니다. 작은 함수가 긴 매개 변수 목록을 갖는 경우 긴 함수를 여러 개의 작은 함수로 나누지 마십시오. 그렇게하면 단일 함수가 실제 개별 값이없는 고도로 결합 된 함수 세트로 바뀝니다.

함수는 한 가지만 수행해야합니다. 함수에서 작은 일을 많이하는 경우에는 각각의 작은 일을 함수로 만들고 long 함수에서 해당 함수를 호출하십시오.

당신이 정말 하지 않는 원하는 것은 복사 할과 (당신의 예에서 알 수 있듯이) 짧은 기능으로 당신의 긴 기능의 매 10 개 라인을 붙여 넣습니다.

함수가 한 가지만 수행해야한다는 데 동의하지만 그 한 수준은 어느 정도입니까?

60 라인이 (프로그램 관점에서) 한 가지를 달성하고 60 라인을 구성하는 조각이 다른 것에 의해 사용되지 않는다면 60 라인은 괜찮습니다.

자체적으로 콘크리트 조각으로 나눌 수 없다면 그것을 깨는 데 실질적인 이점은 없습니다. 사용할 메트릭은 코드 라인이 아닌 기능입니다.

필자는 저자가 단 한 가지를 극한 수준으로 끌어 올리는 많은 프로그램을 연구했으며 결국 누군가가 수류탄을 함수 / 방법에 가져간 것처럼 보이게하고 수십 개의 연결되지 않은 조각으로 만들었습니다. 따라 가기 어렵다.

해당 기능을 꺼낼 때 불필요한 오버 헤드를 추가하고 대량의 데이터를 전달하지 않도록 고려해야합니다.

중요한 점은 그 긴 기능에서 재사용 성을 찾고 그 부분을 꺼내는 것입니다. 남은 것은 10 줄, 20 줄 또는 60 줄의 길이에 관계없이 기능입니다.

60 줄은 크지 만 기능에 비해 너무 길지 않습니다. 편집기에서 한 화면에 맞으면 한 번에 볼 수 있습니다. 실제로 기능이 수행하는 작업에 따라 다릅니다.

왜 기능을 깨뜨릴 수 있습니까?

• 너무 깁니다
• 코드를 분해하고 새로운 기능에 의미있는 이름을 사용하여 코드를 유지 관리하기 쉽게 만듭니다.
• 이 기능은 응집력이 없습니다
• 기능의 일부는 그 자체로 유용합니다.
• 기능에 대한 의미있는 이름을 제시하기 어려운 경우 (아마도 너무 많은 일을하고 있음)

내 개인적인 휴리스틱은 스크롤하지 않고 모든 것을 볼 수 없으면 너무 길다는 것입니다.

크기는 대략 스크린 크기입니다 (그래서 큰 피벗 와이드 스크린을 가져 와서 돌리십시오) ... :-)

농담은 제쳐두고 기능 당 하나의 논리적 인 것입니다.

그리고 긍정적 인 점은 단위 테스트가 하나의 작업을 수행하는 작은 논리 함수로 수행하기가 훨씬 쉽다는 것입니다. 많은 일을하는 큰 기능은 확인하기 어렵습니다!

/ 요한

경험 법칙 : 함수가 무언가를 수행하는 코드 블록을 포함하고 있다면, 나머지 코드와 다소 분리되어 있으면 별도의 함수에 넣으십시오. 예:

function build_address_list_for_zip($zip) {

    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

훨씬 더 좋은 :

function fetch_addresses_for_zip($zip) {
    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }
    return $addresses;
}

function build_address_list_for_zip($zip) {

    $addresses = fetch_addresses_for_zip($zip);

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

이 방법에는 두 가지 장점이 있습니다.

1. 특정 우편 번호에 대한 주소를 가져와야 할 때마다 즉시 사용 가능한 기능을 사용할 수 있습니다.

2. 함수를 build_address_list_for_zip()다시 읽어야 할 경우 첫 번째 코드 블록이 수행 할 작업을 알고 있습니다 (최소한 함수 이름에서 파생 할 수있는 특정 우편 번호의 주소를 가져옵니다). 쿼리 코드를 인라인으로두면 먼저 해당 코드를 분석해야합니다.

[반면에, (고문 아래서도 이것을 말하지는 않겠다) : PHP 최적화에 대해 많이 읽으면 함수 호출이 매우 작기 때문에 함수 수를 최대한 작게 유지하는 아이디어를 얻을 수 있습니다. PHP에서 매우 비쌉니다. 나는 벤치 마크를 한 적이 없기 때문에 그것에 대해 모른다. 이 경우 응용 프로그램이 "성능에 민감한"응용 프로그램 인 경우 질문에 대한 답변을 따르지 않는 것이 좋습니다. ;-)]

"그래프의 각 노드는 흐름이 순차적이고 호는 프로그램에서 취한 분기에 해당하는 프로그램의 코드 블록에 해당합니다. "

이제 코드에 함수 / 방법이 없다고 상상해보십시오. 그래프 형태의 코드가 엄청나게 늘어납니다.

이 스프롤을 메소드로 나누고 싶습니다. 그렇게 할 때 각 방법마다 일정한 수의 블록이있을 것입니다. 각 방법 중 하나의 블록 만 다른 모든 방법에 표시됩니다. 첫 번째 블록 (첫 번째 블록에서는 한 지점에서만 메서드로 이동할 수 있다고 가정합니다). 각 메소드의 다른 모든 블록은 해당 메소드 내에 숨겨진 정보이지만 메소드 내의 각 블록은 해당 메소드 내의 다른 블록으로 잠재적으로 이동할 수 있습니다.

메소드 당 블록 수와 관련하여 메소드의 크기를 결정하려면 한 가지 질문이 있습니다. 모든 블록 사이의 최대 잠재적 종속성 수 (MPE)를 최소화해야하는 방법은 몇 개입니까?

그 대답은 방정식으로 주어집니다. r이 시스템의 MPE를 최소화하는 방법의 수이고 n이 시스템의 블록 수인 경우 방정식은 다음과 같습니다. r = sqrt (n)

그리고 이것은 메소드 당 블록의 수를 sqrt (n)로 나타냅니다.

리팩토링을 위해서만 리팩토링을 수행하여 코드를 처음부터 읽을 수 없게 만들 수 있습니다.

이전 동료는 함수 / 메소드에 4 줄의 코드 만 포함해야한다는 기괴한 규칙을 가지고있었습니다! 그는이 방법을 너무 엄격하게 고수하려고했는데 그의 분석법 이름은 종종 반복적이고 의미가 없어졌고 호출은 깊이 중첩되어 혼란스러워졌습니다.

그래서 내 자신의 진언이되었습니다 : 리팩토링하는 코드 청크에 대한 적절한 함수 / 메소드 이름을 생각할 수 없다면 귀찮게하지 마십시오.

내가 일반적으로 함수를 분해하는 주된 이유는 비트와 그 조각이 내가 작성하는 다른 인근 함수의 구성 요소이기 때문에 공통 부분이 제거되기 때문입니다. 또한 다른 클래스에서 많은 필드 또는 속성을 사용하는 경우 관련 청크를 도매로 해제하고 가능한 경우 다른 클래스로 옮길 수 있습니다.

맨 위에 주석이있는 코드 블록이있는 경우, 함수와 인수 이름이 목적을 나타내는 코드 블록을 함수로 가져와 코드의 근거를 위해 주석을 예약하십시오.

다른 곳에서 유용한 조각이 없습니까? 어떤 종류의 기능입니까?

내 생각에 대답은 : 너무 많은 일을 할 때입니다. 함수는 함수 이름 자체에서 예상되는 동작 만 수행해야합니다. 고려해야 할 또 다른 사항은 함수의 일부를 다른 부분에서 재사용하려는 경우입니다. 이 경우 분할하는 것이 유용 할 수 있습니다.

나는 보통 다음 코드 블록을 설명하는 주석을 달아야 할 필요가있다. 이전에 주석에 들어간 내용은 이제 새로운 함수 이름으로 들어갑니다. 이것은 어려운 규칙은 아니지만 좋은 경험입니다. 의견이 필요한 코드보다 코드 자체를 더 잘 말하는 코드가 좋습니다 (주석은 일반적으로 거짓말이라는 것을 배웠습니다)

이것은 부분적으로 맛의 문제이지만, 이것을 결정하는 방법은 화면에 한 번에 (최대) 맞을 때까지만 대략 기능을 유지하려고합니다. 모든 것을 한 번에 볼 수 있다면 무슨 일이 일어나고 있는지 이해하기가 더 쉽기 때문입니다.

코딩 할 때 긴 함수를 작성 한 다음 다른 함수에서 재사용 할 수있는 비트를 꺼내기 위해 리팩토링을 수행하고 개별 작업을 수행하는 작은 함수를 작성합니다.

나는 이것에 대한 옳고 그른 대답이 있다는 것을 모른다. (예를 들어, 최대 67 줄을 정할 수 있지만 몇 개 더 추가하는 것이 합리적 일 수 있습니다).

가장 적은 버그를 원한다면 코드가 너무 길어서는 안됩니다. 그러나 너무 짧아서는 안됩니다.

메소드가 하나의 디스플레이에 맞는다는 데 동의하지 않지만 한 페이지 이상 아래로 스크롤하면 메소드가 너무 깁니다.

자세한 내용 은 객체 지향 소프트웨어의 최적 클래스 크기를 참조하십시오 .

전에 500 라인 함수를 작성했지만 메시지 디코딩 및 응답을위한 큰 스위치 명령문이었습니다. 단일 메시지의 코드가 단일 if-then-else보다 복잡해지면 추출했습니다.

본질적으로 기능은 500 줄이지 만 독립적으로 유지되는 영역의 평균은 5 줄입니다.

나는 보통 코드 작성에 테스트 주도 방식을 사용합니다. 이 방법에서 함수 크기는 종종 테스트 세분성과 관련이 있습니다.

테스트의 초점이 충분히 맞으면 테스트를 통과하기위한 작은 초점 기능을 작성하게됩니다.

이것은 다른 방향으로도 작동합니다. 기능을 효과적으로 테스트하려면 충분히 작아야합니다. 따라서 레거시 코드로 작업 할 때 종종 더 큰 함수를 분류하여 다른 부분을 테스트한다는 것을 알았습니다.

나는 보통 "이 기능의 책임은 무엇인가"를 묻고, 간결하고 간결한 문장으로 책임을 진술 할 수 없다면 작은 집중 테스트로 번역 할 수 있다면, 그 기능이 너무 큰지 궁금합니다.

분기가 3 개 이상인 경우 일반적으로 분기 논리를 다른 방법으로 캡슐화하기 위해 함수 또는 메서드를 분리해야합니다.

각 for 루프, if 문 등은 호출 메소드에서 분기로 표시되지 않습니다.

Java 코드 용 Cobertura (및 다른 언어를위한 다른 도구가 있다고 확신합니다)는 각 함수의 함수에서 if 등의 수를 계산하고이를 "평균 순환 복잡성"으로 합산합니다.

함수 / 메소드에 분기가 3 개만있는 경우 해당 메트릭에서 3 개를 얻게되므로 매우 좋습니다.

때때로이 지침을 따르는 것이 어렵습니다. 즉, 사용자 입력의 유효성을 검사하기위한 것입니다. 그럼에도 불구하고 분기를 다른 방법으로 배치하면 개발 및 유지 관리뿐만 아니라 테스트에도 도움이됩니다. 분기를 수행하는 방법에 대한 입력을 쉽게 분석하여 분기를 커버하기 위해 테스트 케이스에 어떤 입력을 추가해야하는지 확인할 수 있기 때문입니다. 커버되지 않았다.

모든 브랜치가 단일 분석법에 포함 된 경우 분석법이 시작된 이후 입력을 추적해야하므로 테스트 성이 방해됩니다.

나는 당신이 이것에 대해 많은 대답을 찾을 것이라고 생각합니다.

아마도 함수 내에서 수행되고있는 논리적 작업을 기반으로 분류했을 것입니다. 당신의 짧은 이야기가 소설로 변하고 있다고 생각되면, 나는 분명한 단계를 찾아서 추출하는 것이 좋습니다.

예를 들어, 일종의 문자열 입력을 처리하고 문자열 결과를 반환하는 함수가있는 경우 문자열을 부분으로 나누는 논리, 추가 문자를 추가하는 논리 및이를 삽입하는 논리에 따라 함수를 분리 할 수 ​​있습니다. 서식이 지정된 결과로 다시 다시 연결됩니다.

요컨대, 코드를 깨끗하고 읽기 쉽게 만드는 것은 무엇이든 간단히 함수에 주석을 달거나 분리하는 것이 가장 좋은 방법입니다.

한 가지 일을한다고 가정 하면 길이는 다음에 따라 다릅니다.

• 당신이하고있는 일
• 사용중인 언어
• 코드에서 처리해야하는 추상화 수준

60 줄이 너무 길거나 정확할 수 있습니다. 그래도 너무 길다고 생각합니다.

한 가지 (그리고 함수 이름에서 분명히 드러나야 함), 코드에 관계없이 한 번의 코드 만 넘지 않아야합니다. 글꼴 크기를 자유롭게 늘리십시오. 의심스러운 경우 두 개 이상의 기능으로 리팩토링하십시오.

밥 아저씨의 트윗의 정신을 잠시 연장하면 두 줄의 코드 사이에 빈 줄을 넣어야 할 때 함수가 너무 길어지는 것을 알 수 있습니다. 아이디어는 코드를 분리하기 위해 빈 줄이 필요하면 그 시점에서 책임과 범위가 분리된다는 것입니다.

내 생각은 그것이 너무 길다면 나 자신에게 물어봐야 할지도 모른다는 것이다. 응용 프로그램 수명주기 후반에 도움이 될 수 있으므로이 영역에서 더 작은 기능을 만드는 데 도움이됩니다.