35 줄, 55 줄, 100 줄, 300 줄? 언제 분해해야합니까? 나는 60 줄 (주석 포함)이있는 기능을 가지고 있기 때문에 묻고 그것을 분리하는 것에 대해 생각하고있었습니다.
long_function(){ ... }
으로:
small_function_1(){...}
small_function_2(){...}
small_function_3(){...}
함수는 long_function 외부에서 사용되지 않으므로 더 작은 함수를 만들면 더 많은 함수 호출 등을 의미합니다.
함수를 더 작은 함수로 분리 할 때는 언제입니까? 왜?
- 메소드는 하나의 논리적 인 일만해야합니다 (기능에 대해 생각하십시오)
- 한 문장으로 방법을 설명 할 수 있어야합니다
- 디스플레이 높이에 맞아야합니다.
- 불필요한 오버 헤드를 피하십시오 (명백한 설명은 …)
- 작은 논리 기능에 대한 단위 테스트가 더 쉽습니다.
- 다른 클래스 나 메소드가 함수의 일부를 재사용 할 수 있는지 확인
- 클래스 간 과도한 커플 링을 피하십시오
- 깊이 중첩 된 제어 구조를 피하십시오
답변에 대해 모두 감사 합니다. 목록을 편집 하고 정답 에 투표하십시오.
나는 그 아이디어를 염두에두고 리팩토링하고 있습니다 🙂
답변
그것에 대한 진짜 어렵고 빠른 규칙은 없습니다. 일반적으로 나는 “한 가지 일”을하는 방법을 좋아한다. 따라서 데이터를 가져 와서 해당 데이터로 무언가를 한 다음 디스크에 쓰는 경우, 잡아서 분리하고 별도의 방법으로 쓰면 “주요”방법에 “뭔가”가 포함됩니다.
“뭔가를하는”것은 여전히 몇 줄이 될 수 있으므로 여러 줄이 올바른 메트릭인지 확실하지 않습니다. 🙂
편집 : 이것은 지난 주 직장에서 우송 한 한 줄의 코드입니다 (요점을 증명하기 위해. : 그것은 습관이 아닙니다 :))-나는 내 방법 으로이 나쁜 소년들 중 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();
답변
다음은 함수가 너무 길다는 것을 나타내는 빨간색 플래그 (특별한 순서가 아님) 목록입니다.
-
깊게 중첩 된 제어 구조 : 예를 들어 복잡한 조건을 가진 중첩 된 if 문으로 for-loops 3 레벨 깊이 또는 심지어 2 레벨 깊이.
-
상태 정의 매개 변수가 너무 많음 : 상태 정의 매개 변수로 , 함수를 통한 특정 실행 경로를 보장하는 함수 매개 변수를 의미합니다. 이러한 유형의 매개 변수를 너무 많이 얻으면 조합 경로가 엄청나게 커집니다 (일반적으로 # 1과 함께 발생 함).
-
다른 방법으로 복제 된 논리 : 코드 재사용이 불량하면 모 놀리 식 절차 코드에 크게 기여합니다. 이러한 논리 중복 은 매우 미묘 할 수 있지만 일단 리팩토링되면 최종 결과는 훨씬 더 우아한 디자인이 될 수 있습니다.
-
과도한 클래스 간 커플 링 : 적절한 캡슐화가 없기 때문에 다른 클래스의 친밀한 특성과 관련된 기능으로 인해 기능이 길어집니다.
-
불필요한 오버 헤드 : 명확하게 중첩 된 클래스, 전용 중첩 클래스 변수에 대한 불필요한 게터 및 세터 및 비정상적으로 긴 함수 / 변수 이름을 나타내는 주석은 모두 관련 함수 내에 구문 적 노이즈를 생성하여 결국 길이를 늘릴 수 있습니다.
-
거대한 개발자 급 디스플레이는 그것을 표시하기에 충분히 크지 않습니다 : 실제로 오늘날의 디스플레이는 높이에 가까운 곳의 기능이 너무 길어질 정도로 충분히 큽니다. 그러나 그것이 더 크면 이것은 잘못된 것입니다.
-
즉시 함수의 목적을 확인할 수 없습니다 : 실제로 한 번 더 나아가, 어떻게 당신은 하나의 문장이 목적을 요약하거나 엄청난 두통이 일어날 수없는 경우, 그 목적을 결정,이 단서해야한다.
결론적으로, 모 놀리 식 함수는 광범위한 결과를 가져올 수 있으며 종종 주요 설계 결함의 증상입니다. 읽는 것이 절대적으로 즐거운 코드를 발견 할 때마다 우아함이 즉시 드러납니다. 그리고 무엇을 추측하십시오 : 함수의 길이 는 종종 매우 짧습니다.
답변
이 페이지에서 “한 가지 일만”만트라에 큰 경고가 있다고 생각합니다. 때때로 한 가지 일을하는 것은 많은 변수를 저글링합니다. 작은 함수가 긴 매개 변수 목록을 갖는 경우 긴 함수를 여러 개의 작은 함수로 나누지 마십시오. 그렇게하면 단일 함수가 실제 개별 값이없는 고도로 결합 된 함수 세트로 바뀝니다.
답변
함수는 한 가지만 수행해야합니다. 함수에서 작은 일을 많이하는 경우에는 각각의 작은 일을 함수로 만들고 long 함수에서 해당 함수를 호출하십시오.
당신이 정말 하지 않는 원하는 것은 복사 할과 (당신의 예에서 알 수 있듯이) 짧은 기능으로 당신의 긴 기능의 매 10 개 라인을 붙여 넣습니다.
답변
함수가 한 가지만 수행해야한다는 데 동의하지만 그 한 수준은 어느 정도입니까?
60 라인이 (프로그램 관점에서) 한 가지를 달성하고 60 라인을 구성하는 조각이 다른 것에 의해 사용되지 않는다면 60 라인은 괜찮습니다.
자체적으로 콘크리트 조각으로 나눌 수 없다면 그것을 깨는 데 실질적인 이점은 없습니다. 사용할 메트릭은 코드 라인이 아닌 기능입니다.
필자는 저자가 단 한 가지를 극한 수준으로 끌어 올리는 많은 프로그램을 연구했으며 결국 누군가가 수류탄을 함수 / 방법에 가져간 것처럼 보이게하고 수십 개의 연결되지 않은 조각으로 만들었습니다. 따라 가기 어렵다.
해당 기능을 꺼낼 때 불필요한 오버 헤드를 추가하고 대량의 데이터를 전달하지 않도록 고려해야합니다.
중요한 점은 그 긴 기능에서 재사용 성을 찾고 그 부분을 꺼내는 것입니다. 남은 것은 10 줄, 20 줄 또는 60 줄의 길이에 관계없이 기능입니다.
답변
60 줄은 크지 만 기능에 비해 너무 길지 않습니다. 편집기에서 한 화면에 맞으면 한 번에 볼 수 있습니다. 실제로 기능이 수행하는 작업에 따라 다릅니다.
왜 기능을 깨뜨릴 수 있습니까?
- 너무 깁니다
- 코드를 분해하고 새로운 기능에 의미있는 이름을 사용하여 코드를 유지 관리하기 쉽게 만듭니다.
- 이 기능은 응집력이 없습니다
- 기능의 일부는 그 자체로 유용합니다.
- 기능에 대한 의미있는 이름을 제시하기 어려운 경우 (아마도 너무 많은 일을하고 있음)
답변
내 개인적인 휴리스틱은 스크롤하지 않고 모든 것을 볼 수 없으면 너무 길다는 것입니다.
