[개발방법론] 레거시 코드 활용 전략

최근 관심이 간 책 중에 하나가 "레거시 코드 활용 전략"이라는 책입니다. 프로그래머의 중요한 임무중 하나는 다른 사람 혹은 자신이 생산한 레거시 코드를 끊임없이 개선하고 재생산하는 것이라고 생각합니다. 실제로도 경험한 대다수의 업무가 그러했습니다. 해당 책을 읽기 전에 관련하여 내용을 정리한 좋은 포스팅이 있어 일부 내용을 발췌해보았습니다.

 

출처는 http://soomong.net/blog/2010/11/21/book-legacy-code/ 입니다.

 

- 레거시코드가 왜 변경될 수 밖에 없는 것이고 그 변경을 단위테스트로 cover

- 테스트코드를 작성하기 쉽도록 레거시코드를 어떻게 리팩토링하는가

- 레거시코드에서 (비교적) 안전하게 의존관계를 제거하는 방법

- 의존관계를 없애기 위해 실용적인 전략들

- Extract 그리고 Extract 그리고 Extract

- 변경에 따른 영향을 파악하기 위한 Effect Sketch

- 학습을 위한 test code 작성

- 일단 중요한 부분부터 테스트하자는 PinchPoint 전략

- 레거시 코드를 이해하기 위한 구조 Sketch, CRC, 폐기용 리팩토링

- 레거시 코드의 책임을 식별하고 분리하기위한 Feature Sketching 전략

- 괴물 메소드에 적절한 테스트 루틴을 적용하기 위한 전략

- 의존관계를 없애기 위한 25가지 기법

 

- 뭐라고요? 그 부분을 위해 메소드 하나를 더 생성하라 말입니까? 그렇게는 못합니다. 대신 기존 메소드 안에 몇 줄의 코드를 추가할 수는 있습니다. 이렇게 하면 약간만 수정하면 되므로 훨씬 안전합니다

- 편집하고 기도하기 프로그래밍

- 좋은코드와 나쁜코드의 차이를 느끼기 시작하는 시점

- 중요한 것은 좋은 설계란 테스트가 가능해야 하고, 테스트가 불가능한 설계는 나쁜 것이라는 점

- 테스트 루틴이 부족한 경우에 시스템이 실제로 어떤 일을 수행할지를 파악하는 유일한 방법은 마음 속으로 '컴퓨터를 돌리는' 것

- 당장 더 나은 설계 쪽으로 바로 갈 수는 없다. 하지만 책임을 식별해 내는 행위 그 자체만으로도 작업을 진행하는데 있어서 더 나은 의사결정을 쉽게 내릴 수 있다. 그렇다, 나은 설계란 그런 것이다.

- 여러팀이 저지르는 최악의 실수 가운데 하나는 개발 단계에서 일정 시점에 이르렀을 때 설계가 끝났다 라고 생각하는 것이다

- 가장 쉬운 방법은 생각을 아주 많이 한 후에 시스템을 패치하고 변경이 올바르게 되었기를 바라는 것이다.

- 중요한 것은 책임들을 찾아낼 수 있어야하고 또 그것들을 잘 분리하는 법을 배워야 한다는 것이다.

- Private 메소드를 테스트하고 싶은 욕구가 생긴다면 그 메소드는 결코 private 메소드이면 안된다. 해당 메소드를 public으로 만드는 것이 마음에 걸린다면, 해당 메소드는 다른 클래스 상에 있어야 한다.

- 식별화 능력을 키울 수 있는 가장 좋은 방법은 좀 더 많이 읽어 보는 것이다.

- 키보드로 무엇이든 입력할 때에 어떻게 s/w에 영향을 미치는지 아는 것이 버그를 줄이는데 도움을 준다

- 레거시 코드에서 작업하는 것은 마치 외과수술과 같다. 의사들은 결코 혼자 수술하지 않는다.

- 결국 우리가 작업할때의 마음가짐이 중요한 것이다. 좀 더 즐겁게 프로그래밍 하라.