유산 이라는 뜻이다.
레거시를 검색하면 이쪽으로 보라는듯이 소개를 한다.
이 페이지에서 소개하는 레거시 시스템이란 아래와 같다.
그리고 레거시 시스템을 계속 사용 할 때의 문제점은 아래와 같이 기술하고 있다.
이 페이지에서 'Modern interpretations' 부분을 보면 아래와 같이 소개하고 있다.
넷 중에 하나라도 포함되면 레거시 코드다.
자기 자신이 작성했던 코드라도 포함되는 부분이 있다면 여지없이 레거시 코드라고 볼 수 있다.
위에 레거시 시스템 부분에 소개된 에뮬레이션이나 하위 호환성을 구현 부분이 있다.
조금 더 쉽게 설명하자면, 레거시 코드를 수정할 수 없기 때문에 새로 작업한 코드가 레거시 코드와 통신할 수 있게 별도의 작업을 할 필요가 생긴다는 것이다.
그리고 레거시 코드는 개발자가 변경하기를 두려워하는 코드다.
이 말인 즉, 변경 했을 때 문제가 발생 할 위험성이 크고 어떤 문제가 발생할지 파악하기 힘들다는 것이다.
따라서 레거시 코드에 문제가 생겨서 수정이 필요한 일 이 생기면...
레거시 코드가 거대 할 수 록 문제는 걷잡을 수 없이 커진다.
레거시 코드가 되는 조건에서 벗어나면 된다.
그리고 그렇게 하기 위해 리펙터링을 하게 된다.
혼자서 일하는게 아니라면 코드는 협업을 위한 소통 수단이다.
나름 리펙터링을 했다고 생각했지만, 협업자들이(혹은 미래의 나) 이 소통 수단을 이해하지 못한다면 다시 레거시 코드가 될 수 밖에 없다.
리펙터링을 할 때 많이 하는 실수가 있는데,
코드를 파악하고 자신이 알아보기 편한 방식대로 고치는데 성공했으나 테스트 코드를 작성하지 않는 경우이다.
결국 '따끈따끈한 레거시 코드'가 되었을 뿐이다.
테스트 코드를 작성하지 않는 이유는 주로 '시간이 없어서' 이지만, 역설적이게도 테스트 코드의 작성은 작업 시간을 단축시켜준다.
테스트 코드를 작성하면 절대적인 코드 양이 늘어난다.
그만큼 시간을 써야한다고 느끼는 것이다.
하지만 조금만 경험을 돌이켜보면 그렇지 않다.
코드가 올바르게 작동하는지 확인하려면 print나 log(혹은 그런 비슷한 행위)를 하며 확인을 해야 할 것이다.
매번 코드를 실행시켜야 하고, 해당 지점까지 가서 확인해야 한다.
경우에 따라서는 실행 후에 확인 해야 하는 지점에 도달할 때 까지 몇번의 클릭과 몇번의 타이핑이 매번 들어가야 하는 일도 생긴다.
코드가 올바르게 작동하는지 곧장 피드백을 받을 수 있다.
문제가 생긴다면 테스트 코드가 해당 지점으로 네비게이션 역할을 해주기에 문제 지점도 빠르게 찾을 수 있다.
왜 이렇게 짰습니까? 미쳤습니까 휴먼
테스트의 작성은 개발자가 함수나 메서드를 작고 간단하게 만들도록 유도한다.
유지보수 하기 쉽게 작성 될 확률이 높아지는 것이다.
그리고, 테스트 코드는 일종의 인수인계 문서이며 소통 수단이다.
단기적으로는 빠른 피드백으로 코드의 이상유무를 빠르게 확인이 가능하고,
장기적으로는 유지보수가 가능하고 알아볼 수 있는 코드가 되어서 시간을 절약해준다.
이분 글 맛집이네요