개발 들어가기 앞서 요구사항을 완벽히 분석하고 설계한 후 개발에 들어가진 못했다. 변명을 하자면... 그런 습관이 잘 들어있지 않았고 시간이 부족했다. 그래서 개발을 하다가 더 좋은 방법이 생각나 중간 중간 변경하기도 했다. 채점자 리뷰에서도 이 부분과 관련해 지적을 받은게 있어서 앞으로 설계에 대해 신경을 좀 더 써야겠다고 생각했다. DB 설계 테이블 테이블 이름 역할 song 노래 정보 저장 album 앨범정보 저장 playlist playlist 정보 저장 playlist_song playlist와 playlist에 들어있는 곡 정보를 담고 있는 테이블 테이블간 관계 한개의 앨범에 여러 노래가 담길 수 있으니 album과 song의 관계는 1:n 관계로 간단하게 정했다. playlist와 song의..
블로그를 옮기며 예전에 썼던 글을 옮겨왔습니다. 오랜만에 구직활동을 시작했다. 결국 과제탈락(채점 결과 상위 3%라고 써져 있었는데ㅠㅠ) 이지만 실무에서 스프링부트를 사용하지 않았음에도 긍정적인 피드백을 받아 용기도 얻을 수 있었고 나쁘진 않았던 경험이었다. 이대로 그냥 좋은 경험 이었다 하고 넘어가 버리면 또다시 실력이 원점으로 돌아갈 것 같아서 과제를 하며 했던 생각, 개발 의도를 적어 놓으려 한다. 그리고 채첨관들의 리뷰 + 스터디원들의 리뷰 + 셀프 리뷰를 통해 코드를 개선해보고 최종 마무리를 해보려 한다. 순서 순서는 설계 리뷰 내용 개선 방향 으로 진행하려 한다.
앞서 적은 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줄이 넘는 메소드 그리고 복사 붙여넣기가 난무한 코드를 보며 나는 똥을 안싸는줄 착각하고 남탓만 하며 한숨 쉬던 지난날을 반성하며 '나 부터 달라지자' 라는 다짐과 함께 조금씩 리팩토링을 하며 경험한 것, 공부한 것들을 정리해가려 한다 리팩토링을 업무 로 한다? 리팩토링을 업무 로 한다는 것은 굉장히 힘든 일 인것 같다. 코드 상태에 대해, 테스트와 코드 리뷰에 대해 내 문제 제기를 몇번 해 보았다. 현재 상태를 모르는 사람은 없었다. 하지만 리팩토링을 할 시간을 얻어낼 수는 없었다. 우리 팀엔 하루가 멀다 하고 이슈가 들어왔으며, 수많은 고객사로 부터 갖가지 요구사항이 들어오고 있다. 이런 상황에서 인력을 빼서 겉으로는 티가 나지 않는 리팩토링 업무를 시킨다는 것은 내가 생각해도 굉장히 하기 어..
Serializer 하나 변경하는게 이렇게 큰 결과를 불러올 줄이야... Refactoring의 일환으로 패키지를 변경했다가 Redis 관련 에러가 났고 이를 해결한 경험을 적어놓는다. Redis Serializer redis 는 data를 byte array 형태로 저장한다. spring data redis에서는 user - redis 사이 데이터를 변환할 수 있도록 여러 serializer들을 제공 하고 있다.(참고 사이트) 상황 팀원 중 한 명이 기존 서비스 legacy 코드가 보기가 어려워 한번 정리 하는 셈 치고 패키지들을 변경 시켰다. 나도 리뷰 할 때 '패키지 위치만 변경 한거면 intellij에서 refactoring 잘 해주겠지' 생각에 빌드 잘 되고 테스트 통과한 것만 보..
요새 '오브젝트'라는 책을 다시 보고 있는데, 응집도와 결합도에 관한 내용이 나온다. 대강 LOW COUPLING(낮은 결합도)와 HIGH COHESION(높은 응집도)를 고려해 가며 설계를 하면 변경에 유연한 설계를 할 수 있다는 내용 이었다. 글로는 잘 이해 했다 생각했지만 실제로 어떻게 적용해볼까 고민이 있었는데, 마침 적절한 경험을 한 것 같아서 기록해두려 한다. 예시 상담신청이라는 도메인이 있고, 이번에 타임세일이라는 도메인을 추가하게 되었다. 유저는 상담신청을 할 수 있고, 타임세일을 통해 은 특정 시간에 싼 가격으로 상담신청을 할 수도 있다. @Entity public class Consultation { @Id Long id; ... @ManyToOne @JoinColumn(name = "..
- Total
- Today
- Yesterday