객체 지향 프로그래밍에서는 물론 메소드의 최대 길이에 대한 정확한 규칙은 없지만 여전히이 두 따옴표가 서로 약간 모순되는 것을 알았으므로 귀하의 생각을 듣고 싶습니다.
에서 클린 코드 : 애자일 소프트웨어 장인의 수첩 , 로버트 마틴은 말합니다 :
함수의 첫 번째 규칙은 작아야한다는 것입니다. 함수의 두 번째 규칙은 그보다 작아야한다는 것입니다. 기능은 100 줄을 넘지 않아야합니다. 기능은 거의 20 줄이되지 않아야합니다.
그는 Kent Beck에서 본 Java 코드의 예를 보여줍니다.
그의 프로그램의 모든 기능은 단지 2, 3, 4 줄 길이였습니다. 각각은 분명했다. 각각 이야기를했습니다. 그리고 각각 당신을 설득력있는 순서로 다음으로 이끌었습니다. 기능이 얼마나 짧아야하는지!
이 큰 소리를하지만, 다른 한편으로는,에 전체 코드 , 스티브 맥코넬은 매우 다른 것을 말한다 :
이 루틴은 유기적으로 최대 100-200 라인까지 자랄 수 있어야하며, 수십 년의 증거에 따르면 그러한 길이의 루틴은 더 이상 오류가 발생하지 않는 것이 루틴이 짧을 것입니다.
그리고 그는 65 줄 이상의 루틴을 개발하는 것이 더 저렴하다고 연구에 대한 언급을한다.
따라서 문제에 대한 의견이 다양하지만 기능적인 모범 사례가 있습니까?
답변
Java 또는 C #으로 코딩 할 때 일반적으로 함수는 짧아야합니다 (5-15 줄). 여러 가지 이유로 좋은 크기입니다.
- 스크롤하지 않고도 화면에 쉽게 맞습니다.
- 머리에 붙일 수있는 개념적 크기에 관한 것입니다.
- 자체적으로 기능을 필요로 할 정도로 의미가 있습니다 (독립적이고 의미있는 논리 덩어리로)
- 5 줄보다 작은 함수는 코드를 너무 많이 나눌 수 있다는 힌트입니다 (함수 사이를 탐색 해야하는 경우 읽기 / 이해하기가 더 어려워 짐). 또는 특별한 경우 / 오류 처리를 잊어 버렸습니다!
그러나 규칙에서 벗어나야 할 유효한 예외 / 이유가 항상 있기 때문에 절대 규칙을 설정하는 것이 도움이되지 않는다고 생각합니다.
- 유형 캐스트를 수행하는 한 줄 액세서 기능은 경우에 따라 명확하게 허용됩니다.
- 5 줄 미만을 분명히 필요로하는 매우 짧지 만 유용한 기능 (예 : 사용자가 알 수없는 스왑)이 있습니다. 큰 문제는 아니지만 몇 가지 3 줄 함수는 코드 기반에 해를 끼치 지 않습니다.
- 하나의 큰 switch 문인 100 행 함수는 수행중인 작업이 매우 분명한 경우 허용 될 수 있습니다. 이 코드는 다른 경우를 설명하기 위해 많은 행이 필요하더라도 개념적으로 매우 간단 할 수 있습니다. 때로는 이것이 별도의 클래스로 리팩토링되고 상속 / 다형성을 사용하여 구현되어야한다고 제안하지만 IMHO는 OOP를 너무 많이 취하고 있습니다 .40 개의 새로운 클래스보다 하나의 큰 40-way switch 문만 가지고 싶습니다. 40-way switch 문으로 작성하십시오.
- 복잡한 함수에는 여러 함수간에 매개 변수로 전달되는 경우 매우 혼란 스러울 수있는 상태 변수가 많이있을 수 있습니다. 이 경우 모든 것을 하나의 큰 함수로 유지하면 코드가 더 간단하고 따르기 쉽다는 주장을 합리적으로 만들 수 있습니다 (Mark는 올바르게 지적했지만이 논리를 캡슐화하기 위해 클래스로 전환하는 후보가 될 수도 있음) 그리고 상태).
- 때때로 더 작거나 큰 함수는 성능상의 이점을 제공합니다 (Frank에서 언급 한 인라인 또는 JIT 이유로 인해). 이는 구현에 따라 크게 다르지만 차이를 만들 수 있습니다. 벤치마킹해야합니다!
따라서 기본적으로 상식을 사용 하고 대부분의 경우 작은 기능 크기를 고수하지만 비정상적으로 큰 기능을 수행 해야하는 진정한 이유가 있다면 독단적 인 것은 아닙니다.
답변
올바른 LOC 번호에 대한 엄격한 규칙이 없다고 말했을 때 다른 사람들의 의견에 동의하지만 과거에 보았던 프로젝트를 되돌아보고 위의 모든 기능을 식별하면 150 줄의 코드를 말하겠습니다. 우리는 이러한 기능 중 10 개 중 9 개가 SRP를 깨고 (OCP도 가능성이 높음) 로컬 변수가 너무 많고 제어 흐름이 너무 많으며 일반적으로 읽고 유지하기 어렵다는 의견에 동의 할 것입니다.
따라서 LOC는 잘못된 코드를 직접 나타내는 지표는 아니지만 특정 기능을 더 잘 작성할 수있는 적절한 간접 지표입니다.
팀에서 나는 리드의 위치에 빠졌고 어떤 이유로 든 사람들이 내 말을 듣고있는 것 같습니다. 내가 일반적으로 정한 것은 팀에 절대적인 제한이 없지만 코드 검토 중에 50 줄 이상의 코드가 있으면 최소한 붉은 깃발을 올려야한다는 것을 알려주는 것입니다. 따라서 다시 살펴보고 다시 평가하십시오. 복잡성과 SRP / OCP 위반 두 번째 모습을보고 난 후에 우리는 그것을 내버려 두거나 바꿀 수도 있지만 적어도 사람들이 이런 것들에 대해 생각하게합니다.
답변
코딩 지침에 관심이없는 프로젝트를 시작했습니다. 코드를 살펴보면 때로는 6000 줄 이상의 코드와 10 개 미만의 메서드가있는 클래스를 찾습니다. 이것은 버그를 수정해야 할 때의 공포 시나리오입니다.
방법의 최대 크기에 대한 일반적인 규칙은 때로는 그리 좋지 않습니다. 나는 Robert C. Martin (Uncle Bob)의 규칙을 좋아한다. “방법은 작고 작아야한다” 이 규칙을 항상 사용하려고합니다. 내 방법이 한 가지 일만하고 더 이상 아무것도하지 않음을 분명히하여 내 방법을 단순하고 작게 유지하려고합니다.
답변
줄 수에 관한 것이 아니라 SRP에 관한 것입니다. 이 원칙에 따르면, 방법은 한 가지만 수행해야합니다.
당신의 방법이 이것을하고 이것을 하고이 OR 저것 => 그것은 아마도 많은 것을하고 있습니다. 이 방법과 분석을 살펴보십시오. “여기서이 데이터를 가져 와서 정렬하고 필요한 요소를 얻습니다”및 “여기서 이러한 요소를 처리합니다”와 “결과를 얻기 위해 마지막으로 이들 요소를 결합합니다”. 이러한 “블록”은 다른 방법으로 리팩토링되어야합니다.
SRP를 따르기 만하면 대부분의 방법이 작고 분명한 의도로 사용됩니다.
“이 방법은> 20 줄이므로 잘못되었습니다”라고 말하는 것이 올바르지 않습니다. 할 수있다 표시 무언가가 있다고 할 수있다 더 이상,이 방법으로 잘못된.
방법에 400 회선 스위치가있을 수 있으며 (종종 텔레콤에서 발생) 여전히 단일 책임이며 완벽하게 정상입니다.
답변
그것은 의존 정말 문제와 작업입니다 언어, 언급 라인 열 다섯 다섯 때문에이 질문에 대한 확고한 답이없는, 심각, 이 대답은 C #이나 자바하지만 다른 언어로는 제공하지 않습니다 작동 할 수는 당신은 많은 일을합니다. 마찬가지로, 작업중인 도메인에 따라 큰 데이터 구조로 코드 설정 값을 작성하는 경우가있을 수 있습니다. 일부 데이터 구조를 사용하면 설정해야 할 수십 가지 요소가있을 수 있습니다. 함수가 오래 실행되어 기능을 분리하기 위해 분리해야합니까?
다른 사람들이 지적했듯이, 경험상 가장 좋은 규칙은 함수가 단일 작업을 처리하는 단일 논리 엔터티 여야한다는 것입니다. 함수가 n 줄 보다 길 수 없다고 말하는 드라코 니안 규칙을 시행하려고 시도 하고 그 값을 너무 작게하면 개발자가 규칙을 피하기 위해 멋진 속임수를 사용하려고 할 때 코드를 읽기가 더 어려워집니다. 마찬가지로, 너무 높게 설정하면 문제가되지 않으며 게으름에도 불구하고 잘못된 코드로 이어질 수 있습니다. 가장 좋은 방법은 코드 검토를 수행하여 기능이 단일 작업을 처리하고 그대로 두는 것입니다.
답변
여기서 한 가지 문제는 함수의 길이가 복잡성에 대해 아무 것도 말하지 않는다는 것입니다. LOC (라인 코드)는 무엇이든 측정하기에 나쁜 도구입니다.
방법은 지나치게 복잡해서는 안되지만 긴 방법을 쉽게 유지 관리 할 수있는 시나리오가 있습니다. 다음 예제에서는 메소드로 분할 할 수 없으며, 메소드가 유지 보수성을 변경하지 않는다고 말합니다.
예를 들어 들어오는 데이터에 대한 처리기는 큰 switch 문과 사례 당 간단한 코드를 가질 수 있습니다. 피드에서 들어오는 데이터를 관리하는 코드가 있습니다. 숫자로 코딩 된 핸들러 (70)! 이제 “상수 사용”이라고 말할 것입니다. API가 제공하지 않고 여기서 “소스”에 가깝게 유지하는 것을 제외하고는 그렇습니다. 행동 양식? 물론 슬프게도 모두 2 개의 거대한 구조의 데이터를 처리합니다. 더 많은 방법 (가독성)을 갖는 것을 제외하고는 그것들을 나누는 데 아무런 이점이 없습니다. 코드는 본질적으로 복잡하지 않습니다. 필드에 따라 하나의 스위치입니다. 그런 다음 모든 경우에는 데이터의 x 요소를 구문 분석하고 게시하는 블록이 있습니다. 유지 보수의 악몽이 없습니다. 필드에 데이터가 있는지 여부를 결정하는 조건이 하나만 있으면 반복됩니다. pField-> IsSet () {blabla} 인 경우 pField = pFields [x]-모든 필드에서 거의 동일합니다.
중첩 루프를 포함하는 훨씬 더 작은 루틴과 많은 실제 스위칭 명령문으로 대체하면 큰 메소드는 하나의 작은 것보다 유지 관리하기가 더 쉬울 수 있습니다.
죄송합니다. LOC는 좋은 측정 방법이 아닙니다. 그렇다면 복잡성 / 의사 결정 지점을 사용해야합니다.
답변
나는 또 다른 인용문을 던질 것이다.
사람들이 읽을 수 있도록, 그리고 기계가 실행할 수 있도록 프로그램을 작성해야합니다.
-해롤드 아벨 슨
100-200으로 증가하는 기능이이 규칙을 따르는 것은 매우 불가능합니다