복잡성을 언제 제거해야합니까?


14

디자인 패턴이 필요하기 전에 구현하여 복잡성을 조기에 도입하는 것은 좋은 습관이 아닙니다.

그러나 모든 (또는 대부분의) SOLID 원칙을 따르고 공통적 인 디자인 패턴을 사용하는 경우 기능과 요구 사항이 추가되거나 변경되어 디자인을 유지 관리 가능하고 유연하게 유지하기 위해 약간의 복잡성이 발생합니다.

그러나 일단 그 복잡성이 도입되어 챔피언을 제거했을 때 챔피언처럼 작동합니까?

예. 클라이언트를 위해 작성된 응용 프로그램이 있습니다. 원래 몇 가지 방법으로 직원에게 인상을 줄 수있는 곳을 만들었을 때. 전략 패턴과 팩토리를 사용하여 전체 프로세스를 훌륭하고 깨끗하게 유지했습니다. 시간이 지남에 따라 응용 프로그램 소유자가 추가하거나 제거하는 특정 인상 방법.

시간이 지나고 새로운 소유자가 인수합니다. 이 새로운 주인은 코가 단단하고 모든 것을 단순하게 유지하며 인상을 줄 수있는 유일한 방법이 있습니다.

전략 패턴에 필요한 복잡성은 더 이상 필요하지 않습니다. 요구 사항에서이를 코딩 할 위치를 지정하면이 추가 복잡성을 도입하지는 않지만 필요한 경우 작업을 거의 또는 전혀하지 않고 도입 할 수 있는지 확인하십시오.

이제 전략 구현을 제거합니까? 나는이 새로운 소유자가 인상이 어떻게 제공되는지를 바꿀 것이라고 생각하지 않습니다. 그러나 응용 프로그램 자체는 이것이 일어날 수 있음을 보여주었습니다.

물론 이것은 새로운 소유자가 많은 프로세스를 인수하고 단순화 한 응용 프로그램의 한 예일뿐입니다. 수십 개의 클래스, 인터페이스 및 팩토리를 제거하고 전체 응용 프로그램을 훨씬 간단하게 만들 수 있습니다. 현재 구현은 잘 작동하고 소유자는 그것에 만족합니다 (그리고 논의 된 복잡성으로 인해 그녀의 변경 사항을 너무 빨리 구현할 수 있다는 사실에 놀랐고 더 행복했습니다).

이 의심의 작은 부분은 새로운 소유자가 더 이상 나를 사용하지 않을 가능성이 높기 때문에 인정합니다. 나는 그것이 큰 수입원이 아니기 때문에 다른 누군가가 이것을 인수 할 것을 정말로 걱정하지 않습니다.

하지만 나는 2 가지 (관련) 것들에 관심이있다

  1. 코드를 이해하려고 할 때 새로운 관리자가 조금 더 열심히 생각해야한다는 점에 약간 관심이 있습니다. 복잡성은 복잡하며 나는 정신 미치광이가 나를 뒤 따르도록 분노하고 싶지 않습니다.

  2. 그러나 경쟁 업체가 이러한 복잡성을보고 작업 시간을 채우기 위해 디자인 패턴을 구현한다고 생각하는 것보다 더 걱정하고 있습니다. 그런 다음이 소문을 퍼뜨려 다른 사업에 피해를 입혔습니다. (이 언급을 들었습니다.)

그래서...

일반적으로 이전에는 복잡성이 필요했지만 이전에는 복잡성에 대한 요구가 있었지만 과거에는 복잡성이 제거되어야했지만 앞으로 필요할 것이라는 표시는 없습니까?

위의 질문이 일반적으로 "아니오"로 대답 되더라도 프로젝트를 경쟁자 (또는 낯선 사람)에게 건네 줄 경우이 "필요하지 않은"복잡성을 제거하는 것이 현명합니까?

답변:


7

어떤면에서는 이것이 주로 비즈니스 결정이며 코드 자체를 기반으로하는 것은 아니라고 생각합니다. 고려해야 할 사항 :

  • 변경 비용을 지불하고 있습니까?
  • 코드가 현재 예상대로 작동합니까?
  • 코드에 보안 또는 성능 문제가 있습니까?
  • 기술 부채 금액이이를 수정하는 비용보다 많은가?
  • 코드를 그대로두면 실제로 어떤 일이 일어날까요?
  • 리팩토링의 유무에 관계없이 발생할 수있는 미래의 문제점은 무엇입니까?
  • 귀하와 귀하의 비즈니스에 대한 코드의 책임은 얼마입니까?

당신은 그 질문에 대답하기에 가장 좋은 위치에 있습니다. 그러나 귀하의 설명에 따르면, 시간이 가치가있는 것처럼 들리지 않기 때문에 리팩토링 및 단순화를 방해하는지 여부는 알 수 없습니다. 현재 작동한다면 고객은 행복하고 모든 것을 업데이트하여 돈을 받고 싶지 않다면 수익 창출 활동에 참여하십시오.

간단히 말해서 두 경로 모두에 대한 비용-편익 분석 및 위험 평가를 수행하고 가장 안전하고 효율적이며 가장 수익성 높은 조치를 취하십시오.


6

고객이 고려하고 지불해야하는 기능을 나중에 코딩하기 쉽도록이 코드를 제거하고 간단한 것으로 대체하지 않습니까?

다른 개발자가 배울 수있는 유용한 정보가있을 수 있지만 다른 클라이언트의 앱을 찾아서 연결할 가능성은 적습니다.

경쟁사의 코드를 험담하는 것은 막을 수있는 것이 아닙니다. 고객을 부정적으로 모집하려고하는 것은 어리석게 보일 것입니다.


"지불"+1 고객에게 변경 비용을 지불하도록 요청하려면 고객이 변경 여부를 결정하도록 허용해야합니다. 시스템을 유연하게 유지하면 NEXT 소유자가보다 쉽게 ​​변경할 수 있으므로 비즈니스의 재판매 가치에 어느 정도의 금액이 추가됩니다.
John R. Strohm

3

일반적인 말은 "파산하지 않으면 고치지 마십시오"입니다.

이 규칙에는 몇 가지 합리성이 있습니다. 그 중 일부는 "단순화"가 새롭고, 다르고, 더 큰 버그를 도입 할 위험이 있고, 다른 귀중한 노력에서 멀어 질수록 개발 시간이 길어질 수 있으며, 예기치 않은 미래의 비즈니스 기회에 대한 잘못된 변화 일 수 있습니다. 발생합니다.

이 코드를 이식성 있고 유지 관리하기에 충분한 비즈니스 가치가있는 경우 해당 코드가 현재 코드 "파손"을 고려하기에 충분한 지 결정하십시오. 주요 사업 확장이 계획되어 있거나 사업을 중단시킬 수있는 복잡성에 숨겨진 잠재적 버그가 의심되는 경우에 적합합니다.


2

우선, 새로운 소유자가 앱을 이미 인수 한 경우 다시 발생할 수 있습니다. 그리고 다음 소유자는 다시는 그 혜택을 누리지 못하는 복잡성을 다시 사용할 수 있습니다.

이 외에도 작업 코드에 대한 사소한 변경은 항상 위험을 수반하므로 고객은 (다른 사람들이 지적했듯이) 고객이 이에 동의하고 지불해야합니다. 현재의 "추가"복잡성으로 인해 성능 문제와 같이 눈에 띄고 측정 가능한 단점이 발생하지 않으면이를 제거 할 강력한 이유가 없습니다.

(잠재적) 경쟁 업체의 소문에 근거하여 귀하를 고용하지 않는 고객은 수입이 절실히 필요하지 않은 한 IMHO의 가치가 없습니다. 당신이했던 방식대로 앱을 구현 한 이유는 합리적이고 논리적이며, 모든 심각한 고객은 그것을 이해할 것입니다. 어쨌든 당신에게 묻지 않거나 심지어 귀찮게하지 않는 사람은 어쨌든 직업의 가치보다 더 많은 문제를 일으킬 것입니다.


1

일반적으로 이전에는 복잡성이 필요했지만 이전에는 복잡성에 대한 요구가 있었지만 과거에는 복잡성이 제거되어야했지만 앞으로 필요할 것이라는 표시는 없습니까?

아니.

위의 질문이 일반적으로 "아니오"로 대답 되더라도 프로젝트를 경쟁자 (또는 낯선 사람)에게 전달할 경우이 "필요하지 않은"복잡성을 제거하는 것이 현명합니다.

아니요. 우선 순위가 낮은 문제를 해결하기 위해 시간을 낭비하는 이유는 무엇입니까? 거기에 머무는 코드에 해를 끼치 지 않습니다.

귀하의 질문에 관해서 : 복잡성을 언제 제거해야합니까?

내 취지는 그것이 깨지지 않으면 고치지 마십시오 .


0

복잡성을 제거하려면 다음 사항이 충족되어야합니다.

  1. 제거 된 부분은 프로그램과 독립적이어야합니다. 주변 프로그램에서 문제의 코드에 대한 종속성이 있으면 복잡성을 제거해도 작동하지 않습니다.
  2. 불행히도 복잡해 보이는 경우 조각이 독립적이지 않고 조각을 제거 할 때 종속성이 프로그램을 중단시킬 가능성이 큽니다.
  3. 모든 종속성을 제거하는 데 시간이 걸리므로 작업이 노력할만한 가치가 있는지 추정 할 때 시간을 고려해야합니다.
  4. 대부분의 경우 노력할 가치가 없지만 이전 코드를 사용하는 새 코드를 만들지 않기로 결정합니다.

그들은 독립적이며 실제로 제거했으며 모든 단위 / 통합 / 회귀 테스트를 통과했습니다. 복잡성은 단순히 전략을 구현하기 위해서는 최소한 인터페이스와 해당 인터페이스의 구체적인 구현이 필요합니다. 새로운 소유자가 단순화 한 24여 곳에서 단일 클래스로 수행 할 수 있습니다.
ElGringoGrande 1

0

여기에는 더 큰 무언가가 있다고 생각합니다 ... 확장 성

당신이 말하는 것은 확장 성 입니다. 코딩이 복잡한 지 여부는 중요하지 않습니다. 새로운 비즈니스 규칙 또는 변경된 비즈니스 규칙을 기반으로 애플리케이션을 발전시킬 수 있는지 여부가 중요합니다. 다음 소유자가 완전히 다른 것을 원하면 어떻게됩니까?

그래서 코드를 유지하고 문서화한다고 말합니다. 응용 프로그램을 활용하는 방법의 특징입니다.


0

일반적으로 이전에는 복잡성이 필요했지만 이전에는 복잡성에 대한 요구가 있었지만 과거에는 복잡성이 제거되어야했지만 앞으로 필요할 것이라는 표시는 없습니까?

복잡성을 제거하려는 노력과 위험이 있습니다. 지나치게 복잡한 코드를 유지하기위한 추가 노력과 위험보다 높은 경우 유지하십시오. 그렇지 않으면 제거합니다. 그러나 이러한 위험을 추정하기는 어렵습니다.

코드에서 디자인 패턴 전략을 사용한 이유 를 문서화하여 유지 관리가 더 어려운 위험을 줄일 수 있다고 덧붙 입니다. 필자는 개인적으로 모든 디자인 패턴이 명시 적 요구 사항 (기능 또는 비 기능)으로 추적 가능해야한다고 생각합니다.

위의 질문이 일반적으로 "아니오"로 대답 되더라도 프로젝트를 경쟁자 (또는 낯선 사람)에게 건네 줄 경우이 "필요하지 않은"복잡성을 제거하는 것이 현명합니까?

패딩 시간에 대한 경쟁으로 인해 소멸되는 시나리오는 복잡성을 문서화해야하는 이유입니다. 패턴의 사용을 문서화하고 (특정 고객 요구 사항과 함께) 정당화하면 보장됩니다. 고객의 요구 사항에 따라 패턴을 정당화 할 수 없으면 과잉 설계 또는 패턴 염처럼 보입니다.

요구 사항이 변경되면 코드를 손상시킬 수있는 위험 (또는 외과 적으로 패턴을 제거하는 작업량)으로 인해 그대로 두는 것이 정당 할 수 있습니다.


패턴이 종종 두 가지를 모두 포함하기 때문에 우발적 인 복잡성과 필수 복잡성 을 구별하는 것이 좋다고 생각합니다 .

즉, 인상 결정을위한 다양한 알고리즘을 지원해야하는 요구 사항은 본질적으로 복잡합니다 (해결해야 할 문제의 일부). 유지 보수 코드의는 전략 패턴에 의해 쉽게 구성되어 있지만,이 경우 / 다음 대안 전략 것이다 여전히 작업에 하드 코딩. 저는 학생들이 오픈 소스 프로젝트에 전략을 적용 할 수있는 기회를 찾는 석사 과정에서 연습을했습니다. 전략을 적용 할 때 복잡성이 반드시 나을 필요는 없습니다 ( 필수 복잡 하기 때문에 ). 코드가 하나의 큰 if / then / else 블록이 아니라 다형성을 갖는 여러 클래스로 분할되기 때문에 때로는 전략을 이해하기가 더 어려울 수 있습니다.

이상적으로는 패턴이 제공하는 이점이 단점의 비용보다 많은 경우 패턴이 작동합니다. 다시, 이러한 것들을 정량화하는 것은 어렵다. 패턴은 종종 개발자를 행복하게 만듭니다 (새로운 인상 전략을 쉽게 추가 할뿐 아니라 개발자에게 패턴이 적용되었다는 것을 알려주는 따뜻한 퍼지). 고객에게 어떻게 혜택이 있는지를 보여주기는 어렵습니다.

고객은 세부 사항을 신경 쓰거나 이해하지 못합니다. 새로운 소유자가 프로세스에 KISS를 적용하는 경우 소프트웨어 솔루션에 영향을 줄 수있는 필수 복잡성을 줄입니다.

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