리팩토링에 대해 어느정도는 들어본 내용이었지만 책을 읽어보니 좀 더 개념이 정리되는 것 같아서 뿌듯했습니다. 과제를 제출해야 환급되는 구조라서 열심히하게 되네요ㅋㅋ 분량을 채우기 위해 일부러 많이 작성한 부분도 있지만 기록을 위해 남겨둡니다.
1. YAGNI에 대하여 서술하세요
YAGNI는 “you aren’t going to need it”의 줄임말 입니다. 미래에 추가될지도 모르는 스펙을 위해서 미리 추가적인 기능이나 인터페이스를 만들어 두지 말자는 취지의 말입니다. 이렇게 설계하는 방식을 간결한 설계, 점진적 설계라고 한다고 저자는 설명합니다. 현재 주어진 스펙 안에서 최대한 적절한 설계로 코드를 작성합니다. 실제로 추가적인 기능을 개발해야할 때 다시 리팩토링을 진행합니다. 미래에 추가될 스펙을 미리 예측해서 작업하는 것이 도움이 되는 경우도 있겠지만 오버엔지니어링으로 이득을 보는 경우는 많지 않습니다. 실제로 작업을 해보고 원하는 바를 정확하게 알게되었을 때 그것을 위해서 작업하는 것이 더 효율적입니다. 현재 주어진 문제를 푸는것에 집중한다고 해서 설계를 대충하는 것은 아니라고 저자는 주의의 말을 합니다. 다만 아키텍처가 한번 작성되면 고정되는 것이 아니라 점진적으로 진화해 간다는 것을 기억하고 조금씩 발전시켜 나가는것이 중요합니다. 소프트웨어를 점진적으로 발전시켜 나가는데는 리팩토링이 가장 핵심이라고 할 수 있습니다.
2. 리팩터링을 해야 할 때가 언제인지 저자의 견해를 서술하시요
모든 경우에 리팩토링을 해야하는 것은 아닙니다. 저자는 구체적인 예시를 들며 리팩토링을 고려해야할 시점을 소개합니다.
- 3의 법칙: 비슷한 일을 3번째 하게되었을 때
- 준비를 위한 리팩토링: 조금만 리팩토링하면 기능을 추가하기 쉬울것 같을 때
- 이해를 위한 리팩토링: 이해한 바를 명시적으로 코드에 드러내고 싶을 때, 새로운 설계를 할 때, 새로운 코드를 접했을 때 (새로운 팀에 갔을 때 조금씩 리팩토링 하면서 코드에 적응하는 것이 좋을 것 같다는 생각을 했습니다)
- 쓰레기 줍기 리팩토링: 간단히 수정할 수 있으면 바로 고치고, 아니라면 기록 후 나중에 리팩토링
- 수시로 하는 리팩토링: 저자가 지향하는 방향인데, 거창한 계획을 하는 것보다 프로그래밍 중에 최대한 자주 리팩토링을 하는 것을 추천함
- 조금씩 개선하기: 오래걸리는 리팩토링은 바람직 하지 못하다고 합니다. 많은 부분을 재구조화 하면서 시간이 오래 걸린적이 있었는데, 이렇게 하면 리팩토링의 목적을 잊어버리게 되는 경우가 많았습니다. 그런데 조금씩 개선을 하기 위해서는 유닛 테스트가 충분히 지원되어야 한다고 생각합니다.
- 리팩토링을 하지 말아야 할 때: 굳이 수정할 필요가 없을 때, 청므부터 새로 작성하는게 쉬울 때
3. 설계 단계에서 모든 요구사항을 알 기 힘드므로 아키텍쳐의 변경이 필요할 때가 많다. 이를 해결하기 위한 저자의 견해를 서술하시오
과거에는 모든 요구사항을 미리 파악하고 설계를 완벽하게 마친 후에 코드를 작성해야 한다는 생각이 널리 퍼져있었던 것 같습니다. 아마도 프로그래밍 활동을 건축하는 것과 비슷하게 바라보고 있었던 것 같습니다. 완벽하게 요구사항을 파악하는 것은 사실상 불가능 합니다. 그리고 애자일 방식이 널리 퍼지면서 프로그래밍 개발 주기 짧고 빨라졌기 때문에 요구사항도 계속해서 변한다고 볼 수 있습니다. 처음부터 모든 것을 파악하려고 하지말고 어느 정도 파악한 요구사항들을 설계에 녹여내면서 진행하는 것이 좋습니다. 개발하면서 요구사항이 더 명확해지는데 이때 리팩토링을 하면서 개선시켜 나갈 수 있습니다. 1번 질문에서 나왔던 YAGNI 개념과 동일한데 파악된 요구사항을 중점으로 개발합니다. 자신있는 리팩토링을 위해서는 테스트 코드가 있으면 훨씬 수월합니다. 테스트가 설계를 결정해주는 것은 아니지만 설계를 개선해나갈 수 있는 좋은 도구 입니다. 개인적인 경험으로도 겉보기 동작이 동일한 것을 확인해주는 테스트 코드가 있을 때 훨씬 더 자신있고 빠르게 설계를 개선할 수 있었습니다.
4. 리팩터링으로 이점이 무엇인지 저자의 관점에서, 회사 윗사람을 설득시킨다는 생각으로 서술하세요
리팩토링은 개발자들 사이에만 존재하는 윤리적인 문제가 아닙니다. 단순히 깔끔한 코드를 만들어내는 것이 전부가 아닙니다. 소프트웨어는 시간이 갈 수록 기능이 추가되는 경향이 있습니다. 기능이 추가될 수록 코드가 늘어나고 코드끼리 서로 영향을 줍니다. 그래서 시간이 지날 수록 개발 속도가 느려질 수 있습니다. 리팩토링을 하면 이해하기 쉽고 기능 추가를 하기 간편한 구조를 얻을 수 있습니다. 좋은 설계를 점진적으로 얻어갈 수 있다는 뜻인데, 이렇게 되면 개발 속도를 일정하게 유지할 수 있습니다. 이러한 경제적인 이유 때문에 리팩토링을 해야합니다. 만약 개발 기간을 결정하는 사람을 설득할 수 없다면, 리팩토링을 한다는 말을 아에하지 않는 방법도 있습니다. 리팩토링은 대부분 기간을 따로 빼서 진행하는 것이 아니라 일상의 개발 중에 짧고 자주 진행되는 것들이기 때문에 특별한 기간 산정이 필요 없을 수도 있다고 합니다. 다만 누군가는 일부러 속이는 것은 아니라 리팩토링을 통해서 개발 속도를 높이고 최종적으로 회사의 매출에 더 기여할 수 있기 때문에 회사에도 좋을 일이 됩니다.
5. 리팩터링이 어떻게 하여 소프트웨어의 성능에 도움이 될 수 있는지 저자의 관점을 서술하시오
리팩토링을 진행할 때는 속도 보다 이해하기 쉬운 코드를 위주로 개선하게 됩니다. 이렇게 하면 약간의 속도 저하가 있을 수도 있습니다. 리팩토링 후에 코드를 파악해보면 속도를 저하시키는 부분을 찾는게 훨씬 더 쉽다고 저자는 말합니다. 복잡한 코드를 보면서 속도 저하가 있는 곳을 유추하는 것보다 리팩토링 후에 속도를 분석하는 것이 더 유용합니다. 개발 중에 속도를 분석하면서 개발한다고 해도 속도를 높이는데 큰 도움이 되지 않았다고 합니다. 그리고 속도를 느리게 하는 부분은 프로그램의 10% 정도 밖에 되지 않는다고 합니다. 대부분의 경우 특별한 기능을 하고 있는 코드보다 당연하게 기존에 당연하게 작동하고 있는 부분이 속도를 느리게 하고 있습니다. 리팩토리을 하게되면 이해하기 쉬운 코드를 얻게되고 버그를 찾을 확률도 높아집니다. 예를 들면 불필요하게 여러번 호출하고 있는 함수를 찾을 수 있습니다. 그래서 프로그래밍 속도를 높일 수 있다고 저자는 주장합니다. 특히 자주 읽게 되는 부분을 리팩토링하면 효과가 큽니다.
6. 본인이 실제로 경험한 리팩터링에 대해 작성해 주세요
10년된 코드를 품고 있는 프로그램을 개발 중이라서 리팩토링을 자주 하게 되었습니다. 처음에는 코드를 무작정 옮겨보기도 하고 완전히 새로 작성해보기도 했는데, 최종적인 결과물이 만족스럽지 않았습니다. 어떤 경우에는 리팩토링 후에도 기존의 설계와 거의 동일한 경우도 있었습니다. 리팩토링을 거창한 것으로 생각해서 많은 부분을 한꺼번에 수정하려고 해서 설계를 빠르게 변화시키지 못했던 것 같습니다. 너무 완벽한 결과물을 얻으려는 마음보다 일상에서 작은 부분을 자주 개선시켜야 겠다는 생각을 했습니다.