비즈니스 클래스 이름을 어떤 언어로 지정해야합니까?

29

이 질문으로 모범 사례를 요청하고 있습니다. 이것은 고객 회사가 엄격하게 자국인 인 경우 영어 이외의 모국어 인 경우에만 문제가됩니다.

고객이 주로 도메인 고유 (예 : 독일어) 식을 많이 사용하고 일부 도메인 고유 이름 지정과 혼합 한 경우 코드 주석의 언어, 클래스 / 방법 / 변수 이름은 영어입니다. 모든 도메인 특정 이름을 번역 하시겠습니까?

naming

— 지미
소스

11

영어. 프로그래밍을위한 Lingua franca.

— Rig

6

더 '도전적인'PHP 오류 메시지 중 하나에는 흥미로운 히브리어 비틀기가 unexpected T_PAAMAYIM_NEKUDOTAYIM있습니다. 내 인생에서 이것을 몇 번 보았을 때, 나는 영어를 사용해야한다는 의심의 여지가 없습니다.

— K.Steff

3

독일어 도메인 특정 표현식에 비표준 문자 (예 : umulauts (sp?))가 있습니까? 해당 지역 이외의 프로그래머를 고용하면 필요한 문자가 포함 된 키보드를 찾지 못할 수도 있습니다 (광산이 아닌). 예, '유형'언어를 전환하는 방법이 있지만 번거 로움을 원하지 않습니다.

— Clockwork-Muse

2

그리스어-비 라틴어 알파벳을 사용하는 것이 클링 온보다 작업 안정성이 뛰어납니다.

— Wyatt Barnett

3

@ X-Zero가 일반 ASCII를 벗어나면 웜의 "사용할 문자 인코딩"이 열립니다. 일반적으로 당신은 물고 다시는 가지 않습니다.

16

저는 독일에서 일하고 있고 영어를 고르는 것을 선호합니다.

예를 들어 "DATEV"(독일 송장 / 청구 소프트웨어)로 모듈을 만드는 것과 같은 도메인 관련 사항은 독일어 이름을 사용합니다. "Referenzbuchungsnummer"(ReferenceBookingNum?) 또는 "Sachkontenlaenge"(..?)와 같은 일부 독일어 단어는 제대로 번역되지 않습니다. 또한 도메인 관련 사항이 유지 관리 공포로 끝날 것이라고 생각합니다. 아마 ReferenceBookingNum은 "Referenzbuchungsnummer"와 관련이 있지만, 동료들은 어떻습니까? 문서가 존재하는 경우 이름에 대한 내부 문서를 연구해야합니다. 적절한 이름이 없으면 모듈에 익숙하지 않을 것입니다. 다른 모든 개발자가 독일인이라면 불필요한 복잡성입니다. 그러나 "CakeFactory"는 "KeksFabrik"보다 훨씬 더 잘 들립니다.

모든 것이 달려 있습니다.

— lurkerbelow
소스

2

이 답변은 다른 답변을 읽은 후 나의 개인적인 의견을 가장 많이 반영합니다. 특히이 점은 모든 것을 번역 할 때 "다른 모든 개발자가 독일인이라면 불필요하게 복잡하다"는 것입니다.

— Zeemee

1

@Mulmoth : "다른 모든 개발자가 독일인이라면 불필요한 복잡성입니다."--- 몇 년 안에 프로젝트가 다른 국가에 아웃소싱되지 않는 시점을 어떻게 확신 할 수 있습니까? 독일어를 구사하는 개발자가 특정 시점에 프로젝트에 소개되지 않을 것이라고 어떻게 확신 할 수 있습니까?

— 산호 도우

5

@Coral 미상 - 나는 새 / 기타 /의 아웃소싱 개발자가 이미 생각 해야 할 비즈니스 도메인과 그 구체적인 표현으로 깊이 파고. 따라서 imho는 잘못 번역되거나 잘못 번역 된 영어 이름 대신 고객이 (독일인이 될) 고객을 독일어 명명 된 클래스에 매핑하는 것이 더 쉽습니다.

— Zeemee

2

독일어 청구 / 세 관련 "상품"은 독일어가 아닌 국가로 아웃소싱되지 않습니다. 대학에서 누군가는 모든 청구서 / 세금 책의 85 %가 독일 법률을 말하며 독일어로 작성되었다고 말했습니다. 세계적인.

— lurkerbelow

3

동의하지만 거의 항상 발생하는 한 가지 문제는 개발자가 사용하는 언어가 사용자와 다른 이해 관계자에게 유출된다는 것입니다. UI의 일부가 아니라 문제 영역에 대해 어떻게 말하는지. 모든 개발자가 영어만큼 유창하지는 않기 때문에 이것은 혼란을 초래할 것입니다.

— Mille Bessö

14

노르웨이 회사에서 일하는 노르웨이 인이기 때문에 영어로 물건을 명명합니다. 물론 일부 단어 나 개념에는 영어 대응 언어가 없을 수 있으며,이 경우 의미가없는 대체 또는 문자 그대로의 번역 대신 네이티브 단어가 사용될 수 있다고 주장 할 수 있습니다. 물론, 이러한 문제의 대부분은 우리 중 일부는 더 나은 어휘를 가져야한다는 사실 일 수 있습니다. 그래서 나는 보통 좋은 영어 이름을 생각할 수없는 경우 동료에게 물어 봅니다. :)

저희 직원 중 일부는 노르웨이 인이 아니므로 영어로 글을 쓰면 도움이됩니다. 대부분의 유럽에서 프로그래머를 고용 할 수 있다는 것이 경제에 좋으므로 우리 회사도 혜택을 볼 수 있습니다.

BTW : Hermes의 출처를 한 번 읽은 것을 기억합니다 (ebXML b2b 구현). 그들이 북경어로 작성하고 주석을 달았 으면 힘들었을 것입니다.

— 실베스터
소스

5

내가 생각하는 것에 대해 거의 편집 된 "대학"은 "동료"인 것으로 생각되지만 의도적인지 확실하지 않았습니다.

— Jacob Schoen

물론 나는 동료를 의미했다 :)

— Sylwester

Of course some words or concepts might not have a English counterpart-영어를 할 줄 아는 스피커가 내놓지 않을 디자인 패턴을 아는 것처럼 프로그래밍에 있어서는 항상 궁금합니다. 빠른 예가 있습니까?

— 이즈 카타

5

@Izkata : 비즈니스 클래스 에 관한 질문이었습니다 . 그들은 종종 국가 별 규칙 및 규정과 관련이 있습니다. 예를 들어, 법에 따라 위험한 화학 물질이있는 모든 트럭의 위치를 추적해야하는 경우 해당 법률에 따라 해당 클래스의 이름을 지정할 수 있습니다.

— MSalters

9

저는 영어가 IT 도메인의 링구아 프랑카이기 때문에 소스 코드를 다른 언어로 제한하면 개발에 인공적인 장애물이됩니다. 먼저 특정 언어를 사용하는 사람들에게 기여할 수있는 사람들의 수영장을 제한하십시오. 로컬 사이트가 아닌 스택 교환에서 요청한 것과 동일한 이유입니다.

또한 당신은 기부금의 출처와 목적지를 모릅니다. 사이트의 샘플을 사용하면 어떻게 번역 하시겠습니까? 다른 국가의 고객이 사용하도록 제품을 확장하면 어떻게 되나요? 계약자 / 외부 아웃소싱을 고용해야합니까? 왜 하나의 수영장으로 제한하고 전 세계에서 가장 적합하지 않습니까?

다른 언어로 쉽게 매핑되지 않는 기존 도메인 기반 구조 나 기존 코드 기반이 유지되는 경우에는 괜찮다고 가정 할 수 있습니다.

— 디미트리오스 미스트 리츠
소스

9

마지막 프로젝트 목표는 담보 및 모기지의 비즈니스 영역을 모델링하는 것이 었습니다. 우리가 일한 모든 개발자와 회사는 폴란드 출신입니다. 우리는 도메인 기반 설계 원칙에 따라 소프트웨어를 구축했습니다. 우리는 모든 사업체에 대해 폴란드의 이름을 사용했으며 이것이 좋은 선택이라고 생각합니다. 이 접근 방식 덕분에 통신 문제를 피할 수 있다고 생각합니다. 비즈니스 영역은 영어 번역은 말할 것도없고 폴란드어로 알지 못하는 많은 용어로 구성되었습니다. 우리는 라틴 문자 만 사용했고 모든 기술 수업은 영어로 명명되었습니다.

— 엠피
소스

4

좋은 지적입니다. 모든 도메인 지식이 현지 언어로되어 있고 도메인 개념에 대해 합의 된 영어 이름이 없으면 현지 언어를 사용하는 것이 좋습니다.

— Joachim Sauer

7

단일 언어로 작성된 소스 코드를 읽는 것이 일반적으로 더 쉽습니다. 이것은 대부분의 프로그래밍 언어에서 영어로 작성해야 함을 의미합니다.

그러나 도메인 개념에는 영어로 쉽게 번역되지 않는 주요 문제가 있습니다. 전형적인 예는 사회가 개인에게 제공하는 고유 식별자입니다. 미국에서 가장 가까운 개념은 사회 보장 번호이지만 정확한 매핑은 아닙니다. 이름과 전화 번호는 일반적으로 매우 잘 매핑됩니다.

나는 정확한 매핑을 영어로 쉽게 구할 수 없을 때마다 도메인 용어 를 유지 해야한다고 생각 하지만 나머지는 영어로 유지해야합니다. KommuneImpl과 같은 비정상적인 식별자가 발생하지만 도메인을 아는 사람들에게는 즉시 의미가 있어야합니다.

2

오픈 소스 / 국제 커뮤니티 유형 프로젝트

오픈 소스 및 국제 커뮤니티 프로젝트의 공통 언어는 영어입니다. 예를 들어, Stack Exchange 사이트의 언어는 영어입니다. 가장 광범위한 접근성을 위해서는 모든 코드 및 객체 이름에 영어를 사용해야합니다.

상업 프로젝트

대부분의 국제 소프트웨어 회사는 코드를 영어로 작성해야합니다. 가장 큰 공통 분모이므로 일관성을 만드는 수단으로 영어를 사용하는 것이 좋습니다.

많은 지역 소프트웨어 회사가 자국어로 작성합니다. 모든 사람이이 접근 방식을 따르는 것은 아니지만 관점에서 볼 때 의미가 있습니다. 모든 개발자에게 공통 언어를 사용합니다.

비즈니스 오브젝트 이름 지정

팀의 코딩 언어를 사용하여 개체 이름을 지정해야합니다.
우선 순위는 개발자가 오브젝트 및 프로젝트 요구 사항과 관련하여 서로 통신 할 수있는 것입니다. 팀이 프랑스어로 작성하는 경우 비즈니스 오브젝트는 프랑스어로 이름을 지정해야합니다. 영어로 코딩 된 경우 개체의 이름을 영어로 지정하십시오.

고객이 팀의 코딩 언어가 아닌 모국어를 사용하므로 질문에 주름이 생깁니다. 여전히 팀의 코딩 언어를 사용하여 개체 이름을 지정해야합니다.
비즈니스 분석가 또는 개발자가 특정 비즈니스 개체에 대해 클라이언트와 통신해야하는 경우 코딩 언어에서 클라이언트 언어로 개체 이름을 필요에 따라 변환해야 할 수 있습니다. 내 경험상 클라이언트와 특정 코드 객체에 대해 이야기 했으므로 클라이언트 언어로의 번역이 실제로 필요하지 않은 경우는 거의 없습니다.

명명 규칙에 대한 유일한 예외는 객체의 의도를 포착하기 위해 객체에 다른 간결한 용어가없는 경우입니다. IMO, 이것은 매우 드물지만 발생할 수 있습니다. 그러나 실제로는 언어가 특정 개념을 표현하기 위해 사용하는 것과 동일합니다. " Facade "는 원래 프랑스어 용어이지만 개념을 표현하기 위해 영어로 채택되었으며 일반적인 디자인 패턴입니다. " Schadenfreude "는 해당 패턴이 있다고 생각하지 않지만 빌린 용어의 또 다른 좋은 예입니다.

1

마지막 단락은 첫 번째 단락과 완전히 모순됩니다.

— James

@ 제임스-감사합니다! 내가 의미하는 바를 명확히 할 시간이 없기 때문에 해당 섹션을 제거했습니다. 그것은 지원해야했지만 아무 상관이 없습니다.

1

강하게 동의. 실제로 모든 언어의 핵심 개념은 영어로 작성되므로 영어 이외의 용어를 사용하면 읽기 어려운 소스 코드가 생성됩니다. 마음은 끊임없이 영어와 다른 언어 사이를 뛰어 넘어야합니다. 코드는 유창하고 읽을 수 있어야합니다.

— Mike Adler

@ MikeAdler-일반적인 규칙 (팀의 언어로 된 이름)이나 매우 드 물어야 할 예외 사례로 제안한 내용에 동의하지 않는 경우 명확하지 않습니다.

당연하다. 나는 명확히 할 것이다 : 나는 어떤 객체가 영어 이외의 언어로 명명되어야한다는 것에 동의하지 않는다. 첫 번째 제목 인 '오픈 소스 / 국제 커뮤니티 유형 프로젝트'는 저의 견해를 잘 반영합니다. 그 후의 모든 것, 나는 사지 않는다. 언급 한 바와 같이 그 이유는 유지 관리 성인데, 이는 실제로 모든 설계 결정 (네이밍 체계 포함)이 내 생각에 가장 우선적으로 고려해야하는 문제이기 때문입니다.

— Mike Adler