woowacourse-teams/2020-14f-guys

오프라인 스터디, 소모임의 목표 달성을 도와주는 동기부여 서비스 🚴‍♂️

2020-14f-guys's Issues

와이어프레임 설계하기

레이스를 시작하는 기능

인증 이미지 파일 업로드 기능

유저 flow 논의

도메인 스키마 일치 테스트 작성

@SpringBootTest
class MemberRepositoryTest {
    @Autowired
    private MemberRepository memberRepository;

    @DisplayName("주어진 Member 객체가 DB에 저장이 잘 되는지 확인")
    @Test
    void saveMember() {
        final Member member = Member.builder()
            .name("김범준")
            .cash(new Cash(new BigDecimal(1)))
            .email("[email protected]")
            .role(Role.MEMBER)
            .build();

        final Member persisted = memberRepository.save(member);

        assertAll(
            () -> assertThat(persisted.getId()).isNotNull(),
            () -> assertThat(persisted.getCash()).isEqualTo(new Cash(new BigDecimal(1))),
            () -> assertThat(persisted.getName()).isEqualTo("김범준"),
            () -> assertThat(persisted.getEmail()).isEqualTo("[email protected]"),
            () -> assertThat(persisted.getRole()).isEqualTo(Role.MEMBER),
            () -> assertThat(persisted.getCreatedAt()).isNotNull(),
            () -> assertThat(persisted.getUpdatedAt()).isNotNull()
        );
    }
}

위 테스트는 모든 필드를 갖는 Member 객체를 만들고 repository.save()를 통해 도메인-스키마 간 불일치 발생 또는 에러를 확인하는 테스트입니다.
현재는 도메인-스키마의 일치가 되는지 안되는지 확인할 방법이 없습니다. 또, 테스트 커버리지도 0%에 가깝기 때문에 후에 commit 할 때, 테스트 커버리지 80% 이상 원칙을 지키기 위해서라도 기본적인 Save 테스트는 있으면 좋다는 생각이 들었습니다.

하지만 각자 기능을 작성할 때, 그때 그때 각 기능 별로 테스트를 작성하면 된다고 생각할 수도 있기 때문에 간단하게 찬반 의견 정도 남겨주시면 감사하겠습니다 :)

아, 그리고 Assignees는 랜덤으로 정하는 게 좋을 것 같아요!

레이스를 생성하는 기능

엔티티 저장 전 Validator가 동작해야함

도메인 설계하기

• 엔티티, 도메인 용어 확정짓기
• Aggregate 정하기

레이스가 끝나는 기능

1. 라이더별로 성취율을 계산하는 기능

2. 성취율에 따라 금액을 분배하는 기능(수수료 포함)

매번 중복 생성되는 객체를 어디서 관리할 것인가?

기능 - 프론트엔드 추가

회원 정보 조회하는 기능

라이더 등록 기능(레이스에 참가하는 기능)

특정 라이더의 미션 인증을 실패로 수정하는 기능

Dto는 어디 레이어까지?

프론트 package.json 설정

• 기초 의존성 설정

Github Actions 활용 논의

Java With Gradle

Link

기능

Github 상에서 Action 수행 전, 후 자동으로 Script로 설정한 기능들이 수행됨

• 원하는 OS 에서 프로젝트 실행 가능
• 원하는 JDK 버전과 아키텍쳐에서 실행 가능
• 빌드 & 테스트 자동화
• 의존성 캐싱
• JAR 파일 빌드 및 다운로드 & 업로드

해당 내용을 학습하여 적용한다면, 빌드와 배포에 도움이 될 것으로 판단됩니다.

특정 기술에 대해서 조금 더 학습할 크루를 정한다.

• github action
• restful api
• github project
• etc

담당을 결정하는 방식은 사다리타기와 같이 랜덤하게 결정한다.
(원하는 사람이 가져가면 분배가 적절하지 않을 것 같기 때문에)

레이스의 링크를 통해 레이스에 참여하는 기능

회원 탈퇴하는 기능

BaseEntity 사용 여부 결정

BaseEntity를 사용할 경우

• 생성자를 모두 private으로 감추고 Builder만 사용 가능
• id 필드에 Wither(@With)가 없어야함
• BaseEntity의 필드를 포함한 @PersistenceConstructor를 따로 만들어야함(Spring Data JDBC에서 인스턴스를 생성할 때 사용)
• BaseEntity에는 반드시 @NoArgConstructor가 존재해야함

// Entity.java

@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder
@EqualsAndHashCode(of = "id", callSuper = false)
@Getter
public class Entity extends BaseEntity {
    @Id
    private final Long id;

    @NotBlank
    private final String name;
   
    @PersistenceConstructor
    private Entity(Long id, String name, LocalDateTime createdAt, LocalDateTime updatedAt) {
        super(createdAt, updatedAt);
        this.id = id;
        this.name = name;
    }
}

// BaseEntity.java

@AllArgsConstructor
@NoArgsConstructor
@Getter
public abstract class BaseEntity {
    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;
}

BaseEntity를 사용하지 않는 경우

• @CreatedDate, @LastModifiedDate가 직접 필드에 들어옴
• 생성자의 접근자가 package-private
• id 필드에 Wither(@With)가 필요함

// Entity.java

@Builder
@AllArgsConstructor(access = AccessLevel.PACKAGE)
@Getter
@EqualsAndHashCode(of = "id")
public class Entity {
    @Id
    @With(AccessLevel.PACKAGE)
    private final Long id;

    @NotBlank
    private final String name;

    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;
}

생각해볼 것들

• @PersistenceConstructor를 작성하는 코드량 vs createdAt, updatedAt 필드를 작성하는 코드량
• @PersistenceConstructor vs 하나의 생성자 + Wither (링크를 참조하면 Spring Data JDBC는 후자를 선호)
  등등

의견 달아주시면 감사하겠습니다!

캐시를 충전하는 기능

RESTful api 에 대한 학습

이 부분은 모두가 알아야 하는 부분이지만, 조금 더 잘 아는 사람이 알려주는 방식이 좋아보임.

그래서 특정 한명 혹은 두명이 추가로 학습하고, 우리 프로젝트에서 이 부분은 rest 하지 않은데? 라고 제언할 수 있으면 좋을 것 같음.

회원 정보 수정하는 기능

라이더가 미션 수행을 인증하는 기능

레이스의 링크를 카톡으로 공유하는 기능

Race 카테고리 별로 Mission instruction을 생성하는 기능

#54 미션을 생성하는 기능을 진행하다 보니
Mission 필드의 MissionInstruction을 생성하는 기능이 필요 할 것 같습니다.

미션을 생성하는 기능

인증 사진 촬영 기능 구현

거짓 인증 신고를 등록하는 기능

캐시를 사용하는 기능

사용자가 레이스에 참여하면 선입금액을 사용하는 기능

라이더에게 미션을 수행하는 날에 미리 알림을 주는 기능

회원 가입하는 기능

Expo에서 Kakao 네이티브 모듈을 직접 사용하지 못함

문제

일반적으로 카카오 로그인에 대해 떠올리면

1. 로그인 버튼을 누르면
2. 카카오톡 어플로 이동해서 로그인을 완료하고
3. 다시 어플로 돌아오는 프로세스를 기대합니다.

이를 어플에서 가능하게 하려면 Kakao SDK를 다운받아서 사용해야하는데
Expo는 외부 네이티브 모듈을 지원하지 않기 때문에 위 프로세스가 불가능합니다. 링크 참고

해결책

1. 웹 뷰를 쓰는 방법이 있습니다.
   즉, 카카오 어플로 이동해서 로그인을 하는 것이 아니라 매번 웹 화면으로 이동해서 로그인을 하는 방법을 사용하면 해결은 가능합니다.
   일반적인 UX와 다르다는 단점이 있습니다.
2. 위 링크에서 나온 ExpoKit을 사용하는 방법이 있습니다. 그런데 ExpoKit으로 eject 하는 과정부터 ExpoKit으로 전환했을 때, 네이티브를 하나하나 만져야 할 가능성이 생기는 점이 단점입니다.

어떤 방법이 좋을지 의논해봐야할 것 같네요 😄
다른 해결 방법이 있다면 답글 달아주시면 감사하겠습니다 🙇

어도비 XD 및 제플린 사용유무 결정하기

• 무늬 : 어도비 XD 학습곡선 확인
• 나머지 : 제플린 사용방법 학습

Entity 이름 길이가 너무 깁니다

final MissionCertificationReport persist = missionCertificationReportRepository.save(
    missionCertificationReport);

우리 포맷팅 컨벤션 기준 라인 수를 넘어가서 save() 만 사용하도 두 줄이 됩니다.
네이밍을 다시 생각해볼 만한 것 같아요!

스키마에 외래 키 등록 시, 테스트가 어려워짐

create table if not exists RIDER
(
    ...
    foreign key (MEMBER_ID) references MEMBER (ID),
    foreign key (RACE_ID) references RACE (ID)
);

@DisplayName("Rider 엔티티가 저장되는지 확인")
@Test
void save() {
    Rider rider = Rider.builder()
        .memberId(AggregateReference.to(1L))
        .raceId(AggregateReference.to(1L))
        .build();

    Rider persisted = riderRepository.save(rider);

    assertThat(persisted.getId()).isNotNull();
}

위와 같이 테스트 코드 작성 시, 현재 DB에 Id가 1인 Member와 Race가 존재하지 않아서 데이터 무결성 예외가 발생합니다. 테스트 코드를 통과시키려면 각각 Id가 1인 Member와 Race 객체를 생성하고 DB에 저장한 뒤, 위 테스트를 다시 진행해야합니다.

Aggregate Root 간의 관계를 끊어서 테스트를 쉽게 한다.

Spring Data JDBC 소개 영상에서 나온 장점인만큼 스키마에 외래키를 등록하는 문제를 다시 한 번 생각해보면 좋을 것 같습니다 😄

레이스 상세정보 페이지 구현

예제 이슈

git branch 이름에 괄호 포함 불가

괄호 포함 시 에러

Embedded 엔티티 Validator 작동

.gitignore에 packager-info.json 추가

캐시를 출금하는 기능

인덱스 페이지 프론트 코딩

• 디디 무늬 시카 : 인덱스
• 범 카일 : 레이스 상세페이지

Git flow 정하기

UI 색상, 컨셉 결정하기

값 객체에 @Value 어노테이션 사용 여부 결정

레퍼런스 링크

해당 어노테이션이 제공하는 기능

• @getter
• @FieldDefaults(makeFinal=true, level=AccessLevel.PRIVATE) (기본 필드 접근제어자를 private final 로)
• @AllArgsConstructor
• @tostring
• @EqualsAndHashCode

값 객체에서 사용되는 모든 코드를 포함하고 있어 고려해볼만 하다고 판단됩니다.

레이스 조회 기능

사용하지 않는 브랜치는 삭제하기

프로젝트를 진행하다보면 팀원들끼리 fork 한 저장소를 remote에 등록하게 됩니다.
이후 로그를 보면 아래와 같이 나옵니다.

merge가 완료된 브랜치를 지우지 않으면 커밋 그래프에 모두 표시가 됩니다.
아래는 불필요한 브랜치를 삭제한 뒤의 커밋 그래프입니다.

훨씬 깔끔한 그래프가 나오는 것을 확인할 수 있습니다.

github 저장소의 브랜치를 지우는 명령어는 다음과 같습니다.
git push origin --delete [브랜치명]