클래스, 열거 형 및 기타 엔터티를 별도의 파일에 배치해야합니까?

회사의 팀 리더 / 아키텍트는 "논리로 연결된 엔터티"가 하나의 .cs 파일에 배치되면 대규모 프로젝트를 이해하기 쉽다고 주장합니다.

나는 인용한다 :

• "논리와 인터페이스 및 클래스의 전체 구조를 한 곳에서 볼 수 있습니다. 이것은 반박 할 수없는 논증입니다. 같은 것을 볼 수 있지만 많은 파일을 사용하려면 도구, 클래스를 사용해야합니다. 탐색을위한 다이어그램, R # 등 "

• "빈약 한 이론에 따르면 분리 된 파일의 군대가 멋지다고 비명을 지르 겠지만, 기존 코드를 변경할 때, 특히이 코드의 작성자가 아닌 경우에는 흩어진 파일을 많이 이해하기가 매우 어렵습니다. 따라서 포럼에서는 "하나의 열거 형 파일"이라고 쓸 수 있지만 실제로는이 방법을 사용해서는 안됩니다. "

• "... 개발자들 사이의 코드베이스 분리에 관해서는, 현재 같은 파일을 동시에 편집하는 것은 문제가 아닙니다. 병합은 문제가되지 않습니다."

열거 형, 클래스 등마다 하나의 .cs 파일을 만들어야한다는 것을 듣고 여러 번 읽었으며 이것이 모범 사례입니다.

그러나 나는 그를 설득 할 수 없다. 그는 Jon Skeet과 같은 잘 알려진 프로그래머를 신뢰하지 않는다고 말합니다. 그런데이 주제에 대한 Skeet의 의견은 다음과 같습니다. 열거 형 유형을 찾는 가장 좋은 장소는 어디입니까?

어떻게 생각해? 진짜 문제가 있습니까? 아니면 맛의 문제이며 조직의 코딩 표준에 의해 규제되어야합니까?

팀장의 주장에는 몇 가지 결함이 있습니다.

1. 잘 설계된 클래스와 열거 형은 논리적으로 의미가있는 곳이 아니라 프로젝트의 어느 곳에서나 사용하도록 고안되었습니다 .

2. XML 주석으로 올바르게 문서화 된 클래스와 열거 형은 참조하는 항목 위에 마우스를 올려 놓음으로써 자체 설명이 가능합니다.

3. 참조를 마우스 오른쪽 단추로 클릭하고 "정의로 이동"을 선택하여 클래스 또는 열거 정의에 항상 액세스 할 수 있으므로 실제로 어디에 두든 상관 없습니다 .

4. "논리적"방식으로 객체를 조합하는 것은 임의적입니다 (즉, "논리적"의 의미에 대해 생각해야합니다. 실제 프로그래밍을 수행하는 클록 사이클을 오히려 소비하고 싶습니다).

고유 한 파일에 각 객체 정의를 설정하면 조직과 구조에 대한 균일하고 훈련 된 기대치가 생기고 "왜 이것이 여기에 있습니까?"와 같은 질문을 일으키지 않습니다. 아주 좋은 일입니다.

둘 이상의 객체가 논리적으로 관련되어 있으면 프로젝트 탐색기 의 자체 폴더 에 넣습니다 .

마우스 오른쪽 버튼을 클릭하고 "정의로 이동"을 선택하는 것이 옵션이 아니었던 초기 팀 시대에 팀 리더가 이빨을 잘라 냈을 가능성이 높습니다. 나는 무거운 스파이크 개발 모드에있을 때 다시 날카롭게 할 때까지 꽤 큰 클래스 파일을 자랄 것임을 알고 있습니다.

어쨌든 팀을 업무에 이끌고 싶다면 왜 이러한 클래스와 열거가 자식 클래스와 열거가 아닌지 물어보십시오. 진정으로 의존하는 엔티티 인 경우 독립 클래스로 선언 할 이유가 없습니다. 이것은 그를 통해 fatwa를 생각하는 데 도움이 될 수 있습니다.