Backend/회고

보호되어 있는 글입니다.

3주 차 미션은 설계 실수도 있었고, 코드에 욕심이 생겨 스스로 많은 생각이 들었던 한 주였다. 2주 차의 problem 1. 값을 하드코딩 하지 않는다. (공통 피드백) 2주차 미션을 풀 때는 '1', ', '등의 문자를 상수로 정의하지 않고 하드코딩 하였습니다. 3주 차 미션에서는 이러한 문제점을 해결하기 위해 각 클래스에 상수로 정의하였습니다. private static final String ONE_STEP = "-"; private static final String RESULT_MESSAGE = "최종 우승자"; private static final String COLON = " : "; public static final String CAR_NAME_MESSAGE = "경주할 자동차 이름을 ..

1주 차의 Problem을 해결하자. 회고의 목적은 문제를 인식하고 개선을 하는 것입니다. 1주 차의 Problem 1. JDK 17을 효과적으로 활용하지 못했다. 이 문제점을 해결하기 위해 JDK 17의 Record을 사용했습니다. public record RoundResultDto(String name, int location) { } public record GameResultDto(List winners) { } Record를 사용한 이유 간결성과 불변성이라는 장점을 가지고 있다. 필드 정의와 getter 메서드 작성 등의 반복적인 작업을 한 줄로 간결하게 표현할 수 있습니다. equals, toString, hashCode 등의 메서드를 자동으로 생성해 줍니다. 2. 의존성 주입 private ..

높은 응집도 낮은 결합도 1주 차의 핵심 키워드는 "높은 응집도 낮은 결합도"였다. 설계를 할 때도 항상 키워드를 중심으로 설계했다. Keep 설계를 확실하게 한 뒤, 개발을 시작하니까 갑작스럽게 변하는 내용이 없어서 좋았다. 높은 응집도, 낮은 결합도를 중심으로 개발을 하다 보니 자연스레 MVC 패턴이 생각났고 문제에 적용시켜보았다. 설계 Controller View에게 입력을 받은 뒤, Service를 통해 데이터의 가공을 요청하고 다시 결과를 View를 통해 표현 View 입력을 받은 뒤, Controller에게 결과를 전달하고, 받은 결과를 출력한다. Sevice Controller을 통해 데이터 가공을 요청받은 뒤, 가공을 마치면 결과를 Controller로 전달. 이렇게 개념을 확실하게 공부한..