Topics covered

• Evolution processes
• Legacy systems
• Software maintenance

Software change

• Software change is inevitable.
  • New requirements emerge when the software is used;
  • The business environment changes;
  • Errors must be repaired;
  • New computers and equipment is added to the system;
  • The performance or reliability of the system may have to be improved.
• A key problem for all organizations is implementing and managing change to their existing software systems.

소프트웨어 변화

소프트웨어의 변화는 불가피합니다. 소프트웨어가 사용되면서 새로운 요구사항이 등장하고, 비즈니스 환경이 변하며, 오류를 수정해야 하고, 시스템에 새로운 컴퓨터와 장비가 추가되며, 시스템의 성능이나 신뢰성을 개선해야 할 수도 있습니다. 모든 조직에게 핵심적인 문제는 기존 소프트웨어 시스템에 대한 변화를 구현하고 관리하는 것입니다.

Importance of evolution

• Organisations have huge investments in their software systems - they are critical business assets.
• To maintain the value of these assets to the business, they must be changed and updated.
• The majority of the software budget is devoted to changing and evolving existing software rather than developing new software.
  • Software debugging alone takes significant portion of developers' time.
  • US developers spent 35% of their time on software debugging.
  • Another study shows that debugging takes about 50% of the time, and software bugs cost $312 billion per year.

진화의 중요성

조직들은 소프트웨어 시스템에 거대한 투자를 하고 있으며, 이들은 중요한 비즈니스 자산입니다. 이러한 자산의 비즈니스 가치를 유지하기 위해서는 이들을 변경하고 업데이트해야 합니다. 소프트웨어 예산의 대부분은 새로운 소프트웨어 개발보다 기존 소프트웨어의 변경과 진화에 투자되고 있습니다. 소프트웨어 디버깅만으로도 개발자들의 시간의 상당 부분이 소요됩니다. 미국 개발자들은 그들의 시간의 35%를 소프트웨어 디버깅에 사용했으며, 다른 연구에서는 디버깅이 시간의 약 50%를 차지하며 소프트웨어 버그가 연간 3120억 달러의 비용을 발생시킨다고 보고하고 있습니다.

Evolution and servicing

진화와 서비스

첨부된 첫 번째 이미지는 소프트웨어 제품이 초기 개발 단계에서 사용 및 진화 단계로 넘어가는 과정을 보여줍니다. 제품이 서비스되고 사용되는 동안, 소프트웨어는 지속적으로 진화하며 변경되어야 합니다. 이 변경은 새로운 기능이나 요구 사항이 추가됨에 따라 발생하거나, 발견된 오류를 수정하기 위해 발생하거나, 시스템의 성능을 향상시키기 위해 발생합니다.

A spiral model of development and evolution

개발과 진화의 나선형 모델

두 번째 이미지는 소프트웨어의 개발과 진화를 설명하는 나선형 모델을 보여줍니다. 이 모델에서는 소프트웨어가 초기 개발 단계에서 진화 단계로 이동하면서 반복적인 사이클을 거치는 것을 볼 수 있습니다. 각 사이클은 개발 단계(요구사항 분석, 설계, 구현, 테스트)를 포함하며, 이는 이전 사이클에서 학습된 내용에 따라 수정되고 확장됩니다. 이런 방식으로, 소프트웨어는 점진적으로 개발되고, 요구사항의 변경이나 시스템의 성능 향상과 같은 새로운 요구사항에 맞게 진화합니다.

Evolution processes

The software evolution process

소프트웨어 진화 과정

첫 번째 이미지는 소프트웨어 진화 과정을 보여줍니다. 이는 소프트웨어 변경 요청이 제출되면 변경이 필요한 이유를 이해하기 위해 초기 평가 단계로 들어가게 됩니다. 이를 기반으로 변경이 승인되면, 그 변경을 구현하고 테스트하는 단계가 이어집니다. 그 후에는 변경이 사용자에게 배포되며, 이후에는 추가 변경 요청이나 이슈가 생길 때까지 이 과정이 반복됩니다.

Change implementation

• Iteration of the development process where the revisions to the system are designed, implemented and tested.
• A critical difference is that the first stage of change implementation may involve program understanding,
  • especially if the original system developers are not responsible for the change implementation.
• During the program understanding phase,
  • you have to understand how the program is structured,
  • how it delivers functionality, and
  • how the proposed change might affect the program.

변경 구현

두 번째 이미지는 변경 구현 과정을 보여줍니다. 여기서 핵심적인 차이점은 변경 구현의 첫 단계가 프로그램 이해를 포함할 수 있다는 것입니다. 이는 특히 원래의 시스템 개발자가 변경 구현을 담당하지 않는 경우에 매우 중요합니다. 프로그램 이해 단계에서는 프로그램이 어떻게 구조화되어 있는지, 어떻게 기능을 제공하는지, 제안된 변경이 프로그램에 어떤 영향을 미칠 수 있는지를 이해해야 합니다.

이렇게 변경 구현은 원래의 개발 과정을 반복하는 것처럼 보일 수 있지만, 여기서는 시스템을 이해하고 변경을 설계하고 구현하며 테스트하는 단계를 포함합니다. 이 과정은 시스템이 변화하는 요구사항에 맞게 적응하고 진화할 수 있게 해줍니다.

Agile methods and evolution

• Agile methods are based on incremental development so the transition from development to evolution is a seamless one.
  • Evolution is simply a continuation of the development process based on frequent system releases.
• Automated regression testing during continuous integration is particularly valuable when changes are made to a system.
• Changes may be expressed as additional user stories.

애자일 방법론과 진화

애자일 방법론은 증분 개발에 기반을 두고 있어, 개발에서 진화로의 전환은 매우 자연스러운 과정입니다. 진화는 시스템이 빈번하게 릴리즈되는 것을 바탕으로 한 개발 과정의 연속적인 진행입니다. 지속적인 통합 중 자동 회귀 테스트는 시스템에 변경이 발생할 때 특히 유용합니다. 이러한 변경 사항은 추가적인 사용자 스토리로 표현될 수 있습니다.

Handover problems

• Where the development team have used an agile approach but the evolution team is unfamiliar with agile methods and prefer a plan-based approach.
  • The evolution team may expect detailed documentation to support evolution and this is not produced in agile processes.
• Where a plan-based approach has been used for development but the evolution team prefer to use agile methods.
  • The evolution team may have to start from scratch developing automated tests and the code in the system may not have been refactored and simplified as is expected in agile development.

인수 문제

개발 팀이 애자일 방법론을 사용했지만, 진화 팀이 애자일 방법론에 익숙하지 않고 계획 기반 접근법을 선호하는 경우 문제가 발생할 수 있습니다. 이 경우, 진화 팀은 진화를 지원하기 위한 상세한 문서화를 기대할 수 있는데, 이는 애자일 프로세스에서 생성되지 않는다는 문제가 있습니다.

개발에 계획 기반 접근법이 사용되었지만 진화 팀이 애자일 방법론을 선호하는 경우에도 문제가 생깁니다. 진화 팀은 자동 테스트를 처음부터 개발해야 하며, 시스템의 코드가 애자일 개발에서 기대하는 것처럼 리팩터링되고 간소화되지 않았을 수 있습니다. 이런 상황에서는 진화 팀이 더 많은 노력을 기울여야 할 수 있습니다.

Legacy systems

Legacy systems

• Legacy systems are older systems that rely on languages and technology that are no longer used for new systems development.
  • e.g.) Y2K issues and COBOL, Dismissal of ActiveX, Flash.
• Legacy software may be dependent on older hardware, such as mainframe computers and may have associated legacy processes and procedures.
• Legacy systems are not just software systems but are broader socio-technical systems that include hardware, software, libraries and other supporting software and business processes.

레거시 시스템

레거시 시스템은 이전의 시스템을 의미하며, 이들 시스템은 새로운 시스템 개발에 더 이상 사용되지 않는 언어와 기술에 의존합니다. 예를 들면, Y2K 문제와 COBOL, ActiveX의 폐기, 플래시 등이 있습니다. 레거시 소프트웨어는 메인프레임과 같은 이전의 하드웨어에 의존할 수 있으며, 연관된 레거시 프로세스 및 절차를 가질 수 있습니다. 레거시 시스템은 단순히 소프트웨어 시스템만이 아니라 하드웨어, 소프트웨어, 라이브러리 및 기타 지원 소프트웨어, 비즈니스 프로세스를 포함하는 보다 광범위한 사회기술적 시스템입니다.

Legacy system components

• System hardware: Legacy systems may have been written for hardware that is no longer available.
• Support software: The legacy system may rely on a range of support software, which may be obsolete or unsupported.
• Application software: The application system that provides the business services is usually made up of a number of application programs.
• Application data: These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases.
• Business processes: These are processes that are used in the business to achieve some business objective.
  • Business processes may be designed around a legacy system and constrained by the functionality that it provides.
• Business policies and rules: These are definitions of how the business should be carried out and constraints on the business.
  • Use of the legacy application system may be embedded in these policies and rules.

레거시 시스템 컴포넌트

• 시스템 하드웨어: 레거시 시스템은 더 이상 사용되지 않는 하드웨어를 위해 작성되었을 수 있습니다.
• 지원 소프트웨어: 레거시 시스템은 구식이거나 지원되지 않는 다양한 지원 소프트웨어에 의존할 수 있습니다.
• 응용 소프트웨어: 비즈니스 서비스를 제공하는 응용 시스템은 일반적으로 여러 응용 프로그램으로 구성됩니다.
• 응용 데이터: 이는 응용 시스템에 의해 처리되는 데이터입니다. 이들은 일관성이 없거나 중복되거나 다른 데이터베이스에 저장될 수 있습니다.
• 비즈니스 프로세스: 이는 어떤 비즈니스 목표를 달성하기 위해 사용되는 비즈니스의 프로세스입니다. 비즈니스 프로세스는 레거시 시스템을 중심으로 설계되고 그 기능에 의해 제약될 수 있습니다.
• 비즈니스 정책 및 규칙: 이는 비즈니스가 어떻게 수행되어야 하는지, 비즈니스에 대한 제약 사항에 대한 정의입니다. 레거시 응용 시스템의 사용이 이러한 정책과 규칙에 내재되어 있을 수 있습니다.

Legacy system replacement

• Legacy system replacement is risky and expensive so businesses continue to use these systems.
• System replacement is risky for a number of reasons.
  • Lack of complete system specification
  • Tight integration of system and business processes
  • Undocumented business rules embedded in the legacy system
  • New software development may be late and/or over budget

레거시 시스템 교체

레거시 시스템 교체는 위험하고 비용이 많이 들기 때문에 기업들은 계속해서 이런 시스템을 사용합니다. 시스템 교체는 여러 가지 이유로 위험합니다.

• 완전한 시스템 명세가 부족하다
• 시스템과 비즈니스 프로세스의 긴밀한 통합
• 레거시 시스템에 내장된 문서화되지 않은 비즈니스 규칙
• 새로운 소프트웨어 개발이 예산 초과 또는 지연될 수 있다.

Legacy system change

• Legacy systems are expensive to change for a number of reasons:
  • Inconsistent programming style.
  • Use of obsolete programming languages with few people available with these language skills.
  • Inadequate system documentation.
  • System structure degradation.
  • Program optimizations may make them hard to understand.
  • Data errors, duplication and inconsistency.

레거시 시스템 변경

레거시 시스템 변경은 여러 가지 이유로 비용이 많이 듭니다:

• 일관성 없는 프로그래밍 스타일
• 사용할 수 있는 사람들이 적은 노후 프로그래밍 언어의 사용
• 시스템 문서화 부족
• 시스템 구조의 퇴화
• 프로그램 최적화가 이해하기 어렵게 만들 수 있다.
• 데이터 오류, 중복, 일관성 없음.

Legacy system management

• Organisations that rely on legacy systems must choose a strategy for evolving these systems.
  • Scrap the system completely and modify business processes so that it is no longer required;
  • Continue maintaining the system;
  • Transform the system by re-engineering to improve its maintainability;
  • Replace the system with a new system.

레거시 시스템 관리

레거시 시스템에 의존하는 조직은 이러한 시스템을 진화시키기 위한 전략을 선택해야 합니다.

• 시스템을 완전히 폐기하고 비즈니스 프로세스를 수정하여 더 이상 필요하지 않게 만든다.
• 시스템을 계속 유지보수한다.
• 유지보수성을 향상시키기 위해 재공학을 통해 시스템을 변형한다.
• 새로운 시스템으로 시스템을 대체한다.

Figure 9.13 An example of a legacy system assessment

• The strategy chosen should depend on the system quality and its business value.
  

Legacy system categories

• Low quality, Low business value
  • These systems should be scrapped.
• Low-quality, High-business value
  • These make an important business contribution but are expensive to maintain.
  • Should be re-engineered or replaced if a suitable system is available.
• High-quality, Low-business value
  • Replace with COTS, scrap completely or maintain.
• High-quality, High business value
  • Continue in operation using normal system maintenance.

레거시 시스템 카테고리

• 품질이 낮고, 비즈니스 가치가 낮은 시스템
  • 이런 시스템은 폐기되어야 합니다.
• 품질이 낮고, 비즈니스 가치가 높은 시스템
  • 이 시스템은 중요한 비즈니스 기여를 하지만 유지보수에 비용이 많이 듭니다.
  • 적절한 시스템이 사용 가능한 경우 재공학을 통해 변형하거나 대체해야 합니다.
• 품질이 높고, 비즈니스 가치가 낮은 시스템
  • 상용 소프트웨어로 대체하거나, 완전히 폐기하거나, 유지보수를 계속합니다.
• 품질이 높고, 비즈니스 가치가 높은 시스템
  • 일반 시스템 유지보수를 사용하여 운영을 계속합니다.

Business value assessment

• The use of the system
  • If systems are only used occasionally or by a small number of people, they may have a low business value.
• The business processes that are supported
  • A system may have a low business value if it forces the use of inefficient business processes.
• System dependability
  • If a system is not dependable and the problems directly affect business customers, the system has a low business value.
• The system outputs
  • If the business depends on system outputs, then the system has a high business value.

비즈니스 가치 평가

• 시스템의 사용
  • 시스템이 가끔씩 또는 소수의 사람들에 의해서만 사용된다면, 그 시스템의 비즈니스 가치는 낮을 수 있습니다.
• 지원되는 비즈니스 프로세스
  • 만약 시스템이 비효율적인 비즈니스 프로세스의 사용을 강요한다면, 그 시스템의 비즈니스 가치는 낮을 수 있습니다.
• 시스템의 신뢰성
  • 만약 시스템이 신뢰성이 없고 문제가 직접 비즈니스 고객에게 영향을 미친다면, 그 시스템의 비즈니스 가치는 낮습니다.
• 시스템 출력
  • 비즈니스가 시스템 출력에 의존한다면, 그 시스템은 높은 비즈니스 가치를 가집니다.

System quality assessment

• Business process assessment
  • How well does the business process support the current goals of the business?
• Environment assessment
  • How effective is the system’s environment and how expensive is it to maintain?
• Application assessment
  • What is the quality of the application software system?

시스템 품질 평가

• 비즈니스 프로세스 평가
  • 비즈니스 프로세스가 현재의 비즈니스 목표를 얼마나 잘 지원하는가?
• 환경 평가
  • 시스템의 환경이 얼마나 효과적이고 유지보수하는 데 얼마나 비용이 드는가?
• 응용 프로그램 평가
  • 응용 소프트웨어 시스템의 품질은 어떠한가?

Software maintenance

Software maintenance

• Modifying a program after it has been put into use.
• The term is mostly used for changing custom software.
  • Generic software products are said to evolve to create new versions.
• Maintenance does not normally involve major changes to the system’s architecture.
• Changes are implemented by modifying existing components and adding new components to the system.

소프트웨어 유지보수

• 프로그램이 사용된 후에 수정하는 작업을 말합니다.
• 이 용어는 대체로 사용자 정의 소프트웨어 변경에 대해 사용됩니다.
  • 일반적인 소프트웨어 제품은 새로운 버전을 만들기 위해 진화한다고 말합니다.
• 유지보수는 일반적으로 시스템의 주요 아키텍처를 변경하는 데는 포함되지 않습니다.
• 변경 사항은 기존 컴포넌트를 수정하고 시스템에 새 컴포넌트를 추가함으로써 구현됩니다.

Types of maintenance

• Fault repairs
  • Changing a system to fix bugs/vulnerabilities and correct deficiencies in the way meets its requirements.
• Environmental adaptation
  • Maintenance to adapt software to a different operating environment
  • Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation.
• Functionality addition and modification
  • Modifying the system to satisfy new requirements.

유지보수의 종류

• 결함 수리
  • 시스템을 변경하여 버그/취약점을 수정하고 요구 사항을 충족하는 방식에 대한 미비점을 바로잡습니다.
• 환경 적응
  • 소프트웨어를 다른 운영 환경에 적응시키기 위한 유지보수
  • 시스템을 변경하여 초기 구현에서 다른 환경(컴퓨터, 운영 체제 등)에서 작동하도록 합니다.
• 기능 추가 및 수정
  • 새로운 요구 사항을 만족시키기 위해 시스템을 수정합니다.

Maintenance effort distribution

유지보수 노력 분포

• 이미지에서 보여주는 바와 같이, 다양한 유지보수 작업이 요구되는 노력은 그 종류에 따라 다르게 분포됩니다.
  • '완전히 새로운 기능 추가'이 가장 많은 비율을 차지하고, 그 다음으로는 '결함 수정'와 '적응 유지보수'가 이어집니다.

Maintenance costs

• Usually greater than development costs (2x to 100x depending on the application).
• Affected by both technical and non-technical factors.
• Increases as software is maintained.
  • Maintenance corrupts the software structure so makes further maintenance more difficult.
• Aging software can have high support costs (e.g. old languages, compilers etc.).

유지보수 비용

• 보통 개발 비용보다 더 많습니다(응용 프로그램에 따라 2배에서 100배까지 다릅니다).
• 기술적 요인뿐만 아니라 비기술적 요인에도 영향을 받습니다.
• 소프트웨어가 유지보수되면서 비용이 증가합니다.
  • 유지보수는 소프트웨어 구조를 손상시켜 추가 유지보수를 더 어렵게 만듭니다.
• 오래된 소프트웨어는 높은 지원 비용을 가질 수 있습니다(예: 오래된 언어, 컴파일러 등).

Software reengineering

• Restructuring or rewriting part or all of a legacy system without changing its functionality.
• Applicable where some but not all sub-systems of a larger system require frequent maintenance.
• Reengineering involves adding effort to make them easier to maintain.
  • The system may be re-structured and re-documented.

소프트웨어 재공학

• 기능은 그대로 유지하면서 레거시 시스템의 일부 또는 전체를 재구조화하거나 다시 작성하는 것입니다.
• 대형 시스템의 일부 하위 시스템만 자주 유지보수가 필요한 경우에 적용할 수 있습니다.
• 재공학은 유지보수를 더 쉽게 하기 위해 노력을 추가하는 것을 포함합니다.
  • 시스템을 재구조화하고 재문서화할 수 있습니다.

Advantages of reengineering

• Reduced risk
  • There is a high risk in new software development.
  • There may be development problems, staffing problems and specification problems.
• Reduced cost
  • The cost of re-engineering is often significantly less than the costs of developing new software.

재공학의 장점

• 위험 감소
  • 새로운 소프트웨어 개발에는 높은 위험이 있습니다.
  • 개발 문제, 인력 문제, 사양 문제가 있을 수 있습니다.
• 비용 감소
  • 재공학 비용은 일반적으로 새로운 소프트웨어 개발 비용보다 훨씬 적습니다.

Reengineering process activities

• Source code translation
  • Convert code to a new language.
• Reverse engineering
  • Analyse the program to understand it;
• Program structure improvement
  • Restructure automatically for understandability;
• Program modularisation
  • Reorganise the program structure;
• Data reengineering
  • Clean-up and restructure system data.

재공학 프로세스 활동

• 소스 코드 번역
  • 코드를 새로운 언어로 변환합니다.
• 리버스 엔지니어링
  • 프로그램을 분석하여 이해합니다.
• 프로그램 구조 개선
  • 이해하기 쉽도록 자동으로 재구조화합니다.
• 프로그램 모듈화
  • 프로그램 구조를 재조직합니다.
• 데이터 재공학
  • 시스템 데이터를 정리하고 재구조화합니다.

Refactoring

• Refactoring is the process of making improvements to a program to slow down degradation through change.
• You can think of refactoring as ‘preventative maintenance’ that reduces the problems of future change.
• Refactoring involves modifying a program to improve its structure, reduce its complexity or make it easier to understand.
• When you refactor a program, you should not add functionality but rather concentrate on program improvement.
  • Root Canal vs Floss Refactoring.

리팩토링

• 리팩토링은 변화를 통한 퇴화를 늦추기 위해 프로그램에 개선을 가하는 과정입니다.
• 리팩토링을 미래의 변화 문제를 줄이는 '예방 유지보수'로 생각할 수 있습니다.
• 리팩토링은 프로그램의 구조를 개선하고, 복잡성을 줄이고, 이해하기 쉽게 만들기 위해 프로그램을 수정하는 것을 포함합니다.
• 프로그램을 리팩토링할 때 기능을 추가하지 말고 프로그램 개선에 집중해야 합니다.
  • 뿌리 치료와 치실 리팩토링 비교.

Refactoring and reengineering

• Re-engineering takes place after a system has been maintained for some time and maintenance costs are increasing.
  • You use automated tools to process and re-engineer a legacy system to create a new system that is more maintainable.
• Refactoring is a continuous process of improvement throughout the development and evolution process.
  • It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system.

리팩토링과 리엔지니어링

• 리엔지니어링은 시스템이 일정 시간 동안 유지되고 유지 비용이 증가한 후에 이루어집니다.
  • 이때는 자동화된 도구를 사용하여 레거시 시스템을 처리하고 재구성하여 보다 유지 보수가 쉬운 새로운 시스템을 생성합니다.
• 리팩토링은 개발 및 진화 과정을 통한 지속적인 개선 과정입니다.
  • 이는 시스템을 유지 보수하는 데 드는 비용과 어려움을 증가시키는 구조 및 코드의 저하를 피하려는 것이 목적입니다.
    리엔지니어링은 크게 문제가 된 상황에서 대응하는 전략으로, 보통의 경우 전체 시스템이나 큰 부분의 코드를 재작성하게 됩니다. 이는 매우 큰 비용과 시간을 필요로 합니다.

반면에 리팩토링은 지속적인 개선과정으로서, 코드가 복잡해지거나 구조가 무너지기 전에 미리 미리 조치를 취하는 방법입니다. 이는 일반적으로 작은 단위로 수행되며, 개발 과정에서 계속 이루어질 수 있습니다. 따라서 리팩토링은 더욱 저렴하고 더 적은 리스크를 수반합니다.

Refactoring

• Martin Fowler is one of the most famous figure in this matter.
• You can also check
• https://martinfowler.com/
• He and Kent Beck are famous figures in Agile development, who signed the Agile Manifesto.

리팩토링

• 마틴 파울러는 이 분야에서 가장 유명한 인물 중 하나입니다.
• 자세한 내용은 https://martinfowler.com/ 를 참고하시면 됩니다.
• 그와 켄트 벡은 Agile 개발의 유명한 인물들로, Agile 매니페스토에 서명한 사람들입니다.

‘Bad smells’ in program code

• Duplicate code (a.k.a Code Clones)
  • The same or very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required.
• Long methods
  • If a method is too long, it should be redesigned as a number of shorter methods.
• Switch (case) statements
  • These often involve duplication, where the switch depends on the type of a value.
  • The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing.
• Data clumping
  • Data clumps occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program.
  • These can often be replaced with an object that encapsulates all of the data.
• Speculative generality
  • This occurs when developers include generality in a program in case it is required in the future.
  • This can often simply be removed.

프로그램 코드에서의 ‘나쁜 냄새’

• 중복 코드 (a.k.a 코드 클론)
  • 같거나 매우 비슷한 코드가 프로그램의 다른 부분에 포함될 수 있습니다. 이는 필요에 따라 호출되는 단일 메소드나 함수로 구현하여 제거할 수 있습니다.
• 긴 메소드
  • 메소드가 너무 길면, 이를 몇 개의 더 짧은 메소드로 재설계해야 합니다.
• Switch (case) 문
  • 이들은 종종 중복을 포함하며, switch가 값의 유형에 따라 달라집니다.
  • switch 문은 프로그램 전체에 흩어져 있을 수 있습니다. 객체 지향 언어에서는 대체로 다형성을 이용하여 같은 기능을 수행할 수 있습니다.
• 데이터 덩어리
  • 데이터 덩어리는 같은 데이터 항목 그룹 (클래스의 필드, 메소드의 매개변수)이 프로그램의 여러 곳에서 반복적으로 나타날 때 발생합니다.
  • 이들은 종종 모든 데이터를 캡슐화하는 객체로 대체할 수 있습니다.
• 추측적 일반성
  • 개발자들이 미래에 필요할 경우를 대비해 프로그램에 일반성을 포함시키는 경우입니다.
  • 이는 대체로 간단하게 제거할 수 있습니다.