나쁜 디자인의 기준
인생은 매우 간단하게 작동합니다. 종종 똑똑해지기 위해 어리석은 일을 할 필요가 없습니다. 이는 소프트웨어 개발에도 적용됩니다. 대부분의 경우 어떤 일을 잘하기 위해서는 나쁘게만 하지 않으면 됩니다.
대부분의 프로그래머는 잘못 설계된 시스템 부분에 대한 경험이 있습니다. 그러나 더 슬프게도 대부분의 여러분은 자신이 그러한 시스템의 저자라는 사실을 깨닫는 슬픈 경험을 할 것입니다. 우리는 최고를 원했지만 언제나처럼 밝혀졌습니다.
대부분의 개발자는 나쁜 아키텍처를 열망하지 않으며 많은 시스템의 경우 아키텍처가 끔찍하다고 말하기 시작하는 시점이 있습니다. 왜 이런 일이 발생합니까? 건축 설계가 처음부터 좋지 않았습니까, 아니면 시간이 지남에 따라 나빠졌습니까?
이 문제의 근본 원인은 "나쁜" 디자인에 대한 정의가 없다는 것입니다.
모든 프로그래머에게 가장 중요한 자질은 디자인의 품질과 그 "부패"의 이유에 대한 이해인 것 같습니다. 대부분의 다른 경우와 마찬가지로 중요한 것은 문제를 식별하는 것이며 이를 해결하는 것은 기술의 문제일 것입니다.
"나쁜 디자인"의 정의
동료 프로그래머 앞에서 자신의 코드에 대해 자랑하기로 결정하면 “누가 이런 일을 하는 거지?”, '왜 이러지?'라는 비웃음을 받을 가능성이 큽니다. 그리고 "나는 일을 다르게 할 것입니다." 이것은 매우 자주 발생합니다.
모든 사람은 다르지만 여전히 동료 프로그래머를 위해 코드를 작성하므로 각 기능을 개발하는 과정에서 다른 사람들이 코드를 볼 때 항상 검토 단계가 필요합니다.
그러나 많은 일을 다른 방식으로 수행할 수 있더라도 모든 개발자가 동의하는 일련의 기준이 있습니다. 요구 사항을 충족하지만 여전히 하나(또는 그 이상)의 특성을 나타내는 코드 조각은 잘못된 설계입니다.
나쁜 디자인:
- 모든 변경 사항이 시스템의 다른 많은 부분에 영향을 미치기 때문에 변경하기 어렵습니다. ( 강성 , 강성).
- 변경이 이루어지면 시스템의 다른 부분이 예기치 않게 중단됩니다. ( 취약성 , 취약성).
- 코드를 현재 애플리케이션에서 꺼내기가 너무 어렵기 때문에 다른 애플리케이션에서 코드를 재사용하기 어렵습니다. ( 부동성 , 부동성).
재미있는 점은 이러한 특성(즉, 유연하고 신뢰할 수 있으며 재사용 가능)을 포함하지 않고 요구 사항을 충족하는 동시에 설계가 나쁜 시스템을 찾는 것이 거의 불가능하다는 것입니다 . .
따라서 이 세 가지 특성을 사용하여 디자인이 "나쁜"지 "좋은"지 명확하게 판단할 수 있습니다.
"나쁜 디자인"의 원인
디자인을 단단하고 부서지기 쉽고 움직이지 않게 만드는 것은 무엇입니까? 모듈의 엄격한 상호 의존성.
쉽게 변경할 수 없는 디자인은 경직된 것입니다 . 이러한 경직성은 직조 시스템의 코드 조각에 대한 단일 변경이 종속 모듈의 계단식 변경을 초래한다는 사실에 기인합니다. 이것은 한 사람이 코드 작업을 할 때 항상 발생합니다.
이로 인해 전체 상용 개발 프로세스가 즉시 복잡해집니다. 설계자나 개발자가 계단식 변경의 수를 예측할 수 없는 경우 이러한 변경의 영향을 예측하는 것이 불가능합니다. 따라서 이러한 변경을 무기한 연기하려고 합니다.
그리고 이것은 변화의 비용을 예측할 수 없게 만듭니다. 이러한 불확실성에 직면한 관리자들은 변화를 꺼리기 때문에 공식적으로 설계가 경직됩니다.
어느 시점에서 귀하의 프로젝트는 "이벤트 호라이즌"을 통과하고 경직된 아키텍처의 "블랙홀"에 빠질 운명입니다.
취약성 은 시스템이 한 번의 변경 후에 여러 곳에서 무너지는 경향입니다. 일반적으로 새로운 문제는 변화의 장소와 개념적으로 관련이 없는 장소에서 발생합니다. 이러한 취약성은 시스템의 설계 및 유지 관리에 대한 신뢰를 심각하게 약화시킵니다.
이는 일반적으로 개인 메서드가 없는 경우에 해당합니다. 모든 방법을 공개하는 것으로 충분하며 깨지기 쉬운 아키텍처의 외관에 처하게 될 것입니다. 캡슐화는 마이크로 수준에서 이를 처리하는 데 도움이 됩니다. 그러나 거시적 수준에서는 모듈식 아키텍처가 필요합니다.
프로젝트에 취약한 아키텍처가 있는 경우 개발자는 제품의 품질을 보장할 수 없습니다.
응용 프로그램의 한 부분에 대한 간단한 변경으로 인해 관련 없는 다른 부분에 버그가 발생합니다. 이러한 오류를 수정하면 더 많은 문제가 발생하고 에스코트 프로세스는 자신의 꼬리를 쫓는 유명한 개로 변합니다.
시스템의 필요한 부분이 원치 않는 다른 세부 사항과 강하게 연결되어 있으면 디자인이 움직이지 않습니다 . 자체 코드, 고유한 접근 방식 및 솔루션이 너무 많습니다.
아무 이유 없이 개발자가 자체 로깅 수준을 제시한 JUL 로거를 기억하십니까? 이것은 단지 사실입니다.
디자이너에게 기존 디자인을 재사용하는 것이 얼마나 쉬운지에 대한 아이디어를 제공하려면 새 응용 프로그램에서 사용하기가 얼마나 쉬운지 생각하는 것으로 충분합니다.
디자인이 밀접하게 결합된 경우 이 디자이너는 불필요한 세부 사항에서 시스템의 필수 부분을 분리하는 데 필요한 작업량에 겁을 먹을 것입니다. 대부분의 경우 이러한 디자인은 처음부터 개발하는 것보다 분리하는 비용이 더 크기 때문에 재사용할 수 없습니다.
관련성
모든 것은 변하지만 모든 것은 동일하게 유지됩니다. (중국 속담)
위에서 매우 좋은 질문이 제기되었습니다. 취약하고 경직된 시스템의 위험은 무엇입니까? 예, 그러한 프로젝트를 관리하는 프로세스는 예측할 수 없고 제어할 수 없기 때문입니다. 그리고 가격이 엄청나다.
관리자가 실제로 시간이 얼마나 걸릴지 모르는 경우 기능을 추가하기 위해 미리 결정을 내리거나 내리지 않을 수 있습니까? 구현 시간과 복잡성을 적절하게 예측할 수 없는 경우 작업의 우선 순위를 지정하는 방법은 무엇입니까?
그리고 우리가 지불할 때 개발자는 어떻게 동일한 기술 부채를 갚을 수 있으며, 우리가 긁어모을 때까지 우리가 얼마나 긁을 것인지 이해할 수 없습니까?
코드 재사용 또는 테스트 문제도 매우 관련이 있습니다. 단위 테스트는 테스트 중인 단위에 대한 몇 가지 가정을 테스트하는 역할을 할 뿐만 아니라 응집도를 결정하고 재사용 지표 역할을 할 수 있습니다.
다음은 이 사례에 대한 Bob Martin의 인용문입니다 . 그렇지 않으면 아무도 이 문제에 신경쓰지 않을 것입니다.
디자인 원칙과 패턴을 사용하는 것은 하나의 목적, 즉 디자인을 좋게 만드는 것입니다. 그것들의 사용이 당신에게 어떤 이점도 주지 않는다면(또는 그 반대의 경우도 "좋은 디자인"의 원칙을 위반하는 경우), 당신의 온실에 있는 무언가가 옳지 않으며 아마도 도구가 다른 목적으로 사용되기 시작했을 것입니다.