인프런 워밍업 클럽 3기 백엔드 코드 스터디 1주차

정리. A. 추상1) 구체에서 중요한것만 남겨서 추상화 해야 한다. 2) 추상으로 부터 구체를 유추하지 못한 이유추상화 과정에서 중요한 정보를 부각 시키지 못했다.공유 문맥이 없다.중요한 정보의 기준이 다를 수 있다.도메인 영역별 추상화 기준이 다를 수 있다. 잘못된 추상화가 야기하는 side-effect가 크다. 3) 이름짓기줄임말. 자제하는 것이 좋으나 관용적인 경우도 있다. 문맥이 있는 경우에는 허용할 수 있다.(lat, lon)은어/ 방언 사용하지 않기. 좋은 코드를 보고 습득하기 4) 메서드와 추상화- 한 문단의 주제는 반드시 하나여야 한다.- 메서드는 하나의 일을 해야 한다. 5) 반환타입 메서드명 (파라미터) {}구성{} : 메서드 구현부반환타입 + 메서드명 + 파라미터 : 메서드 선언부메서드명 (파라미터) : 메서드 시그니처메서드명 추상화된 구체를 유추할 수 있는 적절한 의미가 담긴 이름파라미터와 연결지어 더 풍부한 의미를 전달할 수도 있다.파라미터파라미터의 타입, 개수, 순서를 통해 의미를 전달파라미터는 외부 세계와 소통하는 창반환타입메서드 시그니처에 납득 가는, 적절한 타입의 반환값 돌려주기Void대신 충분히 반환할 만한 값이 있는지 고민해보기. -> 반환값이 있다면 테스트도 용이. * 한줄이라도 추상화를 하는지 -> 코드 크기보다 추상화로 부여하는 의미가 더 중요하다.6) 추상화 레벨외부세계 (추상화 레벨이 높다.) 내부세계( 추상화 레벨 낮다.)추상화 레벨을 맞춰주어서 읽다가 너무 구체적인 내용으로 나오지 않는지 체크. 7) 상수로 추출의미 가지고 있으나 상수로 추출 되지 않은 숫자, 문자열상수 추출로 이름을 짓고 의미를 부여함으로서 가독성과 유지보수성 높아진다. B. 논리 사고의 흐름1) Early return을 해서 if문 복잡하게 만들지 말기2) 사고의 depth 줄이기:이해하기 복잡하다면 중첩문의 depth 줄이기변수 사용하는 곳 가까이 쓰기 3) 공백 라인: 의미를 어디서 나눌지에 대한 의미를 가진다.4) 부정어는 사용 지양.5) 예외처리해피케이스도 중요하지만 예외를 꼼꼼히 해야 소프트웨어가 견고해진다.예외 가능성을 낮추기 -> 의도와 다르게 동작하지 않도록 한다.외부와의 접점이 검증 필요사용자 입력, 외부 서버, 객체 생성자 등불신을 하면서 검증하며 신뢰를 쌓아간다.의도한 예외랑 의도치 않은 예외 검증 * Optional : orElse(항상 실행), orElseGet(null인 경우만 실행) C. 객체 지향 패러다임1) 객체로 추상화비공개 필드, 비공개 로직공개 매서드의 선언을 통해 외부와 소통(퍼블릭 인터페이스)객체의 책임이 나뉨에 따라 객체간 협력 발생2) 객체가 제공하는 것절차 지향에서 잘 보이지 않았던 개념을 가시화관심사가 한군데로 모임.클라이언트는 구현에 신경 쓰지 않고 추상화 레벨에서 도메인 로직 사용 가능.3) 새로운 객체를 만들 때 주의할 점1개의 관심사로 명확하게 책임 정의 되었는지 확임.객체를 만듦으로써 외부 세계와 어떤 소통을 하려고 하는지 생각.생성자, 정적 팩토리 메서드에서 유효성 검증이 가능도메인에 특화된 검증 로직이 들어갈 수 있다.Setter 사용 자제 -> 의도 드러내는 메서드로 사용getter도 처음에는 사용 자제하고 반드시 필요한 경우 추가.외부에서 객체 내 데이터가 필요하다고 getter 남발은 무례하다. (또한, 의도를 드러내자)객체에 메세지를 보내기필드의 수는 적을 수록 좋다.소나큐브에서는 7개를 권장한다.4) SOLIDSRP : 단일 책임 원칙 응집도를 높이고 결합도를 낮추기 위한 방법.클래스가 변경되는 이유는 하나여야 한다.테스트가 용이하도록 만들어야 한다. OCP : 개방 패쇄의 원칙 개방 폐쇄의 원칙은 확장에는 열려있고 수정에는 닫혀있다.중요한 것은 코드 변경없이 클래스의 추가만으로 확장 가능해야한다. LSP : 리스코프 치환 원칙 자식은 부모의 인스턴스로 치환 가능해야 한다. 부모 객체가 쓰이는 곳을 자식으로 모두 바꾸어도 바뀌는 것 없이 작동해야 한다. ISP: 인터페이스 분리 원칙 SRP를 지킬 수 있도록 거대 인터페이스를 만들지 말고 기능별 분리한다.응집도를 높이며 결합도를 낮춘다. DIP: 의존성 역전 원칙 기존 고수준 모듈이 저수준 모듈을 의존하는 것을 모두 추상화에 의존하게 만든다.결과적으로 서로의 결합도를 낮추고 책임과 메시지만 남는다. 미션을 진행하며 배운점.: 혼자서 객체지향관련 책들을 읽고 프로젝트에 적용해보았지만 정리가 안된 느낌이 강했습니다. 그런데 강의를 들으면서 한번 더 복습하게 되고 멘토님은 어떤 방법이 유용하였고 중요한지 정리해 주셔서 좋다고 생각했습니다. 강의를 들을 수록 이전의 코드들을 되돌아 보게 되네요. 실습을 해보면서 복습도 되고 또 고민했던 부분들에 대해 인사이트를 얻게 되어서 좋습니다. 특히 이번 과제에서는 객체의 책임을 나눌때 "기능적으로 분리"를 해도 되는지 이전 개인 프로젝트에서도 고민이 많았는데 이번 과제를 하면서 어떻게 해야 될지 인사이트가 생겨서 그렇게 개인 프로젝트도 리팩토링 해 보았네요 ㅎㅎ

인프런 워밍업 클럽 3기 백엔드 스터디 1주차

혼자 객체 지향에 관해 공부한 내용들을 조금씩 적용해보고 싶어서 시작했습니다.마침 궁금했던 코틀린으로 간단한 프로젝트를 해볼 수 있어서 과제를 해나아가며 이것 저것 적용해보려고 합니다.코틀린은 널처리 관련해서 자바보다 언어 차원에서 지원을 많이 해준다고 해서 궁금하네요. 이번 주는 실습보다 강의 위주로 진행했습니다.스프링과 HTTP 그리고 JPA와 연관관계까지.간단한 기본기부터 이제 엔티티를 작성하며 ERD를 만드는 테이블 설계 과정에 들어왔습니다.발자국이 간단한 회고록만 작성한다고 생각해 내용들을 노트 필기를 많이 못했네요.다음 주차 부터는 노트도 더 하면서 들어야겠습니다. 일단은 가끔 까먹게 되는 HTTP Status Code에 관해 남기어 보았습니다.500, 400, 401, 200 정도만 많이 쓰는거 같은데 다른 코드도 써봐도 좋겠습니다.파일 관련해서는 415나 타임아웃 관련 504는 꽤나 유용해 보입니다.관성에서 벗어나 다른 Status Code도 무엇이 있나 체크해봐야겠습니다. 200: OK201: Created202: Accepted300: Multiple Choices400: Bad Request401: Unauthorized403: Forbidden404: Not Found405: Method Not Allowed415: Unsupported Media Type500: Internal Server Error502: Bad Gateway503: Service Unavailable504: Gateway Timeout 미션을 해결하는 과정:이번주 미션은 깃 리포지토리를 만드는거라 다음 미션을 진행 해보아야 할 것 같습니다. 깃 아이디 새로 만들어서 기존 인텔리 제이는 다른 아이디라 푸시가 될까 싶었는데 오리진 추가 후 푸시가 되어서 이 부분은 신기했습니다. 그렇지만 보안 부분으로 특정 아이디만 푸시하도록 제한 할 수 있게 조금 고민해봐야 할 것같습니다.