명명 유형에 대한 좋은 기술이나 테스트가 있습니까?

어색하고 공개적인 질문이지만 항상 부딪 치는 문제입니다.

유지 관리 및 작업이 쉬운 소프트웨어는 잘 설계된 소프트웨어입니다. 직관적 인 디자인을 시도한다는 것은 다음 개발자가 구성 요소의 기능을 유추 할 수 있도록 구성 요소의 이름을 지정하는 것을 의미합니다. 이런 이유로 우리는 클래스 이름을 "Type1", "Type2"등으로 지정하지 않습니다.

실제 개념 (예 : 고객)을 모델링 할 때는 일반적으로 실제 개념을 모델링 한 후 유형을 명명하는 것만 큼 간단합니다. 그러나보다 시스템 지향적 인 추상적 인 것들을 만들 때, 읽기 쉽고 소화하기 쉬운 이름을 사용하기가 매우 쉽습니다.

구성 요소의 기능을 설명하지만 작동 방식을 설명하지 않는 기본 유형 또는 인터페이스를 사용하여 유형 패밀리의 이름을 지정하려고하면 나에게 더 나빠집니다. 이 자연스럽게 구현 (예를 들면 맛을 설명하려고 각 파생 유형 리드 IDataConnection와 SqlConnection닷넷 프레임 워크를),하지만 어떻게 당신이 "반사와 속성의 특정 세트를 찾고 작품"와 같은 복잡한 무언가를 표현합니까?

그런 다음 마지막으로 수행하려는 작업을 설명하는 유형의 이름을 선택하면 동료가 "WTF가 DomainSecurityMetadataProvider실제로 수행합니까? "라고 묻습니다.

구성 요소의 의미있는 이름을 선택하는 데 유용한 기술이 있습니까?

이름이 "좋은"것인지 더 잘 느끼고 다른 사람에게 더 직관적이어야하는지 이름에 적용 할 수있는 간단한 테스트가 있습니까?

명명에는 6 가지 기술 이 있습니다.

1. 이름을 발명하는 데 많은 시간을 할애하다
2. 코드 리뷰 사용
3. 망설이지 말고 이름 바꾸기
4. 이름을 발명하는 데 많은 시간을 할애하다
5. 코드 리뷰 사용
6. 망설이지 말고 이름 바꾸기

추신. API가 공개 될 예정이라면 위의 내용이 그 전에 적용됩니다 .

"공개 API는, 다이아몬드처럼, 당신은 그것을 잘 그래서 당신의 최고의 ...주고받을 수있는 하나의 기회가 있습니다. 영원히"(여호수아 블로흐는 어떻게 디자인 할 수있는 좋은 API를하고 중요한 이유 )

내 기본 테스트는 변수의 단어 만 사용하여 변수의 기능을 설명 할 수 있는지 여부입니다.

예를 들어 DomainSecurityMetadataProvider가 "도메인 보안 메타 데이터 제공"또는 "도메인 보안 관련 메타 데이터 제공"이면 좋습니다.

그러나 사람마다 다른 뉘앙스가 있습니다.

예를 들어, original_team_code는 원래 팀의 코드 인 반면 다른 사람에게는 팀의 원래 코드 일 수 있습니다. 내가 개인적으로 가장 좋아하는 것 중 하나는 "UnsafeLegacyMutex"였는데, "이것은 ThreadUnsafe 레거시 코드의 뮤텍스입니다"대신 "안전하지 않은 레거시 뮤텍스입니다"라고 읽을 수는 없었습니다.

그래서 확장 테스트는 보드 / 위키 / 채팅에 변수를 쓰고 사람들이 그 의미를 추측하게하는 것입니다.

구성 요소의 의미있는 이름을 선택하는 데 유용한 기술이 있습니까?

실제로는 아닙니다.

그러나 한 가지 팁은 "수동적 인 음성"을 피하는 것입니다.

"DomainSecurityMetadataProvider"는 수동입니다. 동사는없고 형용사로 사용되는 모든 명사와 명사입니다.

"ProvideMetadataForDomainSecurity"가 더 활성화되었습니다. 동사가 있습니다.

객체 지향 프로그래밍은 모두 (실제로) 명사입니다. 명사 == 객체. 동사 == 방법. 따라서 클래스 이름은 일반적으로 매우 "누적"입니다. 이 습관을 깨고 동사 삽입을 시작하기는 어렵습니다.

이름이 "좋은"것인지 더 잘 느끼고 다른 사람에게 더 직관적이어야하는지 이름에 적용 할 수있는 간단한 테스트가 있습니까?

예. 당신은 당신의 질문에서 훌륭한 시험을 정의했습니다. 다른 사람들에게 물어보십시오.

옛날에는 이것을 "디자인 연습"이라고 불렀습니다. 폭포수 방법론에서 크고 땀이 많은 거래였습니다. 요즘에는 Agile 메서드를 사용하여 수업의 작성자와 사용자간에 일반적인 공동 작업이 이루어져야합니다. 오래 걸리지 않아야합니다. 테스트 (및 코드)를 작성하기 전에 디자인 (및 이름)을 논의하면 놀라운 요소가 줄어들고 WTF를 방지 할 수 있습니다.

동의어 사전 사용

클래스와 메소드를 설명하는 적절한 단어를 찾기 위해 새로운 개발을 할 때 동의어 사전을 참조하는 경우가 종종 있습니다.

주로 작동 논리를 포함하는 클래스

나는 주로 "EntityProvider", "EntityLocator"등과 같은 명사 동사 구조에서 오퍼레이션 메소드를 제공하는 클래스의 이름을 지정하는 경향이 있습니다.

이 클래스는 일반적으로 많은 상태를 포함하지 않습니다.

상태를 포함하는 클래스

UI 화면과 데이터 엔터티는 일반적으로 상태 저장이므로 명사 또는 형용사 명사 패턴으로이 클래스의 이름을 지정합니다.

예 : 사람, 직원, 현직 직원, 전직 직원

유틸리티 클래스

정적 메서드 만 포함 된 클래스는 일반적으로 "유틸리티"클래스로 간주되므로 "유틸리티"접미사로 일관되게 이름을 지정합니다.

예 : NetworkUtilities, FileUtilities

테스트

이름이 잘못 지정되었는지 여부를 결정하기위한 좋은 테스트는 없지만 이름에 단일 명사 및 / 또는 단일 동사를 사용하는 것이 좋습니다. 그런 다음 해당 명사 / 동사가 당신이 무엇을 정확하게 묘사하는지 생각해보십시오. 다시 명명.

이름으로 캡처되지 않은 클래스 / 메소드가 더 있다고 생각되면 해당 클래스 / 메소드를 리팩터링해야합니다.

Alan Green 과 Jeff Attwood 는 "Manager"접미사로 클래스 이름 지정의 악에 대해 글을 썼습니다. 그들은 "관리자"라는 용어가 과도하게 사용되었고 의미가없는 것을 전달하기에는 너무 모호하다고 주장합니다. 동의해야합니다.

Jeff의 기사는 Steve McConnell의 Code Complete에서 제안 된 지침 목록도 제공합니다.

변수

최근에는 "Of", "By", "For"등과 같이 전치사를 포함하는 더 긴 설명 변수 / 매개 변수 이름을 실험했습니다. 일부 예는 다음과 같습니다.

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

Visual Studio의 인텔리전스 기능을 사용하면 이러한 긴 이름을 쉽게 입력 할 수 있습니다. 또한 변수 이름 접두사 (예 : personID, personFirstName, personLastName vs. idOfPerson, firstNameOfPerson, lastNameOfPerson)의 중복이 적으므로 인텔리전스를 더욱 유용하게 만드는 더 나은 "해시"를 제공합니다.

그런 다음 마지막으로 수행하려는 작업을 설명하는 유형의 이름을 선택하면 동료는 "WTF는이 DomainSecurityMetadataProvider가 실제로 수행하는 작업을 수행합니까?"라고 묻습니다.

복잡한 도메인 특정 클래스에 대해 어떤 종류의 이름을 기대하십니까? 이것은 수업 이름을 문장으로 만들지 않고도 얻을 수있는 수준입니다.

이름에서 공급자를 삭제하는 것을 고려할 것입니다. 메타 데이터에 대해 구체적으로 언급 한 경우 모든 사용자는 리플렉션을 사용하고 있다는 것을 이미 알고 있습니다. 한 단어를 더 간결하게 만들 수 있습니다 (또는 다른 단어로 변경 가능)-작성한 단어의 공급자보다 소비자가 더 많음)

은유를 사용하여 시스템의 일부를 설명하십시오. 새로운 비유를 발견 할뿐만 아니라 이름을 쉽게 지정할 수 있습니다.

(이것은 강력한 예는 아니지만 어쨌든 알고 있습니다) 예를 들어 변수 또는 유형을로 호출 mailbox하여 클래스에 대해 수신 된 메시지의 대기열 역할을 할 수 있습니다 .

내가 매우 확고한 한 가지는 이름이 절대 부정확 해서는 안된다는 것입니다. 가장 좋은 예는, 일부 리팩토링 과정에서 많은 코드가 변경되었고, 몇몇 변수는 이름에서 제안한 것 이외의 것을 참조하기 시작했습니다.

얼마 지나지 않아 한 프로그래머가 오래 전부터 이미 추출되어 저장된 특정 데이터를 파악하려고 고가의 데이터베이스 호출을 사용하고있었습니다. 나는 모든 것을 이름을 바꾸고 갑자기 너무 복잡하고 버그가 많은 논리를 제거 할 수있었습니다.

이름에 대해 그렇게 열심히 생각해야하는 경우는 드물다. 그러한 경우가 발생하면, 수업 내용을 설명하는 단락을 작성하십시오. 기능 중 주석 또는 기능 수준 주석과 달리 클래스의 기본 목적은 거의 변경되지 않으므로 주석이 오래되지 않을 위험은 상대적으로 적습니다. 따라서 두 개의 단락을 작성하거나 클래스의 기능을 설명하기 위해 ASCII를 그릴 수도 있습니다.