코딩 안내서 : 대형 소스 파일을 어떻게 분할합니까?

https://stackoverflow.com/questions/608530

03-07-2019
|

문제

내가 작업하고있는 프로젝트는 메인 C# 파일에서 4200 라인을 쳤으며, 이로 인해 Intellisense는 몇 초 (때로는 6 개 정도)가 응답하여 비주얼 스튜디오가 잠그는 데 응답합니다. 다른 사람들이 어떻게 파일을 분할하고 합의가 있는지 궁금합니다.

나는 가이드를 찾으려고 노력했고 발견했다 Google의 C ++ 가이드, 그러나 기능 크기 및 파일 크기와 같은 의미론에 대해서는 아무것도 볼 수 없었습니다. 어쩌면 거기에있을 수도 있습니다 - 나는 그것을 잠시 동안 보지 않았다.

그렇다면 파일을 어떻게 분할합니까? 그들이 제공하는 기능으로 방법을 그룹화합니까? 유형 (이벤트 핸들러, 개인/공개)? 그리고 어떤 크기의 한계에서 당신은 기능을 분할합니까?

명확히하기 위해, 문제의 응용 프로그램은 데이터를 처리하므로 인터페이스는 큰 그리드이며 모든 것이 그리드를 중심으로 진행됩니다. 관리를위한 몇 가지 대화 상자가 있지만 데이터에 관한 것입니다. 그렇게 큰 이유는 많은 오류 확인, 이벤트 처리 및 그리드가 각 행에 3 개의 그리드가 더있는 마스터 하이 테일로 설정되기 때문입니다 (그러나 마스터 행의 부하가 확장 됨). 이것이 내가 무엇을하고 있는지 명확히하는 데 도움이되기를 바랍니다.

해결책

귀하의 문제는 "Main C# 파일"이라는 용어로 요약된다고 생각합니다.

메인을 의미하지 않는 한 (메소드 Main ())에서와 같이 해당 개념에 대한 장소는 없습니다.

포괄적 인 유틸리티 클래스 또는 기타 공통 방법이있는 경우 유사한 기능 부품으로 나누어야합니다.

일반적으로 내 파일은 일대일 클래스 매핑 일뿐입니다.

때로는 매우 관련된 클래스가 같은 파일에 있습니다.

파일이 너무 크면 클래스가 너무 크고 너무 일반적이라는 것을 나타냅니다.

내 방법을 화면의 절반 이하로 유지하려고합니다. (코드 일 때 처음부터 작성하면 일반적으로 12 줄 이하이지만 최근에는 다른 개발자로부터 기존 코드로 작업하고 있으며 100 줄 함수를 리팩터링해야합니다 ...)

때로는 화면이지만 매우 커지고 있습니다.

편집하다:

크기에 대한 크기 제한 질문을 해결하려면 기능에 대한 질문을 해결하려면 크기에 관한 것이 덜 (문제의 좋은 지표이지만) 한 가지만 수행하고 각각을 단순하게 유지하는 것에 대한 것입니다.

다른 팁

클래식 책에서 "구조화 된 프로그래밍"Dijkstra는 한때"우리가 많은 일을 할 수 없다는 사실 "이라는 제목의 섹션을 썼습니다. 그의 요점은 단순했습니다. 인간은 그다지 똑똑하지 않습니다. 우리는 한 번에 우리의 마음 속에 몇 가지 개념 이상을 저글링 할 수 없습니다.

수업과 방법을 작게 유지하는 것이 매우 중요합니다. 메소드가 12 줄 이상을 초과하면 분리되어야합니다. 클래스가 몇 백 줄을 넘어지면 분리되어야합니다. 이것이 코드를 잘 구성하고 관리 할 수있는 유일한 방법입니다. 저는 거의 40 년 동안 프로그래밍 해 왔으며 매년 소프트웨어를 작성할 때 "작은"이라는 단어가 얼마나 중요한지 알고 있습니다.

에 관해서 어떻게 당신은 이것을합니다. 이것은 여러 번에 쓰여진 매우 큰 주제입니다. 일반적으로 의존성 관리, 정보 숨기기 및 객체 지향 설계에 관한 것입니다. 다음은 읽기 목록입니다.

유형을 분할하는 것이 자연스러운 곳으로 나뉘지만 너무 많은 일을하는 유형을 조심하십시오. 약 500 줄 (Java 또는 C#)에서 나는 걱정됩니다. 약 1000 줄에서 나는 유형을 분할 해야하는지 열심히 찾기 시작하지만 때로는 때로는 그렇지 않을 수 없습니다.

방법에 관해서는 : 한 번에 화면의 전체 메소드를 볼 수 없을 때는 마음에 들지 않습니다. 분명히 그것은 모니터의 크기 등에 달려 있지만 합리적인 경험 법칙입니다. 나는 그들이 더 짧은 것을 선호합니다. 다시 말하지만, 예외가 있습니다. 일부 논리는 특히 자연스럽게 함께 캡슐화되기를 원하지 않는 로컬 변수가 많이있는 경우 분해하기 어렵습니다.

때로는 단일 유형이 많은 방법의 System.Linq.Enumerable 그러나 부분 클래스는 그러한 경우에 도움이 될 수 있습니다. Enumerable, 집계 / 세트 작업 / 필터링 등으로 그룹화하는 것은 자연스럽게 보일 것입니다). 그런 경우는 내 경험에서 드물다.

마틴 파울러의 책 리팩토링 나는 당신에게 이것에 대한 좋은 출발점을 준다고 생각합니다. "코드 냄새"를 식별하는 방법과 코드를 리팩터링하여 이러한 "냄새"를 수정하는 방법에 대해 지시합니다. 자연스러운 결과 (주요 목표는 아니지만)는 더 작게 유지 가능한 클래스로 끝나는 것입니다.

편집하다

당신의 편집에 비추어, 나는 항상 백엔드 코드에 대한 좋은 코딩 관행이 프레젠테이션 계층에서 동일하다고 주장했다. UI 리팩토링에 대해 고려해야 할 몇 가지 유용한 패턴은 명령, 전략, 사양 및 상태입니다.

간단히 말해서, 귀하의보기에는 이벤트를 처리하고 값을 할당하기위한 코드 만 있어야합니다. 모든 논리는 다른 클래스로 분리되어야합니다. 이 작업을 수행하면 리팩터를 리팩터 할 수있는 곳이 더 분명해집니다. 그리드는 이것을 만듭니다 작은 프리젠 테이션 논리와 견해 사이에서 프리젠 테이션 상태를 분할하기가 너무 쉽기 때문에 더 어렵지만 일부 작업을 사용하면 간접적으로 이에 의해 발생하는 통증을 최소화 할 수 있습니다.

절차 적으로 코딩하지 않으면 하나의 파일로 4,200 줄로 끝나지 않습니다.

C#에서는 일부를 준수하는 것이 좋습니다. 단단한 객체 지향 디자인 원칙. 모든 수업에는 하나의 유일한 이유가 있어야합니다. 주요 방법은 단순히 응용 프로그램의 시작점을 시작해야합니다 (구조 캡과 같은 것을 사용하는 경우 종속성 분사 컨테이너를 구성).

나는 일반적으로 200 줄 이상의 코드가있는 파일이 없으며 100 세 미만인 경우 선호합니다.

단단하고 빠른 규칙은 없지만 단일 기능보다 짧고 짧은 기능이 더 낫고 더 작은 클래스가 1 개의 큰 클래스보다 낫다는 일반적인 합의가 있습니다.

40 라인보다 큰 기능은 어떻게 분해 할 수 있는지 고려해야합니다. 특히 혼란스럽고 종종 멋진 설명 이름을 가진 기능 호출로 번역하기 쉬운 중첩 루프를 살펴보십시오.

나는 믹스 프레젠테이션과 논리와 같이 둘 이상의 일을하는 것처럼 느낄 때 수업을 시작합니다. 큰 클래스는 클래스가 1 일을하는 한 큰 방법보다 문제가되지 않습니다.

내가 본 스타일 가이드의 합의는 생성자와 공개 메소드가 상단에있는 액세스에 의한 방법을 그룹화하는 것입니다. 일관된 것은 훌륭합니다.

C# 스타일과 리팩토링을 읽고 문제를 해결하려면 실제로 문제를 이해해야합니다.

리팩토링 행동이 보존되도록 코드를 다시 쓰기위한 팁이있는 훌륭한 책입니다. 코드는 더 명확하고 작업하기 쉽습니다.

C# 스타일의 요소 좋은 죽은 나무 C# 스타일 가이드입니다. 블로그 게시물 좋은 온라인 스타일 가이드에 대한 여러 링크가 있습니다.

마지막으로 사용하는 것을 고려하십시오 fxcop 그리고 스타일 콥. 이것들은 당신이 묻는 질문에 도움이되지 않지만 코드의 다른 문체 문제를 감지 할 수 있습니다. 당신은 당신의 발가락을 물에 담그기 때문에 당신은 뛰어들 수도 있습니다.

그것은 많은 것이지만 맛, 스타일 및 선명도를 발전시키는 것은 훌륭한 개발자와 나쁜 개발자의 주요 차이점입니다.

각 수업은 하나의 작은 일을하고 잘 수행해야합니다. 당신의 클래스 A 양식입니까? 그런 다음 비즈니스 로직이 없어야합니다.

사용자 나 상태와 같은 단일 개념을 나타 냅니까? 그런 다음 도면,로드/저장 등이 없어야합니다 ...

모든 프로그래머는 단계와 수준을 겪습니다. 현재 수준의 문제를 인식하고 다음에 접근 할 준비가되었습니다.

당신이 말한 바에 따르면, 그것은 당신의 현재 레벨이 "문제 해결"인 것처럼 들리며, 대부분의 절차 코드를 사용하고있을 가능성이 높으며, 새로운 방법을 더 많이 찾아야합니다.

나는 실제로 oo 디자인을 수행하는 방법을 조사하는 것이 좋습니다. 말이되지 않는 많은 이론이 있습니다. 그들이하지 않는 이유는 그들이 현재 프로그래밍하는 방식에 적용되지 않기 때문입니다.

lemme 좋은 게시물을 찾으십시오 ... 이것을 살펴보기 시작하십시오.

방법-파손-직접 코딩-택시

rules-for-oop입니다

객체 지향적 인 실습-과정 -V-composition-v-interfaces

좋은 OO 디자인 책을 참조 할 게시물도 있습니다. "Refactoring"책은 아마도 당신이 시작할 수있는 최고의 장소 중 하나 일 것입니다.

당신은 지금 좋은 지적에 있지만, 당신은 얼마나 멀리 가야하는지 믿지 않을 것입니다. 가까운 미래 에이 것들 중 일부는 당신이 가질 수있는 최고의 프로그래밍 "학습 경험"이기 때문에 당신이 그것에 대해 흥분하기를 바랍니다.

행운을 빕니다.

시간이 지남에 따라 각각 천천히 바꿀 작은 것들을 찾을 수 있습니다.

해당 클래스에 사용 된 모든 방법 만 있습니까? 유효성 검사, 문자열 조작과 같은 지원 방법을 찾아 도우미/UTIL 클래스로 옮길 수 있습니다.
#영역 섹션을 사용하고 있습니까? #영역에서 관련 방법의 논리적 그룹화는 종종 별도의 클래스로 나뉘어진다.
클래스 A 양식입니까? 양식 컨트롤 또는 양식 컨트롤 그룹에 사용자 컨트롤을 사용하는 것을 고려하십시오.

전반적인 디자인을 고려하지 않고 빠른 수정 / 새로운 기능을 수행하는 많은 개발자로 인해 시간이 지남에 따라 대규모 클래스가 발전합니다. 다른 사람들이 제공 한 디자인 이론 링크 중 일부를 다시 방문하고 코드 리뷰 및 팀 워크샵과 같은 디자인을 검토하기위한 지속적인 지원을 고려하십시오.

글쎄, 나는 당신이 느린로드 시간보다 더 큰 문제가있을 수 있다고 말하는 것이 두렵습니다. 엄격하게 결합 된 코드와 유지 관리 가능성/가독성 문제의 문제에 도달 할 것입니다.

클래스 파일을 작은 파일로 나누는 데 좋은 이유가 있습니다 (파일을 다른 프로젝트/어셈블리로 옮기는 것이 똑같이 좋은 이유).

수업이 달성해야 할 목적에 대해 생각해보십시오. 각 파일에는 실제로 단일 목적 만 있어야합니다. 예를 들어 "쇼핑 바구니 논리 포함"과 같은 목표가 너무 일반화되면 잘못된 길로 향하고 있습니다.

또한 언급 한 바와 같이, 당신이 사용하는 용어 : "main c# 파일"은 당신이 매우 절차 적 사고 방식을 가지고 있다고 생각합니다. 저의 조언은 중지하고 물러서서 다음 주제 중 일부를 빠르게 읽는 것입니다.

일반 OOP 원칙
도메인 구동 설계
단위 테스트
IOC 컨테이너

당신의 검색에 행운을 빕니다.

부분 클래스를 사용하십시오. 기본적으로 단일 클래스를 여러 파일로 나눌 수 있습니다.

아마도 OP가 응답 할 수 있습니다 : 프로젝트가 객체 지향 프로그래밍을 사용하고 있습니까? "파일"이라는 단어를 사용한다는 사실은 그렇지 않다는 것을 암시합니다.

객체 방향을 이해할 때까지 중요한 방식으로 코드를 개선 할 희망은 없습니다. 파일을 전혀 나누지 않는 것이 좋을 것입니다. 파일이 견딜 수 없을 정도로 느리고 버그가 될 때까지 기다렸다가 더 이상 부과하는 대신 OO를 배우십시오.

Visual Studio 2008의 Intellisense Parser는 2005 년보다 훨씬 빠른 것 같습니다 (이 분야에서 많은 작업을 수행 한 것을 알고 있습니다). Visual Studio 2008은 즉각적인 성능 문제를 해결할 수 있습니다. 많은 문제없이 100k+ linq에서 SQL 파일을 열었습니다.

각 클래스/파일/기능/등을 위해 코드를 분할하십시오. 한 가지만 수행합니다. 단일 책임 원칙 기능을 클래스로 분할하기위한 좋은 지침입니다.

오늘날, 내가 쓴 가장 큰 클래스는 길이가 약 200 줄이며 방법의 길이는 대부분 길이입니다.

클래스 내에 코드 영역이있는 경우 간단한 방법은 partial 키워드 및 해당 클래스의 정의를 해당 파일로 브레이크 아웃합니다. 나는 일반적으로 큰 수업을 위해 이것을합니다.

내가 사용하는 컨벤션은 classname_regionname.cs를 갖는 것입니다. 예를 들어, 데이터베이스 연결에 대한 스키마를 관리하는 클래스를 나누고 싶고 클래스 DatabaseConnection을 호출 한 경우 기본 클래스 용 DataBaseConnection.cs라는 파일을 만들고 Schema 기능에 대한 DatabaseConnection_schema.cs를 작성합니다.

일부 수업은 크기가 커야합니다. 그것은 나쁜 디자인이 아닙니다. 그것들은 단지 구현이 많은 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow