프로그래밍중인 언어로 외부 데이터 변환

다음으로 무엇을해야할지 모르겠습니다.

우리는 자체 도구 내에서 외부 도구에서 데이터를 가져옵니다. 이 데이터는 네덜란드어로 작성되었습니다. 우리는 Java 코드를 영어로 작성하고 있습니다. 이 네덜란드어를 영어로 번역해야합니까 아니면 네덜란드어로 유지해야합니까? 예를 들어, Bouw (영어로 제작)와 Onderhoud (영어로 유지)라는 2 개의 부서가 있습니다.

그런 다음 만드는 것이 논리적입니까?

public enum Department { BOUW, ONDERHOUD }

또는:

public enum Department { CONSTRUCTION, MAINTENANCE }

또는:

public enum Afdeling { BOUW, ONDERHOUD }

(비방은 네덜란드의 부서입니다)

이 시나리오에서는 열거 형 값 을 네덜란드어로 남겨 둡니다 .

public enum Department { BOUW, ONDERHOUD }

이 상수를 사용하는 논리 는 네덜란드어 에있는 데이터와도 일치하기 때문입니다 . 예를 들어, 입력이 "bouw"인 경우 비교 코드는 다음과 같습니다.

if (Department.BOUW == input.toUpper())

값이 일치 할 때 디버깅하는 것이 더 쉽다는 것을 알았습니다 (값의 의미를 모르더라도). 번역은 단지 개발자로서 정확성을 증명하기 위해 뛰어 넘어갈 필요가없는 정신적 후프를 추가합니다.

그럼에도 불구하고 다른 사람들이 데이터 컨텍스트를 이해하는 데 도움이되면 코드에 주석을 달 수 있습니다.

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

영어는 이유에 대한 링구아 프랑카 / 가장 일반적인 분모입니다. 이유가 "모두가하는 것"만큼 개념적으로 약하더라도 여전히 중요한 이유입니다.

일반적인 관행에 반하는 것은 소프트웨어의 데이터 구조를 이해하기 위해 네덜란드어를 이해해야 함을 의미합니다. 네덜란드어에는 아무런 문제가 없지만 코드베이스와 상호 작용 해야하는 엔지니어가 말할 확률은 영어보다 낮습니다.

따라서,하지 않는 한 네덜란드의 전용 쇼핑있어, 국제적으로 확장 할 계획이없는 지금 , 당신의 코드베이스 단일 언어를 유지하고, 가장 인기있는 코딩 언어를 사용하는 좋은 아이디어는 거의 항상입니다.

참고 : 이 조언은 프로그램 코드 에만 적용 됩니다. 사용자 데이터는 반드시 번역하지 말고 "있는 그대로"처리해야합니다. 고객 "Goldstein"이 있더라도 분명히 "Golden Stone"으로 이름을 저장해서는 안됩니다.

문제는 "사용자 제공, 터치하지 않음"과 "코드 조각, 항상 영어 사용"사이에 연속 된 용어가 있다는 것입니다. 고객 이름은 스펙트럼의 전자 엔드에 매우 가깝고 후자는 자바 변수에 가깝습니다. enum특히 값이 잘 알려진 고유 한 외부 엔터티 (예 : 부서)를 나타내는 경우 값의 상수 가 약간 더 멀어집니다. 조직의 모든 사람이 부서에 네덜란드어 용어를 사용하는 경우 코드 기반이없는 사람과 대면 할 계획이 없으며 기존 부서 세트가 거의 변경되지 않는 경우 허용 된 부서 이름을 사용하면 더 많은 것을 만들 수 있습니다 지역 변수보다 열거 형 상수에 대한 감각. 그래도 나는 그것을하지 않을 것입니다.

모든 번역은 추가적인 노력과 버그를 유발할 수 있으므로 가능하면 번역을 피하십시오.

"도메인 구동 설계"가 현대 소프트웨어 엔지니어링에 기여한 주요 요소 는 프로젝트의 모든 이해 관계자가 사용하는 단일 언어 인 유비쿼터스 언어 의 개념입니다 . DDD에 따르면, 팀 (사양 문서의 프록시만으로도 도메인 전문가 포함) 내에서 번역이 발생하지 않아야하고 팀간에 만 번역해야합니다 (추가 정보 : Eric Evans의 "도메인 기반 디자인", 특히 챕터 유비쿼터스 언어 및 전략적 디자인에 대해).

즉, 비즈니스 전문가 (또는 사양 문서)가 네덜란드어를 사용하는 경우 비즈니스 문제를 소스 코드로 표현할 때 (네덜란드어) 용어를 사용하십시오. 불필요하게 영어로 번역하지 마십시오. 비즈니스 전문가와 프로그래머 간의 의사 소통에 인공적인 장애가 발생하기 때문에 시간이 걸리고 (모호하거나 나쁜 번역을 통해) 버그가 발생할 수 있습니다.

반대로, 비즈니스 전문가가 영어와 네덜란드어로 비즈니스에 대해 이야기 할 수있는 경우 프로젝트의 유비쿼터스 언어를 선택할 수있는 운이 좋은 상황에 있으며 영어를 선호하는 정당한 이유가 있습니다 (예 : "국제적으로 이해할 수있는 표준에 의해 사용될 가능성이 더 높음 "), 그렇게한다고해서 코더가 비즈니스 사람들이 말하는 것을 번역해야한다는 의미는 아닙니다. 대신, 사업 사람들은 언어를 바꿔야합니다.

유비쿼터스 언어를 사용하는 것은 요구 사항이 복잡하고 내부적으로 사용하는 언어를 CRUD 만하는 경우 정확하게 구현해야하는 경우 특히 중요합니다.

개인 일화 : 저는 일부 비즈니스 서비스를 SOAP 엔드 포인트로 노출 한 프로젝트에있었습니다. 비즈니스는 전적으로 독일어로 지정되었으며 특정 관할권과 관련된 법적 문제에 관한 것이기 때문에 영어로 재사용되지 않을 것입니다. 그럼에도 불구하고, 일부 상아탑 설계자들은 향후 재사용을 촉진하기 위해 SOAP 인터페이스가 영어라고 명령했다. 이 번역은 즉석에서 이루어졌으며 개발자들 사이에는 조정이 거의 없었지만 공유 용어집 만 있었으므로 웹 서비스 계약에서 동일한 비즈니스 용어와 웹 서비스 계약에서 동일한 이름을 가진 일부 비즈니스 용어가 생겼습니다. 아, 물론 분열의 양쪽에서 사용되는 일부 이름-다른 의미로!

어쨌든 번역을 선택하는 경우 용어집에서 번역을 표준화하고 해당 용어집의 준수 여부를 정의에 추가 한 다음 검토에서 확인하십시오. 우리처럼 부주의하지 마십시오.

올바른 해결책은 부서를 전혀 하드 코딩하지 않는 것입니다.

ArrayList<String> departments = (... load them from a configuration file ...)

또는 부서 유형이 절대적으로 필요한 경우 :

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

코드에서 특정 부서에 대해 테스트해야 할 필요가있는 경우 해당 부서의 특수한 사항을보다 일반적으로 묻고 해당 부서가 해당 특성을 갖도록 구성해야합니다. 예를 들어, 한 부서에 급여가 매주 있으며 코드가 관심을 갖는 경우 WEEKLY_PAYROLL 특성이 있어야 구성으로 모든 부서에 첨부 할 수 있습니다.

궁금해하는 사람들을 위해 : 우리는 첫 번째 옵션을 선택했습니다. 주로 번역을 위해 용어를 구성해서는 안된다고 생각하기 때문입니다. 그러나 언젠가 국제 개발자가 프로젝트를 진행할 경우 다음과 같은 설명을위한 문서를 추가했습니다.

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

사용자 또는 무언가를 보여주기 위해 문자열 표현이 걱정되는 경우 열거 형 안에 설명 배열을 정의하고 메소드를 노출하십시오.
예 : Department.BUILD.getDescription();"BOUW"를 출력합니다

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

다른 방법을 선택했지만 Google 소용돌이가 실수로 사람들을 여기로 던지는 경우를 대비하여 알고 있습니다.

편집 : Pokechu22에서 지적했듯이 다음과 같이 열거 형 생성자와 개인 속성을 사용할 수 있습니다.

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

또한 그 효과를 얻을 수 있습니다.

코드의 특정 불변이 유지 될 것으로 예상됩니다. 이러한 불변 인 중 하나는 식별자의 이름을 바꿀 때 프로그램이 다르게 작동하지 않는다는 것입니다. 이 경우 특히 열거 형이 있고 해당 열거 형의 멤버 이름을 바꾸고 해당 멤버의 모든 사용을 업데이트하면 코드가 다르게 작동하지 않을 것으로 예상됩니다.

구문 분석은 데이터를 읽고 데이터 구조를 파생시키는 프로세스입니다. 외부 데이터를 가져 와서 읽고 열거 형 인스턴스를 만들면 데이터를 구문 분석하는 것입니다. 해당 구문 분석 프로세스는 데이터를 수신하는 데이터 표현과 데이터 유형 멤버의 모양 및 이름 사이의 관계를 유지 관리하는 프로그램의 유일한 부분입니다.

따라서 열거 형 멤버에 어떤 이름을 할당해도 문제가되지 않습니다. 읽은 데이터에 사용 된 문자열과 일치하는 것은 우연입니다.

도메인을 모델링하기 위해 코드를 디자인 할 때 멤버의 이름은 데이터의 직렬화 형식과 관련이 없어야합니다. 이들은 네덜란드어가 아니어야하고 네덜란드어의 번역이 아니어야하지만 도메인 모델에 가장 적합한 것으로 결정해야합니다.

파서는 데이터 형식과 도메인 모델 사이를 변환합니다. 이것이 데이터 형식이 코드에 미치는 영향의 마지막입니다.