Metaphor

원문 : http://www.extremeprogramming.org/rules/metaphor.html

Choose a System Metaphor

Choose a system metaphor to keep the team on the same page by naming classes and methods consistently. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system. For example the Chrysler payroll system was built as a production line. At Ford car sales were structured as a bill of materials. There is also a metaphor known as the naive metaphor which is based on your domain itself. But don't choose the naive metaphor unless it is simple enough.

시스템 메타포를 선정하면 같은 팀내에서 클래스와 메소드의 이름을 일관적으로 정할수 있어 공감대를 형성할 수 있다. (즉 하나의 메타포를 선정하여 공유하면 변수 이름같은 것을 지을때 같은 관점으로 짖게 된다는 의미). 어떤 객체에 대한 이름을 정하는 것은 시스템 전체를 이해하거나 코드를 재사용하는데 매우 중요하다. 만약 메타포를 올바르게 정한다면, 이름이 어떻게 정해지는가를 추측할 수 있게되고 실제로 개발 시간을 크게 절감시켜준다. 구축할 객체에 대한 이름을 위한 시스템(즉 메타포)를 결정할때는 모든 사람이 해당 시스템에 대하여 특별한 지식이 없이도 쉽게 연관되어 질수 있는 것으로 선택해야 한다. 예를 들어 크라이슬러의 지불시스템은 생산라인으로 구축되었다. 포드의 자동차 영업사원들은 BOM(부품표)으로 구조화 되었다. 구축하려고 하는 분야의 메타포를 사용할 수도 있다. 그러나 충분히 단순하지 않다면 영영에 해당하는 메타포를 사용하지는 말아라.
--> 그런데 실 사례로 이해하기가 힘드네요. 메타포가 현재 시스템을 충분히 포괄하지 못하는 경우가 상당히 많을턴데...
see XperDotOrg