프로젝트가 전체적으로 postFix로 Entity가 안붙어있는데, IssueEntity, LabelRefIdEntity와 같이 postfix로 ~Entity로 하면 계층 구분하는게 더 용이합니다.
마치 RequestDto, ResponseDto를 보면 Presentation Layer를 구분하듯이요.
이 부분은 생각 못해봤는데 그렇다고 한다.
@Getter
@NoArgsConstructor
@Table(name = "user")
@Entity
public class UserEntity {
그래서 이런 식으로 변경해주었다.
private Map<String, String> parsingKeyword(String keyword) {
Map<String,String> keywordMap =new HashMap<>();
String[] tokens = keyword.split(" "); //여기까지 하면 들어온 값을 파싱String Delimiter = " "를 선언해서 상수를 넣으면 나중에 실수를 줄 일 수 있을거 같아요
평소에 split를 할 때는 저렇게 상수 처리를 할 때도 있고 안 할 때도 있는데
실수를 줄이려며 하는 게 좋겠다.
public List<PostEntity> readPost() throws IOException {
BufferedReader reader = new BufferedReader(new FileReader(POST_PATH, StandardCharsets.UTF_8));
List<PostEntity> list = new ArrayList<PostEntity>();
reader.readLine();
String line ="";
while((line=reader.readLine())!=null) {
String[] split = line.split(COMMAN);
PostEntity post = new PostEntity(split[0],
split[1],
Boolean.parseBoolean(split[2]),
LocalDate.parse(split[3]),
LocalDate.parse(split[4]));
list.add(post);
}
reader.close();
return list;
}
return issueAssignees
.stream()
.map(AssigneeRef::getUserId)
.map(id -> new AssigneeInfo(id, getNameById(id)))
.toList()
;stream도 저렇게 내리는 거 같다!
2023 마스터즈
현재 item 테이블(판매자가 올린 중고 상품)에 조회수, 관심수, 채팅수를 나타내는 각각의 컬럼 (view_count, wish_count, chat_count)이 있습니다. 그런데 해당 컬럼들은 쓰기 작업이 굉장히 빈번하게 일어날 것 같은데 item 테이블에 있어도 테이블의 데이터를 읽는데 성능상 문제가 없을까요?
이를 개선하기 위해서는 테이블을 분리하는게 좋을까요?
-> 저라면 조회수, 채팅수에서 만약 빈번하게 쓰일 것 같다면 Cache를 사용하여 시간을 두고 갱신하지 않을 동안 시간을 재어 시간이 만료될 경우 RDB에 반영하도록 설정할 것 같네요.
-> 테이블을 분리하는 거는 성능에 크게 반영을 주지 못합니다. 즉, 정규화를 한다는 것인데 정규화가 무엇인지 정규화를 하는 이유에 대해서 공부하시는 걸 추천드립니다.
이번에 카페를 구현하면서 조회수같은 것을 어떻게 구현해야 할까? 고민했는데
위 방식처럼 일정 시간에 맞춰서 갱신하는 방식을 쓰면 될 거 같다.
chat_log 테이블은 채팅의 대화 내역을 저장하는 테이블입니다. 이 테이블에 많은 쓰기 작업이 일어날 것 같은데 보통 RDB에서 이 데이터를 관리하나요?
-> 이것도 마찬가지로 캐쉬나 NOSQL로 관리하고 그 뒤에 RDB에 저장합니다. 회사마다 다르긴한데 영구적으로 채팅을 저장을 하냐 또는 일정 시간을 지날 경우 채팅을 삭제하냐에 따라 RDB에 저장할 수도 있고 안할 수도 있답니다.
if (!member.getEmail().equals(userProfile.getEmail())) {
throw new UnAuthorizedException(ErrorCode.INVALID_LOGIN_DATA);
}email을 통해 해당 Member인지 판별하는건 해당 도메인에서 처리하는건 어떠세요? 만약 email이 아니라 추가적인 조건때문에 또다른 것으로 해당 Member인지 아닌지 판별하는 코드가 서비스코드에 늘어날 수도 있을거 같아요
추가 조건이 생기거나, 변경이 생길 수 있어서 캡슐화를 한다는 점 기억하자.
RestTemplate
RestTemplate의 역할이 무엇인지 생각하시면 좋을듯 합니다. RestTemplate이 OAuth 이외에는 안쓰는 클래스인가요?
리뷰를 보고 생각해보니 Resttemplate를 도메인config가 아니라 RestTemplateConfig에 등록해 사용하는 게 좋을 거 같다.
