우테코]디스코드 정보 정리

손지민·2023년 12월 1일

우테코 자료

우아한 테크코스_프리코스

목록 보기

16/16

개요

우테코에서 디스코드를 통해 서로 토론하고, 정보를 공유하는 문화가 있다. 다른 개발자들은 어떤 부분을 고민하고 중요하게 생각하는지, 어떤 부분을 공부해야할지 키워드를 얻는데에 도움이 될 듯하여 정리하고자한다.

1. 토론하기

1.1. 키워드

1. 테스트 코드 작성 시 메서드 명

메서드명은 영어로 짓고 Junit에서 제공하는 @DisplayName 어노테이션 사용하여 테스트명을 한글로 출력되도록 정의
메소드 명을 한글로 쓰고, 상단에 @DisplayNameGeneration 라는 애노테이션을 쓰면, 매 메소드마다 DisplayName을 붙이지 않아도 됩니다 !

2. push 주기

commit은 자주하고 push 는 공유 목적이라고 생각하면 좋다

3. 상수는 constant 클래스에 따로 모아두는게 좋은가?

저 같은 경우에는 변경 가능성이 아예 없다고 판단되지 않으면 한 클래스에 모아두는 편입니다. 상수가 코드 내부에 있다는 것은 결국 상수를 변경할 때 코드에 수정이 발생한다는 것인데 그럼 결국 OCP 위반이 아닐까 생각이 들었습니다.

그리고 enum이나 상수 클래스를 의미별로 잘 분리해서 관리하면 유지보수 측면에서도 편리할 것으로 생각됩니다. 상수를 변경하자라는 이야기가 나오면 상수 패키지에서 해당 변수만 찾아 변경하면 되니깐요.

4. 도메인 개념

책-오브잭트(조영호)

5. 생성자 vs @Builder

6. is-a 관계/has-a 관계

7. 명시적 형변환 vs 암묵적 형변환

협업 측면에서 가독성을 위해 명시적이 낫다?

1.2. 공부해볼거리

gradle
Test-Junit/assertJ
함수형 프로그래밍 방식(Functional Programming, FP)vs절차지향(Procedural Programming)vs객체지향 프로그래밍(Object-Oriented Programming, OOP)
디자인패턴
- MVC 패턴의 장단점/목적? 에 대한 고찰(글에서는 디자인패턴MVC사용이 필수인가? 에 대해 작성함.)
- 아키텍쳐 패턴과 디자인패턴?
- MVC는 아키텍쳐 패턴 디자인패턴은 싱글톤 패턴 같은걸 말함.
- MVC 패턴은 리팩토링과 협업을 위한 가독성에도 도움이 됨.
stream
getter를 지양해야하는 이유
- https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/
- '가져오지 말고, 객체에게 메시지를 보내라'
기능단위 commit 주기
validation의 적절한 위치
- 김영한 답
static 정적 메서드의 사용
다만 제가 이해하고 있는 내용으로는 우선 validator와 같이 util의 성격이 강한 클래스의 경우 1회성으로 사용하고 나서 재사용될 필요가 없고, 따라서 인스턴스를 생성할 필요가 없기 때문이라는 게 가장 큰 이유인 것으로 알고 있어요.
이번 1주차 과제에서는 사용자의 Input을 한 번 검증하고 나면 InputView가 validator인스턴스를 계속 저장하고 있을 필요가 없기 때문에 저는 이렇게 이해하고 사용했습니다!
객체지향 생활체조
else 예약어를 쓰지 않는다.
- https://tecoble.techcourse.co.kr/post/2020-07-29-dont-use-else/
- return Early pattern
절차지향 vs 객체지향
플로우차트 그리기?
- 마크다운에서 지원하는 기능으로 플로우차트 그리기
- ToDo List로 작성하기
- Draw.io 활용
- figma 에 그리기
Mock
커밋 방법
- 대부분 IDE 사용, 가끔 터미널 명령어
- 서버환경 같은 경우에는 cli 연습하는게 기능도 많고 좋을듯!
- sourcetree, github desktop : conflict 났을 때 편하게 보기 위한 참고용
DTO와 MVC
캐시/로깅
depth
일급 컬렉션
정적팩토리메서드
코드를 빠르게 이해하려면 - 포비
유효성 검사 위치
멀티 스레드
검증 처리 위치
validation 검증은 클래스 분리? 검증할 클래스에서? 어디서 처리할지
* 보통의 경우는 그게 필요한 클래스에서 메소드만 추가해서 바로 validation까지도 해주는게 좋습니다.
OOP관점에서, 간단한검증은 기본 클래스에서 하고,
검증해야할것이 아주 많아질때만(3~4개 메소드이상) , [이름]Validator라는 식으로 검증클래스를 따로만들어서 뽑아내는 게좋습니다
(응집도를 높이고 가독성을 높이는 방법)
controller 의 역할 범위
상수 클래스 만들지 말지
예외 처리 클래스 만들지 말지
utils 패키지
정적 파일 디렉토리 구조
- 프로필 이미지를 저장하는 기능 때문에 파일 업로드/다운로드를 구현
- 월 별로 분리?
구글 바드
GPT 를 코드리뷰에 사용하기
view, model 중 어디서 검증할지
REST API 구현 시 공통응답객체(응답형식) 사용 여부?
- ResponseEntity
생성자의 매개변수 갯수 제한
핵심 기능을 한 줄로 정리해보기