유사한 기능에 다른 패턴 사용


10

저는 다른 소프트웨어 프로젝트와 마찬가지로 향후 다른 사람이 사용할 수있는 프로젝트의 유일한 개발자입니다.

기능 A를 구현하기 위해 패턴 X를 사용했다고 가정 해 봅시다. 기능을 개발하고 마무리 한 후에 방금 배운 패턴 Y를 사용하여 동일한 기능을 구현할 수 있다는 것을 알게되었습니다. 그러나 기능 A는 훌륭하게 작동하며 X에서 Y로 리팩토링하는 데 시간이 오래 걸리고 이점이 거의 없습니다.

그런 다음 기능 B를 구현할 차례입니다. A와 비슷하지만 이번에는 패턴 Y를 사용하여이 기회를 잡으려고합니다. 기능 A를 수행 할 때보 다 최종 결과에 만족하지만, 이제 코드는 두 가지를 사용합니다. 유사한 특징을 위해 다른 패턴, X와 Y.

그러나 피쳐 AI를 빌드 할 때 피쳐 B와 동일한 패턴을 사용할만큼 숙련되지 않았다는 점을 제외하고는 다른 패턴을 사용해야하는 실제 이유가 없습니다.

이 질문은 주어진 문제에 대한 올바른 패턴을 선택하는 것이 아닙니다 . 비슷한 문제를 해결하기 위해 코드베이스에 공존하는 두 가지 패턴이 있습니다. 리팩토링에 충분한 시간이 주어질 수 있습니다.

  • 그 코드 냄새가나요?
  • 소스 코드를 이와 같이 유지하면 어떤 단점이 있습니까?
  • 하나의 패턴 만 사용해야 만합니까? 즉, B를 쓸 때 A를 사용하여 Y를 사용하거나 X를 계속 사용합니까?
  • 소스에서 유사한 기능에 대해 서로 다른 두 가지 패턴이 존재하는 이유가 근본적인 이유가 아니라고 어떻게 알 수 있습니까?
  • 다음 개발자가 내 코드에 대해 어떻게 생각하는지에 대해 너무 걱정하고 있습니까?

답변:


7

패턴 X와 Y가 같은 문제를 해결하고 어느 쪽도 객관적으로 나아지지 않는다면, 하나를 결정하고 고수해야합니다. 가능하다면 동일한 문제를 동일한 방식으로 일관되게 해결하려고 노력해야합니다.

당신은 너무 걱정 하지 않고 오히려 처리하고 정리 해야하는 심각한 코드 냄새입니다.

코드베이스에서 동일한 문제에 대한 다른 솔루션을 갖는 단점 :

  • 코드를 이해하는 데 두 배가 걸립니다
  • 패턴과 관련된 동작을 변경하면 코드를 수정하는 데 두 배가 걸립니다.
  • 당신은 두 배나 많은 버그를 가질 것입니다
  • 현재와 ​​미래의 동료가 당신을 미워할 것입니다

2

JacquesB의 답변에 동의합니다 . 결론적으로 다른 두 가지 질문을 해결하면서 두 패턴이 공존하고 응용 프로그램을 리팩토링 할 시간이 없었지만 가장 좋은 것으로 생각한 시간이 없다면 "불쾌"클래스 (리팩토링 될 클래스)에 대한 귀하의 의견. 이런 식으로, 미래 개발자 (귀하 또는 다른 누군가)에게 지불해야 할 부채가 여전히 남아 있음이 분명합니다.

마지막으로 이와 같은 코드 기반을 유지 관리하는 데 따른 주요 단점은 추가되었지만 불필요한 복잡성입니다. 모든 비용으로 불필요한 복잡성을 피하고 싶을 것입니다!


오히려 일종의 할 일 목록에서 또는 적어도 코드의 메모 외에 이것을 볼 수 있습니다.
JeffO

@JeffO 동의합니다. 할 일 목록에만 의존하는 것이 추가적인 문제가없는 것은 아니지만 대부분의 경우 공유 코드 기반의 주석과 반대되는 개인 (공유되지 않음)이기 때문입니다. 그러나 다시 한 번 동의하며, 두 가지 모두를 갖는 것이 좋습니다. (그들이 결정적으로 시작하는 것을 피할 수 없을 때).
carlossierra

그건 좋은 지적이야. 공유, 협업, 커뮤니케이션 및 기타 재미있는 것들을 포함하는 것은 일반 Todo 목록 이상의 것이어야합니다.
JeffO

1

코드베이스에서 플레이하지 마십시오. 프로토 타입을 작성하면 한 패턴 / 디자인의 장점과 단점을 다른 패턴 / 디자인보다 찾을 수 있습니다.

직관적으로 느끼는 것이 줄어들 수 있으며 실제로는 두 가지 패턴을 갖는 것보다 더 복잡 할 수 있습니다.

프로토 타입을 위해 개발 된 많은 코드를 던질 것으로 예상하십시오.


1

이것이 코드 냄새인지 여부는 실제로 A와 B 문제가 얼마나 비슷한 지에 달려 있습니다. JacquesB의 답변은 그것들이 매우 유사하다고 가정하는 것 같으며, 문제 A를 변경하면 (예를 들어 버그를 수정하기 위해) 동시에 문제 B도 변경해야한다고 생각합니다. JaqueB는 옳을 수 있지만 A와 B가 모두 비슷하지 않기 때문에 독립적으로 변경되는 경우도 있습니다. 이러한 상황에서는 단점을 설명하지 않을 것입니다.

설명에 따르면 약간의 코드 냄새 (복제)처럼 들리지만 냄새가 얼마나 냄새가 나는지 말하기는 어렵습니다. 예를 들어 A가 템플릿 방법을 사용하고 B가 전략을 사용하는 경우 사용되는 미러링 패턴에도 불구하고 두 가지 문제가 매우 다를 수 있습니다. 나는 기다렸다가 접근하는 것을 보았다. C 문제가 발생하고 A 및 B와 같은 경우 A를 B와 일치하도록 리팩터링 한 다음 C를 만드는 것은 매우 간단합니다. A에 버그가있는 경우 B와 일치하도록 리팩토링하고 싶습니다. 버그를 수정하십시오. 아무것도 바뀌지 않으면 .... 그것은 중요하지 않습니까?

코드베이스에서 유사한 문제를 해결하는 여러 가지 방법이있는 것은 인생의 사실입니다. 유일한 개발자 인 경우에도 새로운 것을 배우고 새로운 통찰력을 가지므로 솔루션이 바뀔 것입니다. 올바르게 인식하면 가치를 제공하면서 이러한 결함을 수정해야합니다. 다시 변경되지 않는 코드 재 설계 (패턴을 변경할 때 실제로 수행하는 작업)는 가치를 제공하지 않습니다. 그것이 어떻게 변할 것인지를 알 수있는 유일한 방법은 실제로 변화를해야하는 것입니다.


1

아니요, 단일 코드 기반에서 여러 패턴을 사용할 수 있습니다.

그러나 구성 요소를 구현하고 패턴을 따르는 구성 요소를 사용하는 방법을 노출하는 경우 구성 요소를 따르는 것이 가장 좋습니다. 예를 들어 REST 쿼리 클라이언트에 빌더 패턴을 사용하고 있지만 리소스 중 하나를 다르게 구현한다고 가정 해보십시오. 사람들을 혼란스럽게 할 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.