앞서 적은 GroupA 하위에 ItemB, ItemC 말고도 ItemD라는 개념이 있는데 이번에 ItemD에 deploy 기능을 구현하게 됐다. ItemDClass에 deploy 기능을 위한 로직을 개발해야 하고 GroupAService 클래스 deployGroupA()메서드 안에 deploy item D 로직을 추가해야 했다. 앞선 시도가 성공적이진 않았지만 그 경험을 바탕으로 아쉬웠던 점을 보완해서 이번 개발에 적용해 보려 한다. 우선 앞선 시도에서 아쉬웠던 점을 먼저 짚고 넘어가보자 아쉬웠던점 코드 재사용 부분에서 기대했던 것 만큼 효과를 보기 어려웠다. GroupAService 안에 deploy item B, deploy item C 관련 메서드를 만들고 ItemBService, ItemCServ..
800줄 짜리 메서드가 있었다. 그래서 앞선 글에서 적은 내용들을 적용하기 딱 좋은 케이스라고 생각했다. 깨끗한 코드를 짜기 위한 연습이라 생각하며 리팩토링을 해보았다. 사전 설명 코드를 공개할 수가 없어서 말로 설명을 최대한 이해하기 쉽게 해봐야겠다. 회사에서 사용하는 개념인데 GroupA, ItemB, ItemC가 있고 GroupA는 ItemB, ItemC를 포함한다. 각 GroupAService, ItemBService, ItemCService엔 GroupA, ItemB, ItemC에 관한 동작들이 구현되어 있다. deployGroupA라는 메서드가 있다. 이 메서드에는 세부 기능 a, itemB, itemC, e를 위한 로직이 있었고 이 로직들은 if문과 for문 그리고 이유를 설명해주는 주석들이..
앞서 intro에서 refactoring 시 달성할 목표를 몇가지 적어보았다. 한 메서드는 인덴트를 하나만 else 예약어 사용을 자제하자 한 가지 메소드는 한 가지 일만 지역변수를 없애보자 말로만 하면 이해하기 어려우니 예시를 들어 알아보자. 예시는 유튜브에 박재성님의 우아한테크세미나 190425 TDD 리팩토링을 참고했다. 아래와 같은 코드를 가지고 목표를 어떻게 달성할지 알아보겠다. public class StringCalculator{ public static int splitAndSum(String text){ int result = 0; if(text == null || text.isEmpty()){ result == 0; }else{ String[] values == text.split(",..
1000줄이 넘는 메소드 그리고 복사 붙여넣기가 난무한 코드를 보며 나는 똥을 안싸는줄 착각하고 남탓만 하며 한숨 쉬던 지난날을 반성하며 '나 부터 달라지자' 라는 다짐과 함께 조금씩 리팩토링을 하며 경험한 것, 공부한 것들을 정리해가려 한다 리팩토링을 업무 로 한다? 리팩토링을 업무 로 한다는 것은 굉장히 힘든 일 인것 같다. 코드 상태에 대해, 테스트와 코드 리뷰에 대해 내 문제 제기를 몇번 해 보았다. 현재 상태를 모르는 사람은 없었다. 하지만 리팩토링을 할 시간을 얻어낼 수는 없었다. 우리 팀엔 하루가 멀다 하고 이슈가 들어왔으며, 수많은 고객사로 부터 갖가지 요구사항이 들어오고 있다. 이런 상황에서 인력을 빼서 겉으로는 티가 나지 않는 리팩토링 업무를 시킨다는 것은 내가 생각해도 굉장히 하기 어..
- Total
- Today
- Yesterday