개발 도서 리뷰(18) 레거시 코드 활용 전략 ✮✮✮✮✮✮✮✮✮✮

 

레거시 코드 활용 전략

나의 평점 백점/5.0
 

추천합니다.

- 레거시 코드를 다루고 있는 개발자

- 내가 레거시 코드를 작성하고 있는 것은 아닌지 고민되는 개발자

- 그냥 모든 개발자 

추천하지 않습니다.

- 해당 없음
 

 

 

간만에 내 가슴을 뛰게하는 책..

테스트 코드와 TDD의 필요성을 단순히 논리적 관점에서만이 아니라 개발자의 감성적인 측면에서도 훌륭하게 전달하는 책..

로버트 마틴의 추천사와 검토까지 받은 책..

저자 이름이 익숙해서 찾아보니 SOLID 원칙을 제안한 그 사람..

 

내가 읽어본 모든 개발 관련 서적 중 가장 재미있고, 예제 또한 실용적이었다.

이 책을 읽고나서 "우리 팀 모두에게 이 책을 추천하고 싶다"는 생각이 들었다.

 

 

제목에서 알 수 있듯, 이 책의 핵심은 레거시 코드를 안전하게 유지보수하는 방법인데, 이를 통해 레거시 코드를 작성하지 않는 방법에 대해서도 깊은 인사이트를 얻을 수 있다.

 

이 책을 읽으면서 나의 잘못된 관점과 편견에 대해 깨닫는 순간이 많았다. 특히 리팩터링과 테스트 코드에 대한 근시안적인 생각이 크게 바뀌었다.

 

여러분도 이 책을 읽고 더이상 자신이 레거시 코드를 작성하고 있는 것은 아닌가하는 고민에서 벗어날 수 있으면 좋겠다..

 

 

“때때로 우리는 고객에게 책임을 돌린다. 고객의 요구 사항이 변경됐기 때문이라고 말한다. 최초의 요구 사항에 고객이 만족했다면 설계에 아무런 문제가 없었을 것이라 스스로를 위안한다. 요구사항을 변경한 고객이 잘못했다는 것이다. 글쎄, 여기에 중요한 사실 하나가 있다. 요구사항은 반드시 변한다. 요구 사항 변경을 수용할 수 없다면 설계에 문제가 있는 것이다.”

“예방만으로는 충분하지 않다. 최선의 원칙을 숙지하고 최선의 패턴을 사용하며 최선의 실행 방법을 따르는 가장 잘 훈련된 개발 팀조차 때때로 일을 망칠 수 있다. 부패는 계속 쌓여가므로 부패를 방지하는 것만으로는 충분하지 않다. 부패를 되돌릴 수 있어야하는 것이다.

“이것이 바로 이 책의 주제다. 즉, 이 책은 부패를 되돌리는 방법을 다룬다. 복잡하게 얽힌 불명료한 시스템을 단계별로 점진적인 방법을 통해 단순하면서 잘 구조화돼 있고 훌륭하게 설계된 시스템으로 변모시키는 방법을 알려준다. 엔트로피를 역전시키는 방법에 관한 책이라 말할 수 있겠다.”

- 로버트 마틴의 추천사



“몇 년 전, 나는 퇴근 후에 친구인 에릭 미드에게 전화를 걸었다. 에릭이 새로운 팀에서 컨설팅 작업을 막 시작한 것을 알고 있던 나는 “새로 일하게 된 팀은 어때?”라고 물었다. 그 질문에 에릭은 “나 참, 그들은 레거시 코드를 작성하고 있어.”라고 답했다. 나는 이 말에 한 대 얻어맞은 것 같은 느낌을 받았다. 나도 그런 느낌을 자주 받았기 때문이다. 고객사의 개발 팀을 처음 만났을 때 자주 느꼈던 기분을 에릭이 정확하게 표현했던 것이다. 그들은 매우 열심히 일하지만, 하루 일과가 끝날 때면 일정에 대한 부담, 과거로부터의 관행, 참조 코드의 부재 등을 이유로 레거시 코드를 작성하고 있었다”

“내게 레거시 코드란, 단순히 테스트 루틴이 없는 코드다. 다만 이 정의는 다소 불완전하다. 코드의 좋고 나쁨이 테스트와 어떤 관계가 있을까?”

“테스트 루틴이 없는 코드는 나쁜 코드다. 코드가 얼마나 훌륭하게 작성돼 있는지 여부와는 상관없다. 아무리 깔끔하게 객체 지향적이며 캡슐화가 잘돼 있어도 소용없다. 테스트 루틴이 있으면, 코드의 동작을 빠르게 검증하며 수정할 수 있다. 테스트 루틴이 없으면 우리가 작성하고 있는 코드가 좋아지고 있는지, 나빠지고 있는지 제대로 알 수 없다.”

“깨끗한 코드만으로는 충분하지 않다. 테스트 루틴 없이 대규모의 수정 작업을 시도하면 커다란 어려움에 직면하게 된다. 이는 마치 안전그물망 없이 공중 곡예를 하는 것과 비슷하다. 이 작업은 엄청난 기술과 더불어, 각 단계에서 벌어질 일을 전부 파악하고 있어야 한다. 변수 몇 개를 수정했을 때 어떤 일이 일어날지 정확히 예측하는 것은 마치 공중에서 재주를 넘었을 때 다른 동료가 팔을 잡아줄지 말지 미리 아는 것과 같다.”

“물론, 개발팀의 실력이 향상될수록 처음부터 더 깔금한 코드를 작성할 수 있다. 하지만 그래도 기존의 오래된 코드를 깨끗하게 만드는 데는 많은 시간 이걸린다. 그리고 완전히 깔끔하게 만들기는 거의 불가능하다. 그렇기 때문에 레거시 코드를 테스트 루틴이 없는 코드라고 정의하는 데는 아무 문제가 없다.”

“기존의 레거시 코드 내에서 잘 짜여진 코드들을 확장하는 방법을 사용할 수 있지만, 코드 수정에 필요한 단계들을 밟다 보면 일부 코드는 오히려 나빠지는 경우도 있는데 그렇다고 놀라지는 말자. 이러한 작업은 외과 수술과 같다. 여러 곳을 절개해야 하고, 내장 사이를 관통해야 하며, 이 과정에서 미적인 판단은 유보해야 한다. 이 한자의 주요 기관과 내장은 이전보다 나아질 수 있을까? 물론이다. 그럼 환자의 긴급한 문제를 제쳐두고 절개 부위를 봉합한 후에 환자에게 잘 먹고 마라톤 훈련을 하도록 권유할까? 그럴 수도 있다. 하지만 정말로 필요한 것은 환자를 있는 그대로 보고 환자의 문제를 고쳐서 건강한 상태가 되도록 이끄는 것이다. 이 환자는 마라톤 선수가 되지는 못하겠지만, 마라톤 선수라는 이상을 위해 건강 회복이라는 현실을 희생해서는 안된다. 좀 더 건전하고 작업하기도 쉬운 코드베이스로 개선할 수는 있다. 환자의 건강을 일단 다소라도 회복한 후에 환자의 건전한 라이프 스타일 확립을 돕는 것이 바람직하듯이, 레거시 코드도 마찬가지다.”

- 마이클 페더스