답변:
내부 이름과 외부 이름의 불일치는 확실히 냄새가납니다. Rinzwind가 지적한 것처럼, 호모 폰과 동의어는 가장 나쁜 냄새를 맡습니다.
당신이 대답해야 할 실제 질문은 다음과 같습니다. 변화를 만드는 데있어 비용 / 혜택은 무엇입니까?
변경하지 않는 비용은 새로운 팀원에게 가파른 학습 곡선이며 향후 버그 가능성이 높아집니다. 변경 비용은 명백한 시간, 프로젝트에 참여한 노인을위한 새로운 학습 곡선 및 새로운 버그 가능성입니다.
비교적 많은 수의 새 팀 구성원이있을 것으로 예상되는 경우 변경하는 것이 더 합리적입니다. 이직을 기대하지 않으면 현재 팀은 혼란스러워하지 않으며 팀은 현재 상태에 만족하면 실제로 이름을 바꾸는 것이 합리적이지 않습니다.
두 번째 질문과 관련하여 게시 된 연구 나 모범 사례를 알지 못합니다. 첫 번째 질문과 관련하여, 나는 '내부'와 '외부'이름이 때때로 다른 유사한 장수명 제품에 대한 개인적인 경험을 통해 관찰 할 수 있습니다.
내가 정말로 고치고 싶은 이름은“호모 폰”인데, 여기서 하나의 이름이 다른 것들을 위해 내부와 외부에서 사용됩니다 . 특히 두 가지가 완전히 다르지 않은 경우 (상황이 명확 해 지도록) 혼동 될 수 있습니다. 내 개인적인 경험에 대한 하나의 (추상적 인) 예는 내부적으로 당신이 Foo여러 개의 집합 인 것과 같은 것을 가지고 있습니다 FooEntity; 외부에서는 후자 만 볼 수 있으며 "Foo"라고합니다. 고객 매뉴얼이 여러 개의 "Foo"에 대해 말할 때 실제로 여러 가지 의미 FooEntity(단일로 Foo)를 의미한다고 생각했습니다.
둘째, 외부 이름이 내부적으로 사용 된 "동의어"를 수정하고 싶습니다. 변수 이름, 메소드 / 함수 이름 등에서처럼. 이는 개발자가 고객 요구 사항 설명에서 직접 무언가를 구현하고 이름을 "번역"하는 것을 잊었을 때 발생합니다. 그런 다음 '잘못된'이름도 퍼지는 경향이 있습니다. 다른 개발자가 예를 들어 새 코드의 템플릿으로 사용하기 위해 해당 코드 중 일부를 복사 / 붙여 넣기하기 때문입니다. 이러한 동의어는 혼동되지는 않지만 참조를 찾기 위해 코드를 검색하는 경우 Bar일부 부분이 다음을 참조 할 수 있음을 명심해야 할 수 있기 때문에 성 가실 수 있습니다.Qux이므로 두 번 검색해야합니다. (이것은 정적 언어보다 동적으로 유형이 지정된 언어에서는 유형이 아닌 변수 / 함수 / ...의 일부를 검색해야하기 때문에 더 나쁠 수 있습니다.) "동의어"의 경우 ”(내부 이름이 외부에서 사용 된 경우) : 고객 지원 직원 등이 일반적으로 내부 이름에 대해 잘 모르기 때문에 자주 발생하지 않는 경향이 있습니다.
위의 두 가지 상황을 피하거나 해결할 수 있다면 모든 내부 이름을 외부 이름과 동일하게 만드는지 확실하지 않습니다. 외부 이름이 내부 이름과 처음 변경되었을 때 내부 이름도 변경되지 않은 이유가있을 수 있습니다. 내 개인적인 경험에서, 그 좋은 이유는 이전 버전의 제품을 지원해야한다는 것입니다. 많은 코드를 변경해야하는 경우 이름 수정 전 버전에서 최신 버전으로 버그 수정을 병합하기가 어려워 질 수 있습니다.
상당히 일반적인 문제입니다. 내가 작업 한 많은 프로젝트는 제품 이름 대신 코드 이름을 사용하고 (이 시점에서 결정되지 않았을 수 있음) 사용자에게 표시되는 것과는 다른 코드에서 매우 다른 용어를 사용합니다. 코드를 대량으로 용도 변경하지 않거나 문제를 일으키는 특정 문제가 없다면 아마도 그대로 두는 것입니다. 사과 카트를 화나게하는 데 사용하지 마십시오. 또한 지금부터 5 년 동안 누가 더 많은 변화가 없을 것이라고 말합니까? 그런 다음 이름 변경을 다시 수행해야합니다. 또한 이는 별도의 코드 문서 (게시 된 API)에 영향을 미치므로 인쇄 된 경우 (하드 카피) 특히 비용이 많이 드는 문제 일 수 있습니다.
"마케팅"엔터티가 내부 엔터티와 정확히 일치하지 않는 경우가 많습니다. 그러한 경우, 다른 추상화 레벨에서 엔티티를 도입하는 것이 더 의미가 있으며, 이는 용어 차이를 약점으로 만듭니다.
예를 들어 계층 구조를 나타내는 모델이 있습니다. 계층의 각 수준에는 계층이 실제 관계를 모델링하는 데 사용되는 방식에 따라 관련 용어가 있지만 내부적으로는 계층의 한 수준에서 다음 수준으로 동작에 차이가 없습니다. 용어는 본질적으로 계층 구조에서 해당 레벨의 이름 일 뿐이므로 트리의 특정 노드에 대한 이름은 단순히 노드가 무엇인지 설명합니다. 특정 행동을 처방하지 않습니다.
또한 트리는 다중 루트이므로 부모가없는 여러 노드가 있습니다. 개념적으로 뿌리가 존재하지만 (본질적으로 우주를 나타냄) 모형에 포함하면 많은 작업이 훨씬 단순 해지지 만 "마케팅 용어"는 없습니다.
물론 시스템의 다른 구성 요소는 다른 용어를 사용합니다. 그것들은 다른 팀에 의해 다른 시간에 개발되었으며, 우리는 그들 모두를 통제 할 수 없습니다. 실제로 어떤 시점에서 누군가가 한 구성 요소에서 수준을 추가 또는 제거 했으므로 다른 수준은 서로에 대해 이동합니다. 동일한 세 수준은 한 구성 요소에서 A, B 및 C로 표시되지만 다른 구성 요소에서 B, C 및 D로 표시됩니다.
추상화의 단계를 밟고 모든 것을 "노드"또는 동일하게 일반적인 것으로 모델링하면 이러한 종류의 모델을 추론하기가 훨씬 쉬워집니다. 각 노드는 "마케팅 용어"가 무엇인지 알고 있으며 특정 마케팅 용어를 나타내는 유형은 각 용어에서 해당 용어가 무엇을 의미하는지 알 수 있습니다.