Software Evolution

Software Change

• 소프트웨어가 변경되는 것은 불가피하다. 개발 중에도 바뀌지만, 개발 후에도 바뀐다.
  • 새로운 기능이 필요하다.
  • 버그를 고쳐야 한다.
  • 바뀐 주변 환경에 맞추어야 한다.
  • 성능을 올려야 한다.
• 대부분의 소프트웨어는 만드는 것 보다 유지보수하는 것에 자원들이 더 많이 소모된다.
  
• Spiral Model의 모습이다. 4가지 과정을 한번만 하는 게 아니라, 계속해서 진행하며 코드를 고친다.

Evolution and Servicing

• 소프트웨어를 개발하고 출시하고 난 후 소프트웨어의 기능이 바뀔 수 있다. 이것이 Evolution이다.
• 계속 Evolution을 하다보면 더 이상 추가적인 기능이 필요하지 않을 때가 있다. 이때부터는 간단한 버그 수정이나 기존 기능을 제공하면서 버티는 과정에 들어간다. 이것이 Servicing이다.
• Servicing이 끝나면 Retirement에 들어간다.
  
• 게임의 경우를 예로 들어보자.
  정식 출시 되었다!
  → 버그도 수정하고 DLC도 내면서 기능을 추가한다.
  → 점점 추가되는 콘텐츠가 줄어든다.
  → 이제 자잘한 버그 수정이나 편의성 패치만 진행하고 콘텐츠는 추가되지 않는다.
  → 오랜 시간이 지나 유지하기 힘들어져 서비스 종료한다.

Evolution Process

• Evolution은 특정한 기능을 추가하고 성능을 향상시키는 과정이다. 주로 시스템이 배포된 초기에 이뤄진다.
• 통상적인 과정은 아래와 같다.
  
  → DLC를 추가할 것이다. (Change Requests)
  → DLC가 추가되면 게임에 미치는 영향을 파악한다. (Impact analysis)
  → DLC를 배포할 방법이나 계획을 세운다. (Release planning)
  → 실제로 DLC를 만들고 적용해본다. (Change implementation)
  → 마지막으로 게임을 다시 배포(업데이트)한다. (System release)
• 많은 경우에 빠르게 바꿔야 하는 문제들이 있다. 이런 문제를 여러 과정을 거치지 않고 빠르게 고치는 것이 Urgent Change이다.
  
  → 심각한 진행 불가 버그를 고쳐야 한다! (Change Requests)
  → 버그가 어디서 발생했는지 코드를 확인한다. (Analyze source code)
  → 버그가 발생한 코드를 고친다. (Modify source code)
  → 고친 코드가 들어간 시스템을 배포한다. (Deliver modified system)

Agile Methods and Evolution

• Agile은 한번의 진행 주기가 굉장히 빠르다.
• 그렇기 때문에 development와 evolution이 구분되지 않는 경우가 많다.
• 이는 개발과 유지 보수가 같이 된다는 이점이 있지만, 개발과 유지 보수하는 사람이 다를 경우 문제가 생길 수 있다는 위험성이 존재한다. 이를 handover problems 라고 한다.
• handover problems는 유지 보수를 거의 불가능케 하므로 피해야 한다.
• 개발과 유지 보수를 같은 사람이 하거나, 유지 보수가 필요 없는 프로그램을 만들면 피할 수 있다.

Legacy System

• Legacy System은 오래 된 시스템을 의미한다.
• 근데 단순히 오래되었다고 Legacy System이 아니다. 유지보수가 끝나고 만든 사람들이 다 없어져서 어떤일을 하는지 모르는 오래된 시스템을 말한다.
• Legacy System은 중요할 수도 있고 아닐수도 있다. 문제는 그걸 모른다! 그렇기 때문에 문제가 발생해도 해결할 수 없고, 성능을 올리고 싶어도 고칠 수 없다.
• 그렇다고 새로 만들기도 힘들다. 무슨일을 하는지 모르기 때문에 뭘 개발해야 하는지도 잘 모르며, 새롭게 적용하는 기술이나 언어가 호환이 되지 않아 오류가 발생할 수 있다.
• 그렇다고~~ 새로 바꾸기도 힘들다. 어떤 데이터 / 시스템과 연관되어 있는지 모른다. 또한 옛날 프로그래밍 스타일이고 옛날 기술이기 때문에 파악하기 힘들다.
• 그렇기 때문에 Legacy System은 1) 그냥 안 쓰거나(discard) 2) 계속 쓰거나(maintain) 3) 중요한 부분만 다시 만들거나(re-engineering) 4) 다른 시스템으로 바꾼다(replace).
  → 내가 예전에 만들어놓은 캐릭터의 스텟이 있다. 예를 들면 정신력...
  → 문제는 이 스텟이 무슨 일을 하는지 모른다! 캐릭터는 체력과 경험치로만 작동하는 것처럼 보인다.
  → 4가지 중에 하나 선택한다.
  → 1) 그냥 정신력을 없앤다. 만약 정신력이 사용자에게는 보이지 않지만, 시스템적으로 영향을 미친다면?
  → 2) 계속 쓴다. 문제는 없지만 쓸데 없는 것에 자원을 써야하는가>
  → 3) 고친다. 기능하는 곳을 다 찾아서(찾을 수 있다면) 조금만 고친다.
  → 4) 다른 거로 대체한다. 처음부터 새로 만들어보자.

Software Maintenance

• 프로그램을 더 나은 방향으로 고치고 발견된 오류를 수정하는 과정이다.
• Generic software는 다음 버전으로 evolve 하는 과정을 거치기 때문에, maintenance는 Custom software에서 많이 쓰인다.
• 요소들을 바꾸거나 추가해서 시스템을 더 나은 방향으로 만든다.

Type of Maintenance

• Fault repairs : 오류나 취약점을 찾고 고친다.
• Environment adaptation : 주변 환경이 바뀌는 것에 따라서 소프트웨어를 업데이트하거나 리펙토링한다.
• Functionality addition and modification : 여러가지 기능을 추가한다.
  

Maintenance Costs

• 프로그램을 유지하는 것은 대부분 개발하는 것보다 비용이 많이 들어간다.
• 대부분 2배에서, 심하면 100배 이상 들어가는 경우도 있다.
• 그러므로, 유지보수에서 들어가는 비용을 잘 파악해야 한다.
• 대부분의 시스템은 오래 될 수록 들어가는 비용이 많아진다.

Maintenance Prediction

• 유지보수는 많은 돈이 들기 때문에, 비용 예상을 하지 않으면 더 많은 돈이 나갈 수 있다.
• 또한, 내년 상황이나 추가되는 기능 등에 따라서 비용은 계속 올라갈 수 있다.
• 이러한 비용을 사전에 계산하고, 경제적인 관점에서 분석하는 것이 Prediction이다.
  

Software Reengineering

• Legacy system을 다시 만드는 것을 Reengineering이라고 한다.
• 기능적인 부분은 유지하면서, 알아볼 수 있는 새로운 프로그램으로 바꾸는 과정이다.
  • 유지 비용이 1년에 10억이 들어가는 시스템이 있다. 이 시스템은 앞으로도 계속 사용해야 하는 중요한 시스템이다.
  • 비용이 너무 많이 들어가므로, 새로운 시스템으로 바꾼다. 이 때 모두 바꾸지 않고, 부분을 조금씩 바꿔가면서 만든다.
  • 옛날에 만든 시스템을 성능 / 비용이 적게 들어가는 현대의 기술을 이용해서 바꾼다.
  • 그렇게 해서 유지 비용이 1년에 1억 들어가는 시스템으로 바꾼다. 유지보수 비용이 대폭 감소했다.
    

Refactoring

• 개발 과정 / 개발 후에 프로그램의 기능은 유지하면서 코드를 고치는 것을 Refactoring이라고 한다.
• Refactoring은 다음과 같은 상황에 수행한다.
  • 이미 짜여진 코드의 성능이 낮아서 성능을 높이기 위해 수행한다.
  • 코드의 가독성이 낮아서 Clean code를 만들기 위해 수행한다.
  • 코드의 취약점이나 문제가 발생할 여지를 발견해서 수정하기 위해 수행한다.
• Re-engineering은 시스템이 다 만들어진 후, 개선을 위해서 수행하는 것인 반면에, Refactoring은 개발 과정에서 더 나은 코드와 성능을 위해서 수행한다.

"Bad smells" in Program Code

• 항상 코드는 Clean Code를 완수해야 하며, Bad smell을 제거해야 한다.
• Bad smell은 다음과 같다.
  • Duplicate code : 반복되는 코드는 읽는 사람을 불안하게 한다. 함수를 사용해서 반복되는 부분을 제거해야 한다.
  • Long methods : 함수가 길고, 여러개의 일을 수행하면 오류가 생길 가능성이 크다. 기능에 따라 여러개로 쪼개거나 길이를 최소화해야 한다. 또한 매개변수는 여러개가 있을수록 변경 요인이 많아지므로 최소화해야 한다.
  • Switch (case) statements : Switch문은 값에 따라 다음 수행을 결정하는 것이지만, 문제는 그 값이 무슨 의미인지 파악하기 어려울 때가 많다. 그러므로 값을 제대로 규정하거나, 사용을 줄여야한다.
  • Data clumping : 같은 데이터가 여러 곳에서 불리면, 데이터가 막 바뀌면서 오류가 생길 수 있다. 캡슐화를 통해 이를 막아야 한다.
  • Speculative generality : 미래에 개발된 부분을 어느정도 파악해 놓는 것이다. 좋은 과정이지만, 너무 많이 파악해두면 현재 코드가 읽고 어렵고 영향을 끼칠 수 있다.