역사적으로 성장한 소프트웨어를위한 명명 된 안티 패턴이 있습니까? [닫은]

여러 개발자가 방금 시스템에 새로운 기능을 추가했지만 아무도 전체 아키텍처를 주시하거나 리팩토링을 수행하지 않은 역사적으로 성장한 소프트웨어 시스템을 설명하는 안티 패턴이 있습니까?

관리 / 고객이 지속적으로 새로운 기능을 요구하고 아무도 리팩터링하지 않고 다른 개발자가 이전에 한 일을 추가 할 때 이런 일이 발생한다고 생각합니다.

개발자가 소프트웨어 시스템에 압도되어 현재 작동 방식을 실제로 이해하지 못하고 코드를 리팩토링하고 변경하는 대신 코드를 추가 / 붙여 넣기 만하는 이유도있을 수 있습니다.

따라서 시간이 지남에 따라 시스템을 유지 관리하기가 점점 더 어려워지고 있습니다.

(전반적인 디자인을 생각하지 않고 점점 더 많은 기능을 추가하여 제작 된 자동차와 같이 프로그래밍에 익숙하지 않은 사람들에게 더 명확하게하기 위해 이러한 종류의 안티 패턴에 대한 그림이 있는지 궁금합니다. 트레일러를 뒤로 타면서 트레일러를 타면 엔지니어가 견인 바를 차 앞쪽에 용접하기 만하면됩니다.하지만 작업이 완료되었지만 이제는 물통이 더 이상 열리지 않습니다.)

기술 부채를 참조하십시오 .

우리는 모두 시간이 지남에 따라 개발 한 제품에 기술적 부채를 발생시킵니다. 리팩토링은이 기술 부채를 줄이는 가장 일반적이고 효과적인 방법 중 하나이지만, 많은 회사에서 기술 부채를 지불하지 않습니다. 이 회사들은 소프트웨어가 수년 동안 극도로 불안정한 경향이 있으며 기술 부채는 너무 끔찍 해져서 그 방식으로 지불하는 데 시간이 너무 오래 걸리기 때문에 점차적으로 지불 할 수 없습니다.

기술 부채는 부채의 동일한 행동을 따르기 때문에 용어가 있습니다. 빚을지고, 지출을 계속하고 (특징을 작성하고) 빚을 갚지 않으면 계속 증가 할 것입니다. 부채와 마찬가지로 부채가 너무 커지면 전체 재 작성과 같은 위험한 작업으로 부채를 완전히 버리려는 지점에 도달하게됩니다. 또한 실제 부채와 마찬가지로 특정 시점에 발생하므로 지출 (기능 생성) 기능을 완전히 방해합니다.

혼합에서 다른 용어를 던지기 위해 응집력 은 시스템, 마이크로-라인 레벨 또는 매크로-시스템 레벨이 얼마나 잘 맞는지를 나타냅니다. 응집력이 높은 시스템은 모든 부분이 잘 어울리 며 한 엔지니어가 모든 것을 쓴 것처럼 보입니다. 코드를 마지막에 붙이는 누군가에 대한 위의 언급은 해당 시스템의 응집력을 위반하는 것입니다.

기술 부채 관리

기술 부채를 관리하는 방법에는 여러 가지가 있지만 실제 부채와 마찬가지로 최선의 방법은 자주 부채를 갚는 것입니다. 불행히도 실질 부채와 같이 단기간에 더 많은 수익을 올리는 것이 더 좋은 아이디어입니다. 까다로운 부분은 이러한 경쟁 우선 순위를 평가하고 부채 ROI 가 주어진 기능과 가치에 대해 가치가없는 시점을 식별하는 것입니다.

따라서 때로는 짧은 기간 동안 부채를 발생시키는 것이 가치가 있지만, 거의 모든 경우와 달리 모든 부채와 마찬가지로 기간이 짧을수록 좋습니다. 따라서 기술 부채가 발생하면 결국 (바람직하게는 빨리 ) 지불해야합니다. 일반적인 접근 방식은 다음과 같습니다.

• 리팩토링
  • 이를 통해 구현이 완료된 후 또는 완료된 후에 만 ​​잘못 배치 된 것으로 인식 된 비트를 가져 와서 올바른 위치에 배치 할 수 있습니다 .
• 고쳐 쓰기
  • 이것은 파산과 같습니다. 슬레이트를 깨끗하게 닦지 만 아무것도 시작하지 않고 같은 실수 나 더 큰 실수를 할 기회가 있습니다. 기술 부채에 대한 고위험 고 보상 접근 방식이지만 때로는 유일한 선택입니다. 그것은 많은 사람들이 당신에게 말할 것보다 더 드문 경우이지만.
• 아키텍처 개요
  • 이것은 활발한 기술 부채 상환 방식입니다. 이는 기술적 세부 사항에 대한 권한을 가진 사람 이 프로젝트 계획 및 일정에 관계없이 기술적 부채가 덜 발생하도록 구현을 중단하도록함으로써 수행 됩니다.
• 코드 동결
  • 변경 규정을 동결하면 부채가 증가하거나 감소하지 않는 공간을 호흡 할 수 있습니다. 이를 통해 접근 방식에 가장 높은 ROI를 기대하면서 기술 부채를 줄이는 방법을 계획 할 수 있습니다.
• 모듈화
  • 당신도 건축 개요에 고용 할 때 계층-2 방식처럼 만 사용할 수 있습니다 이미 모듈 식 시스템을, 또는 리팩토링 한 방향으로 이동합니다. 모듈 식 시스템을 사용하면 시스템 전체에 대한 부채를 격리 된 방식으로 갚을 수 있습니다. 이를 통해 부분적으로 다시 쓰기, 부분 리팩토링 및 기술적 부채 발생률을 최소화 할 수 있습니다. 이는 격리가 시스템 주변으로 확산되는 것이 아니라 기능이 들어간 영역에서만 부채를 유지하기 때문입니다.
• 자동화 된 테스트
  • 자동화 된 테스트는 기술 부채 관리에 도움이 될 수 있습니다. 기술 부채는 해당 영역의 부채가 매우 커지기 전에 시스템의 문제 지점을 식별하는 데 도움이 될 수 있기를 바랍니다. 아직 깨달았을 수도 있습니다. 또한 자동화 된 테스트를받은 후에는 너무 많은 문제를 염려하지 않고도 더 자유롭게 리팩토링 할 수 있습니다. 개발자 가 문제를 해결하지는 않지만 문제를 해결할 시기를 알기 때문에 고도로 빚이 많은 시스템에서 수동 테스터를 사용하면 문제를 찾는 데있어 실적이 좋지 않은 경향이 있습니다.

설명은 Foote와 Yoder의 Big Ball of Mud에 적합합니다 .

지난 몇 년 동안, 많은 저자들이 ... 고급 소프트웨어 아키텍처를 특징 짓는 패턴을 제시했습니다 ... 이상적인 세계에서 모든 시스템은 하나 이상의 이러한 고급 패턴의 예가 될 것입니다. 그러나 이것은 그렇지 않습니다. 실제로 실제로 우세한 아키텍처는 아직 논의되지 않았습니다 : BIG BALL OF MUD .

MUD의 BALL BALL은 우연히 구조화되고, 펼치고, 조잡하고, 덕트 테이프 및 bailing 와이어, 스파게티 코드 정글입니다. 우리는 모두 그들을 보았다. 이러한 시스템은 규제되지 않은 성장과 반복적이고 편리한 수리의 명백한 징후를 보여줍니다. 정보는 시스템의 먼 요소들 사이에서 무차별 적으로 공유되며, 거의 모든 중요한 정보가 전체적으로 복제되거나 복제되는 시점까지 공유됩니다. 시스템의 전체 구조는 잘 정의되지 않았을 수 있습니다. 그랬다면 인식을 넘어서 침식되었을 수 있습니다. 건축적인 감성의 조각을 가진 프로그래머는 이러한 혼란을 피했습니다. 건축에 대해 걱정하지 않고 아마도 실패한 제방에 구멍을 뚫는 일상적인 일의 관성에 익숙한 사람들 만 그러한 시스템에서 일하기에 만족합니다 ...

시스템이 왜 MUD BALL OF MUD가됩니까? 때때로, 추악한 시스템이 THROWAWAY CODE 에서 나옵니다 . THROWAWAY CODE는 한 번만 사용한 다음 폐기하기위한 빠르고 더러운 코드입니다. 그러나 이러한 코드는 일반적인 구조와 문서가 없거나 존재하지 않더라도 종종 자체의 수명을 갖습니다. 작동하지만 왜 고쳐야합니까? 관련 문제가 발생하면이를 해결하는 가장 빠른 방법은 처음부터 적절한 일반 프로그램을 설계하는 대신이 작업 코드를 신속하게 수정하는 것입니다. 시간이 지남에 따라 간단한 프로그램은 BUD BALL OF MUD를 낳습니다.

잘 정의 된 아키텍처를 가진 시스템조차도 구조적 침식이 발생하기 쉽습니다. 성공적인 시스템이 요구하는 변화하는 요구 사항에 대한 끊임없는 공격은 점차 그 구조를 약화시킬 수 있습니다. PIECEMEAL GROWTH 는 시스템 요소가 제어 할 수없는 방식으로 점차적 으로 퍼지면서 한때 깔끔한 시스템이 자라게되었습니다 .

그러한 찌그러짐이 계속 줄어든다면, 시스템의 구조는 심하게 손상되어 버려 져야합니다. 부패하는 이웃과 마찬가지로 하향 나선이 발생합니다. 시스템이 이해하기가 점점 어려워 지므로 유지 관리 비용이 많이 들고 더 어려워집니다. 훌륭한 프로그래머는 거기서 일하기를 거부합니다. 투자자는 자본을 인출합니다. 그러나 이웃과 마찬가지로 이러한 종류의 쇠퇴를 피하고 심지어 뒤집을 수있는 방법이 있습니다. 우주의 다른 어떤 것들과 마찬가지로, 엔트로피 힘을 대항하려면 에너지 투자가 필요합니다. 소프트웨어 gentrification 도 예외는 아닙니다. 소프트웨어에서 엔트로피를 정지시키는 방법은 소프트웨어를 리팩토링하는 것입니다. 리팩토링에 대한 지속적인 노력은 시스템이 MUD BALL OF MUD에 포함되지 못하게 할 수 있습니다.

• ... 진흙의 가장 효과적인 적 중 하나는 햇빛입니다. 복잡한 코드를 정밀 조사 화살표에 적용하면 리팩토링, 복구 및 재활을위한 단계를 설정할 수 있습니다. 코드 검토 는 코드를 일광에 노출시키는 데 사용할 수있는 메커니즘 중 하나입니다.