우아한테크코스 4주차 회고🎄🎁
4주차 회고
인트로
우아한테크코스 6기 4주차 크리스마스 이벤트 미션 회고입니다. 🎄🎁
3주차 코드리뷰
- static final 상수 → enum으로 변경
- 반환값으로 null을 반환하는것은 적절하지 않다
- IllegalStateException은 로직의 흐름에 적절하게 적용하기
- 메서드명 잘 작명하기
- 생성자에서 한번에서 적용하기 = 객체의 불변성 잘 활용하기
- null 채킹 보다는 Optional을 사용해보기
기존에 enum으로 상수를 선언해서 사용을 했었지만 단순히 열거형을 사용하다보니 static final로 선언을 해서 사용을 해도 상관 없겠다고 생각을 했다. 리뷰어님이 코드 리뷰를 하던 중 enum의 기원관련된 링크를 공유해 주시고 enum을 사용해야하는 이유를 명확하게 알게 되었다.
에러 메시지만 출력하고 다시 재입력을 받는 로직을 할때 반환해야할 인자가 존재해 매개변수에 Supplier
블로그 글을 통해 null이 내재 할 수 있는 의미가 무궁무진해 안티패턴이라는 것을 알게 되었다.
IllegalStateException은 로직 흐름상 적절하게 사용해야 한다는 조언을 받았다. null이 들어갈 수 없는 경우에는 굳이 추가를 할 필요가 없다고 하였다.
메서드명을 명시적으로 나타내주기 위해 ~DividedByThousand라는 메서드명을 작명하였고 로직이 변경되면 메서드 명도 변경이 되어야 될 것 같다는 피드백을 받았다. “어떻게”에 집중한 메서드명이 아닌 어떤일을 하는 메서드인지 나타내주는게 중요하다고 생각했다.
객체를 생성하고 내부 인자 하나를 업데이트 해주는 로직을 작성하였다. 값을 한번에 받아와 저장을 하면 객체의 불변성을 장점으로 가져갈 수 있다고 생각이 되었다.
null값 확인을 “==”을 사용해서 null값을 확인했다. Optional을 사용해서 안정성을 높여서 확인을 하는 방법을 추천받았다.
회고
신선한데? 얼마나 분리를 해야하지?
ComponentFactory
이벤트는 하나만 실행이 되어야 하니까 하나의 인스턴스만을 가지고 있어야한다. 즉 이벤트를 전반적으로 관리하는 Controller는 하나의 인스턴스가 보장 되어야하고 싱글턴을 적용하였다. 싱글턴 적용시 enum으로 싱글턴을 적용하면 명시적 싱글턴 보장, 스레드 안정성 보장, 리플렉션 방지를 할 수 있다는 정보를 알게되고 enum으로 싱글턴 패턴을 적용하게 되었다.
OrderMenu, OrderManager
식당에 가면 메뉴를 받아가고 POS기를 통해 메뉴를 정산하는걸 떠올렸다. 그리하여 처음 입력받은 값을 ,로 나눠 OrderMenu에 저장을하고 OrderManager에 EnumMap으로 매뉴와 매뉴의 개수를 저장을 하였다.
Domain간의 협력
지난번에는 협력이라는 개념을 잘못 이해해 도메인의 메서드에 다른 Domain을 받은 안되는 거라고 생각을 했다. 하지만 Domain간의 협력을 하려면 매개변수로 받아와야하고 해당 부분을 적용을 하니 Service의 책임 줄어드는 것을 느낄 수 있었다.
MethodParameter
지난 미션에서 예외를 출력하고 재입력을 받기위해 Supplier를 사용했지만 반환값이 없는경우 null을 리턴을 받아야 했다. 따라서
@FunctionalInterface
interface MethodParameter {
void run();
}
위와 같이 interface를 선언해 매개변수로 메서드를 받아올수있도록 생성을 해 적용을 하였다.
마무리
어느덧 4주간의 시가니 지나갔다. 4주간의 시간을 보내면서 다양한 느낀 점이 있다. 첫 번째로 코드로 명시적으로 나타낼 수 있는 부분이 많고 중요하다는 점이다. 접근제어자 또는 final을 사요앻서 어느정도까지 접근 또는 수정이 가능한지 명시적으로 나타낼 수 있다는 점을 알게 되었다. 두 번째로 자바에는 다양한 collection이 존재하고 그에 따른 framework가 존재하고 그것을 잘 활용하면 코드가 간결하고 직관적으로 표현이 가능하는 점이 느껴졌다. 세 번째로 메서드명을 잘 짓는 것이 중요하다고 생각이 되었다. 메서드명을 잘 지으면 코드가 놀라울 정도로 잘 읽힌다. 마지막으로 역할과 책임을 나누는 것은 중요하다는 것이다. 역할과 책임을 잘 나눌수록 유연한 수정과 확장을 할 수 있는 부분을 경험하였다.
앞으로
4주간의 몰입의 경험을 할 수 있었습니다. 더 나은 코드를 작성하기 위해서 어떤식으로 설계하는게 좋은 방안인가 고민을 했습니다. 몰입의 효율을 할게 되었고, 몰입의 충만함을 알게 되었습니다. 다른 사람들과 함께 성장해 나아간다는 즐거움을 알게 되었습니다. 디스코드의 코드 리뷰를 통해 못보았던 부족한 부분을 알게 되었습니다. 앞으로 기회가 된다면 우아한테크코스를 통해 위와 같은 경험을 더 긴 기간동안 느끼며 성장을 도모하고 싶습니다.
Leave a comment