[용어] legacy(레거시)

legacy 레거시란?

레거시 프로그램, 레거시 데이터, 레거시 코드와 같이 말하는 이 레거시는 프로그래밍 언어, 플랫폼 그리고 기술 등에 있어서 과거로 부터 내려온 것을 의미한다. 컴퓨터를 사용하는 대부분의 기업들은 중요한 업무를 처리하는 레거시 응용 프로그램드과 데이터베이스를 가지고 있다.

 

*레거시 코드

다른 사람에게 넘겨받은 읽고 수정하기 어려운 오래된 코드

 

 

---

 

 

기술이 계속 변화하고 업데이트 됨에 따라서 레거시 코드가 점점 쌓이게 되는데 이러한 코드가 많아지면 몇가지 문제점이 발생한다.

1. 새로운 기술과 새로운 프로그래머의 보다 효율적이고 새로운 코드로 변환하는 동안 레거시 프로그램을 계속해서 운영시켜야 한다는 것이다. 과거에는 많은 프로그램들이 특정업체의 운영체계에 맞게 작성되었다. 하지만, 요즈음에는 많은 회사들이 자신들의 레거시 프로그램들을 개방형이나 표준 프로그램이 인터페이스를 따르는 새로운 프로그래밍 언어와 운영체계에 맞게 변환하고 있다.

 

2. 변수명, 메소드명이 불명확하거나 설명이 없고 복잡한 경우 이해하기 어려움

 

3. 해당 코드에 대한 완벽한 이해가 어렵기 때문에 적기적시에 수정을 하기 어렵고, 이에 발생하는 버그에 대한 대응이나 예측이 어려움

 

4. 해당 프로젝트의 유지보수하는데 오래 걸리고 어려움

 

 

---

 

 

레거시 코드를 만들지 않기위해서는

1. magic number X

변수 이름에 숫자 1이나 2와 같은 직관적으로 알 수 없는 이름 사용하지 않아야 한다. 의도를 명확하게 알아차릴 수 있는 이름을 줄이지 않고 사용해야 한다.

 

2. 가급적 프로그래밍을 할 때 부부만 옳은 것보다 전체적 대칭을시키자?

     *예를 들어, district.setDong("정자")district.setGu("분당")district.setMetroPolitanOrSi("성남") 와 같이 부분만 옳은 동떨어진 메서드를 사용하기 보다는district.setDong("정자")district.setGu("분당")district.setSi("성남") 와 같이 전체적 대칭을 지키는게 나을 때가 많다. 따라서 기존의 코드와 대칭을 이루는 메서드명을 사용하는게 명칭이 잘못됬다 할지라도 나을 경우가 있다.

 

3. 다중 if문 피하기 (if > if > if ...... > if)

필요할 때는 조건문을 사용해야 하지만, 무분별한 조건문 사용은 피해야 한다. 될 수 있으면 조건문을 사용하는 것보다 메서드를 세분화 시켜 다양한 패턴들을 활용해야 한다.

 

4. 사용하면 안되는 클래스/메서드가 있는 경우

*  deprecated를 해 놓으면 (이클립스 등에서 코딩할때) 취소선이 나온다. 하지만 아무런 설명이 없으면 왜 사용할 수 없는지에 대해서 파악하기 어렵다. 왜 @deprecated가 되었는지 주석을 달아주어야 한다.

@deprecated

@deprecated에 대한 주석 달기

5. 주석은 제대로

쉽게 파악할 수 있는 변수에 대한 추가주석은 달 필요가 없다. 필요한 상황에서만 주석을 달아야 한다. 남발하지도, 필요한 경우에 작성하지 않는것도 안된다! 

 

6. 기능에 해당하는 테스트 코드 작성

요즘에는 테스크 코드에 대한 부정적인 시선도 있는 것같지만, 작성하는 방법에 대해서 한번 공부해봐야겠다.

 

7. 리팩토링 지속적으로

외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법으로, 소프트웨어 시스템을 변경하는 프로세스이다.

 

 

 

---

 

 

*cf

현장 TIP1. Q) 얼마 전 중복이 많고 복잡한 코드를 GOF 디자인 패턴을 적용하여 리팩토링 했다. 그런데 코드리뷰 때 다른 개발자가 더 코드가 더 보기 어려워졌다고 한다.

 

 A) Communicative Code의 요건 중 배려가 있다. 따라서 분명히 구조적으로 좋아졌다고 하더라도 팀 내 다른 개발자가 모두 코드 읽기를 어려워 한다면 한번 더 생각해볼 만한 부분이라고 생각한다. 가치의 상충이 일어나는 것인데 '구조적 개선 vs 읽기 어려움'이다. 각각을 통해 얻게 될 가치를 종합적으로 잘 비교해보고 취사선택하는 것이 좋을 것이라 본다. 또한 GOF 디자인 패턴 적용의 초점이 문제해결이 아닌 적용 그 자체에 있을 때가 종종 있다. 이런 형태의 적용은 득보단 실이 많기 때문에 가급적 피하는 것이 좋다.

 

2. Q) Legacy 코드를 수정 중인데 너무 읽고 이해하기 어려운 클래스 xxx가 있다. 아무래도 안될 것 같아 New XXX를 만들었다. 하지만 예전 클래스를 사용하는 곳 까지 모두 수정하기는 어려워 이번에 작업하는 범위의 클래스에서만 New XXX를 사용하게 바꾸었다. 이렇게 해도 괜찮은 건가?

 

 A) 경험이 비추어 볼 때 절대 하지 말아야 할 형태의 개선이다. 이런 형태의 개선을 할 때 New, New2, New3가 계속 생기며, 기존 클래스는 정리가 안 되어 이후 복잡도가 높아지고 혼란을 가중시키는 사례를 봐왔다. 따라서 가급적 신규 클래스를 도입하는 형태의 개선은 트랜잭션과 마찬가지로 'All or Noting' 원칙이 적용되어야 한다고 본다. 신규 클래스를 도입하려면 반드시 기존 클래스를 제거하고, 그게 힘들다면 신규 클래스를 만들지 말고 예전 클래스 기반에서 수정하는 것이 올바른 방향이락 본다.

 

3. Q) Legacy 코드를 수정하기에 앞서 Cover & Modify를 하려고 하고 있다. 그런데 의존하는 객체가 너무 많았다. 할 수 없이 하나하나 만들어가며 테스트를 만들었다. 그런데 새로운 객체를 생성하는 등의 리팩토링을 하다 보니 기존에 만든 테스트가 다 실패한다. 도움을 주기보다는 거추장스러운 느낌이 나는데 왜 그런가?

 

 A) BO나 Service를 대상으로 단위 테스트를 만들면 대게 객체간의 인터랙션을 테스트하는 코드를 만들게 된다. 하지만 이런 테스트는 객체 간의 인터랙션을 조정하는 등의 리팩토링을 하게 되면 테스트를 고쳐줘야 하고 따라서 위와 같이 의미가 퇴색 될 수 있다. 따라서 이런 때는 통합 테스트를 활용하여 상태를 기반으로 검증하는 것이 좋다. BO의 예를 들면 실제 BO나 Service를 호출하고 데이터베이스 등에 값이 제대로 들어갔는지 등을 검사하는 것이다. 이렇게 만든 테스트는 객체의 관계를 조정하는 등의 리팩토링을 해도 달성되는 결과는 같기 때문에 테스트를 수정할 필요가 없고 안전망으로써 역할을 잘 수행한다.

 

 

 

---

 

 

 

새로운 언어로 바꾸는 것 외에도, 기업들은 응용프로그램과 데이터의 위치를 재배치하고 있다. 일반적으로 레거시 시스템들은 그것들을 개발했던 플랫폼에서만 운영될 수 있었다. 대체로 새로운 개발환경은 레거시 시스템과 데이터를 계속 지원해야할 필요에 대해 책임을 진다. 많은 새로운 도구들을 이용하여, 새로운 프로그램이 레거시 데이터베이스들을 액세스할 수 있다.

 

 

 

---

[참고]

https://arabiannight.tistory.com/129

IT/용어 레거시(legacy) 란?

https://brocess.tistory.com/21

Legacy 코드 개선하기