명명 클래스가 쇠약 해짐 [닫힘]

이것이 OCD 특성인지 확실하지 않지만 때로는 외부에서 사용해야한다고 생각하는 클래스 (또는 함수 또는 네임 스페이스 등)의 이름을 지정할 때 내가하고있는 일을 계속할 수 없기 때문에 완전히 차단되는 경우가 있습니다. 주어진 프로젝트의. 예를 들어 API. 또는 유틸리티 클래스 라이브러리.

이름이 정확하지 않으면 (내 마음에) 계속 할 수 없습니다 ... 나는 올바른 이름을 찾으려고 노력합니다. 이름이 어떻게 생겼는지 알 수 있지만 도움이되지 않는 작은 앱을 작성하려고 시도했습니다 ...

나는 그것이 중요하지 않다는 것을 알고 있으며, 당신이 그것을 완벽하게 생각한다고 가정하는 것은 프로그래밍 정신에 위배됩니다 ... 나는 그것에 힘이 없다고 생각합니다 ...

모든 팁 / 아이디어는 대단히 감사하겠습니다 ...

내 마음에 당신이 가진 문제는 좋은 이름을 내릴 수있는 더 좋은 방법을 찾는 것이 아니라 그렇게하는 강박을 다루는 것입니다. 내가 정직하면 나 자신도 비슷한 특성을 인식합니다. 결국 이름은 중요하며, 현재 작업중인 개념에 대한 좋은 이름을 좋아합니다. 그러나 항상 가장 중요한 것은 아닙니다.

이러한 종류의 문제를 극복하기 위해 사용하는 몇 가지 방법은 다음과 같습니다.

1. 완벽한 솔루션이없고 다른 솔루션보다 나은 솔루션 만 있다는 것을 인식하십시오.
2. 먼저하자. 프로그래밍 과제를 완료하는 것보다 완료하는 것이 더 중요합니다.
3. 다른 사람들에게 물어보십시오. 우리 모두는 우리가 늪지대에있는 지역을 가지고 있지만, 다행스럽게도 다른 사람들이 다른 곳에서 늪지대에 있습니다. 아마도 다른 누군가가 좋은 이름을 찾거나 실제로 중요하지 않다고 말할 것입니다.
4. 시간 제한을 설정하십시오. 끊어진 일을하기 위해 자신을 x 분만 기다린 다음 계속 진행하십시오.
5. 나중에 다시 오겠다고 약속하십시오. 다시 가고 싶은 것들을 기록하십시오. 이런 종류의 문제는 조금만 내버려두면 더욱 명확 해집니다. 나중에 더 나은 이름을 찾거나 실제로 중요하지 않다는 것을 알게 될 것입니다.
6. 100 년 안에 아무도 돌보지 않을 것임을 인식하십시오.
7. 반대를하십시오. 반에게 정말 나쁜 이름을 지어주고 무슨 일이 일어나는지보십시오. 이것은 더 나은 이름으로 시간을 보내야 할 필요성을 확인하거나 그것이 얼마나 중요한지 보여줄 것입니다. 또한 이것은 강박 관념에서 벗어날 수 있도록 도와줍니다.
8. 빌다. 이것은 종종 저에게 효과적입니다.
9. 당신이하는 일과는 별개로 자신을 가치있게하십시오. 자신의 가치가 완벽을 제공한다는 데서 오는 생각에서 벗어나십시오. 직무와는 별개로 본질적인 가치가 있음을 인식 할 때, 우리는 우리 자신의 표준에 맞지 않을 때 수치심이 줄어 듭니다.
10. 새로운 단어를 만들어 수업의 이름을 정하거나 오래된 단어를 재사용하십시오. 프로그래밍은 창의적인 과정이며, 때때로 우리가 포착하는 아이디어는 새로운 아이디어입니다. 새로운 아이디어에는 새로운 이름이 필요합니다. "EmployeeTransmogrifier"는 수업에 완벽하게 유효한 이름입니다.
11. 잘못된 문제를 해결하려고합니다. 예를 들어, 호출자의 요구가 무엇인지에 대한 명확한 아이디어없이 API를 작성하는 것은 좋지 않습니다. 이 문제를 해결하면 명명 문제가 훨씬 쉬워 질 수 있습니다.
12. 점심 먹자. 점심은 항상 좋습니다.

먼저

"이 수업의 단일 목적은 무엇입니까?" 단일 책임 원칙 (Single Responsibility Principle)을 준수하지 않으면 클래스 및 메소드 이름 지정이 매우 어려워집니다. 그 질문에 대답 할 수 없다면, 반원들이하고 싶은 일을 다시 생각하고 우려를 분리하는 것을 고려해야합니다. 이렇게하면 이름을 쉽게 지정할 수 있습니다

둘째로

수업 이름을 어떻게 정하는가? 아마도 SRP를 해결하고 나면 따라 가기 쉬운 패턴과 같은 일반적인 이름 지정 패턴을 살펴보십시오. 클래스가 XML을 구문 분석합니까? XMLParser를 사용해보십시오. XML을 구문 분석하고 입력을 나타내는 도메인 모델을 작성하여 DB에 유지 한 다음 성공 메시지를 Twitter에 게시합니까? 리팩토링을 시도하십시오.

셋째

나는 당신이 어디에서 왔는지 이해하고 전에 비슷한 상황에 처해 있습니다. 아마도 임시 이름으로 시작하여 몇 가지 기능으로 수업을 마무리 해보십시오. 좋은 IDE 또는 리팩토링 지원을 사용하면 클래스 이름을 바꾸는 것이 한 번의 클릭 동작이어야하므로 클래스 이름을 지정하는 것이 영구적 일 필요는 없습니다! 이것은 당신이 당신의 OCD 블록을 빠져 나가도록 도와 줄 것이고, 잠재 의식이 조금 더 그것을 처리 할 시간을 줄 것입니다.

마지막으로 약간 벗어난 주제

나는 다른 날에 중요하지 않은 시스템을 구현하는 일에서 전구 순간을 보냈고 다른 클래스의 이름 지정 등으로 놀아 보는 데 시간을 보냈습니다 ... 기능에 따라 인터페이스 이름을 지정하고 이름을 지정하십시오. 특정 구현에 따른 클래스 ... 예를 들어, IXMLParser와 XMLParser를 갖고 싶은 유혹이 있지만 입력이 JSON으로 변경되면 어떻게됩니까? 대신 IInputParser를 사용해보십시오. 그러면 다른 방법으로 IInputParser를 구현하는 구체적인 클래스 XMLParser 및 JSONParser를 만들 수 있습니다.

나를 위해 그것은 일반적으로 디자인이 내 마음에 명확하지 않다는 표시입니다. 그래서 나는 이름을 만들고 그 시간이 끝날 때 더 나은 것을 만들 수있는 시간 (2 분)을주었습니다. 내가 처음 생각 해낸 것을 사용하십시오. Barney, Wilma 및 Fred가 시작하는 것이 가장 좋습니다. "BarniesInputParser"와 같은 작업을 수행합니다. 이름이 너무 나빠서 더 나은 이름을 찾거나 나중에 변경해야합니다. 그들은 또한 독특하여 리팩토링을 사소하고 안전하게 만듭니다. 불완전한 코드를 보는 사람은 즉시 불완전하다는 것을 알 수 있습니다.

중요한 것은 기능을 추가하지 않는 동안 뇌에 이름을 정의하고 디자인을 명확하게하는 데 사용할 새로운 정보를 제공하지 않는다는 것입니다. 당신이하고있는 일은 다른 방법으로 동일한 입력을 역류시키는 것입니다.

아니면 커피를 만들어 당신이 기계에 도착하기 전에 당신은 그것을 가질 것입니다 ...

나는 잠시 후에 친구에게서 이것을 얻었다. 프로세스가 수행해야 할 작업을 작성하십시오. 짧은 이야기. 그런 다음 명사를 가져 와서 클래스로, 동사를 메소드로, 부사는 속성으로 바꾸십시오.