💡 기대 결과

• 유저의 일기를 "안전하게" 보관한다.
• 유저의 정보, 비밀번호 등을 관리한다.

🚨 주의 및 전달 사항

• 개발자 본인도 유저의 정보, 일기 ( 또는 미래에 임시 저장 기능이 생기더라도 ) 등을 알 수 없게 한다.
• 각 항목 별로 우선 적용을 한 다음, 각각에 대해 추가적인 개발이 필요하면 ISSUE를 생성한다.

✅ 작업 내용 겸 체크리스트

• refresh token
• helmet
• cors
• https

💡 기대 결과

• 유저가 사용 가능하다고 느낄 수 있는 수준의 CSS여야 한다.
• 굉장히 모호한 부분...

🚨 주의 및 전달 사항

• 코멘트는 대댓글을 달 수 있어야 한다.
• 코멘트는, 작성자가 누군지, 작성 시간도 나와야 한다.
• 코멘트의 순서에 유의한다.

✅ 작업 내용 겸 체크리스트

• 다이어리 페이지의 CSS 작업
• 다이어리 디테일 모달의 CSS 작업
• 다이어리 디테일 모달의 코멘트 영역 추가
• 다이어리 디테일 모달의 코멘트에 작성자, 작성시간, 코멘트 내용 등을 표시
• 대댓글에 대하여, 접기 기능 제공 ( toggle 기능 )

API 테스트에 대해서는, 각 컨트롤러, 서비스의 목적에 맞는 설계까지만 작성한다.
예컨대, 서비스에서 Repository를 검증하려고 하지 않고, MockRepository를 사용하는 것을 의미한다.

더 풀어서 설명하자면, 그룹을 생성할 때 비밀번호가 hash가 되어서 추가되는지, 서비스의 로직만 확인하고,
DB에 저장이 됐는지, 서버 외부 로직을 검증하지 말라는 의미이다.
컨트롤러에서는 다시, 서비스가 제대로 된 응답을 반환했을 거란 가정 하에서만 다룬다.

테스트를 하려고 했던 것은 좋지만, 무분별한 테스트 작성은 생산성을 떨어뜨릴 뿐이다.

Originally posted by @kakasoo in #1 (comment)

리마인드 차원에서, 별도의 이슈로 작성한다.

나만 볼 수 있도록 하는 그룹 "내게 쓰기"를 일반적인 다른 그룹과 구별하는 방법이 있는가?
현재 DB로는 없다, 값을 다르게 넣는 방법을 쓰면 부분적으로는 가능할지 모르지만 모든 데이터를 꺼내서 서버 측에서 filter를 해야 하기 때문에 부담이 크다.
또한 특정 유저가 그룹의 이름에 그 값을 넣는 경우,
예컨대 "내게 쓰기" 그룹을 특정할 목적으로 "나만보기" 라는 이름의 그룹을 생성하게 했을 때, 유저가 해당 텍스트 이름으로 그룹을 만든 경우 구별할 방법이 사라진다.
따라서 테이블이나 칼럼 자체를 나눠야 할 것 같은데, 아무래도 칼럼이 더 효율적인 방법이다.

Originally posted by @kakasoo in #1 (comment)

💡 기대 결과

• 유저가 메인 페이지에서 자신의 일기장 목록을 보는 데까지 가능하게 한다.

🚨 주의 및 전달 사항

• 페이지 디자인은 다른 홈페이지를 참고한 다음에 개발로 이어간다.
• API에 문제가 생긴 경우, fix commit은 각각의 issue에 등록한다.
• 일기들이 보이는 데까지만 작성하고,
• 일기들을 정렬하는 등의 부가적인 기능, 상세 페이지 조회, 일기 작성 등은 새 ISSUE에서 작업한다.

✅ 작업 내용 겸 체크리스트

• 메인 페이지 view 작업
• 로그인 모달 view 작업
• 로그인 API 연동
• 로그인 시, 로그인 여부를 알 수 있도록 메인 페이지에서 변화를 줄 것
• 로그인 시, 자신의 일기들이 보이도록 함

💡 기대 결과

• 유저가 자신의 정보를 수정하고, 그룹 추가, 가입할 수 있는 페이지를 제공한다.
• 유저가 다른 유저를 그룹에 초대할 수 있는 기능을 제공한다.

🚨 주의 및 전달 사항

• 사용성을 고려한다.
• 일기 작성을 고취(?)할 수 있도록 열심히 만든다!

✅ 작업 내용 겸 체크리스트

영역을 분리하여, 만든다.

• user의 information이 제공되도록 하는 section
• user의 history ( github의 contribution을 참고하여 ) 만든다.
• user의 그룹, 친구들을 볼 수 있는 페이지, link ( 또는 hash 값 ) 을 통해 가입이 가능하도록 한다.
  • 이를 위해 새로운 API를 추가해야 한다.
  • 이 API는 단순히 hash 한 데이터를, 상대방에게 전달할 수 있도록만 하면 된다. 전달은 유저가 다른 메신저를 쓰게끔 한다.

💡 기대 결과

• 스켈레톤 형식으로 만든 레이아웃에 모든 API를 연동한다.

🚨 주의 및 전달 사항

• 이 이슈에 한하여 별도의 커밋 컨벤션을 추가한다.
• feat : API_GROUPS, 삭제 기능을 추가 #number 형태로 작성한다.
• API 단위로 체크리스트 아래 내용 추가하여, 체크를 해둔다.
• 각 API를 사용자 시점에서 생각하고, 실제 서비스되고 있는 타 사의 API는 어떤 모습인지 고민한다.

✅ 작업 내용 겸 체크리스트

• USERS
• GROUPS
  • 일기 작성 시 유저가 가입한 그룹을 선택할 수 있도록 조회
• DIARIES
  • 일기 삭제
• COMMENTS

💡 기대 결과

• 사용자가 자신의 일기를 불러오고, 상세 페이지를 조회할 수 있도록 한다.

🚨 주의 및 전달 사항

• 일기의 INDEX 값을 반드시 불러온다.

✅ 작업 내용 겸 체크리스트

• 일기 조회
• 상세 조회
• 일기 정렬
  • 그룹 별 정렬
  • 날짜 별 정렬
    • 레이아웃은 나중에 변할 수 있으니 공들이지 않는다.
• 일기 작성

제목과 동일하다.
휴대폰 어플리케이션에서 제공하는 것처럼, 웹 사이트에서도 그러한 기능을 제공하면 좋을 것 같다.

프론트 개발자를 구하면 좋을 것 같은데, 안 되면 직접 개발하는 수 밖에.

💡 기대 결과

• 다이어리에 대한 CRUD가 가능해진다.

🚨 주의 및 전달 사항

• ReadAll의 경우에는 API 속도를 느려지게 할 수 있기 때문에 그 부분을 좀 더 고민해서 작성한다.
• 가령, 메인 페이지에 띄우는 일기의 경우, 일부 내용만 보여주고 나머지는 상세 페이지에서 보여줄 거라고 한다면,
• 전체 일기 데이터를 가져올 필요가 있을까?
• 물론 아닐 수도 있다.

✅ 작업 내용 겸 체크리스트

• Create Diary ( 일기 작성 )
• ReadAll ( 메인 페이지에 띄울 전체 일기 조회 )
• ReadOne ( 상세 페이지에 띄울 한 일기, 또는 이전, 다음 일기를 포함한 세 가지 일기 조회 )
  • 이 부분은 프론트에서 고민할 부분일 수도 있다.
• Update ( 일기 수정 )
• Delete ( 일기 삭제 )
• Swagger 문서화

카카오톡을 database와 연관 지어서 생각을 해보자.
유저가 회원가입하고, 방에 들어가는 순간, 어느 방에 어떤 유저가 있는지를 저장할 필요가 있다.
이것을 redis로 관리할 수도 있겠지만, 일단은 캐시가 아니라 데이터베이스에 모두 저장한다고 해보자.

그러면 데이터베이스에서 유저와 room은 n:m의 관계를 가지게 될 것이다.
그러면 유저와 room은 userRooms와 같이 ( 이름은 반드시 저럴 필요가 없다. ) 관계를 나타낼 별도 테이블이 필요하다.
여기까지 나타냈을 때, 지금 내가 궁금한 것은,
유저가 회원가입을 할 때, 유저가 내게 보내기 기능이 있는 한, 각 유저는 '내게 쓰기' 방을 생성하고 가입해야 하는가?
만약 그렇다고 한다면, room과 userRooms에는 user 수 만큼의 데이터가 추가된다.
회원 가입과 동시에 데이터가 3개씩 추가되는 꼴이다.

비효율적인 방식인가?

지금 이것을 고민하는 이유는, 내가 일기를 작성하는 로직을 개발할 때에도, 나만 보기를 만들고 있기 때문이다.
공개 범위를 나까지만으로 설정하는 것을 의미한다.

Originally posted by @kakasoo in #1 (comment)

리마인드 차원에서, 별도의 이슈로 작성한다.

그룹 카드를 만들 때, 클릭된 횟수, 그룹원의 수, 그룹 소개, 그룹의 매니저 정도는 소개해도 좋을 것 같다.
칼럼을 추가하는 대신 매니저들을 등록할 새로운 테이블을 만들자.
그룹의 매니저들, 칼럼은 USER_ID, GROUP_ID, OWNER ( => boolean )만 가진다.
그룹 클릭 횟수와, 그룹 소개는 각기 따로 테이블을 두자.
클릭 횟수는 특히나 빈번할 수 있어서...

Originally posted by @kakasoo in #12 (comment)

💡 기대 결과

• 프론트 페이지를 구성한다.

🚨 주의 및 전달 사항

• 재사용성을 고려한다.
• 카드를 만들 때와 같이, head, body를 구분해보고, util로 뺄 수 있는 한 최대한 뺀다.

✅ 작업 내용 겸 체크리스트

• 별도로 추가하지 않음.

💡 기대 결과

• 메인 페이지의 UI가 실 사용 가능하게끔 한다.
• 모든 API를 연동함을 의미.

🚨 주의 및 전달 사항

• 필요할 시 칼럼을 추가한다.
• 불가능할 시에는 별도의 테이블을 생성하여 작업한다.
• 모든 작업이 끝날 시에는 API 문서화를 재실시한다.

✅ 작업 내용 겸 체크리스트

• 다이어리 카드의 UI를 수정한다.
• 일기 작성 시 그룹을 지정할 수 있게 한다.
• 정렬 외에, 카테고리화하는 기능을 추가한다. ( A 그룹만 보기, 체크하는 방식으로 이루어지게 )
• typeorm을 재설정하고, 쿼리 대신에 orm을 사용하도록 수정한다.

코멘트가 추가되면 이메일을 이용해서 알림을 줄 수 있게 만들면 어떨까?

Originally posted by @kakasoo in #16 (comment)

💡 기대 결과

• Group에 대한 CRUD가 가능해진다.

🚨 주의 및 전달 사항

• User 생성 로직을 염두해두고 개발한다.
• Create의 경우에는 모두에게, 내게 쓰기를 별도의 API 로 분리해둔다.

✅ 작업 내용 겸 체크리스트

• Create some group
• Create "everybody"
• Create "myself"
• Read
• Update
• Delete
• Swagger 문서화
• API에 대한 테스트 코드 작성

💡 기대 결과

• 회원가입, 그룹 가입, 일기 작성 후 공개 범위 설정이 가능해진다.

🚨 주의 및 전달 사항

• 능률을 측정하기 위해 이슈 대신에, 하루 치 할당량, 목표를 정하고 일해본다.

✅ 작업 내용 겸 체크리스트

• 회원 가입 폼 만들기
• 인트로 페이지에서 그룹 소개, 그룹 가입하기
  • 나중에는 가입 요청, 승인 기능을 만들어야 한다.
• 일기 작성 후 공개 범위를 설정할 수 있게 폼을 수정한다.
• 다른 유저를 생성하여, 일기를 확인한다.
• 일기 닫기 버튼 만들기
  • 가능하면, UX 요소를 고려하여 모달 창 바깥을 클릭해도 닫히게 하자.

💡 기대 결과

• User에 대한 CRUD가 가능해진다.

🚨 주의 및 전달 사항

• 그룹과의 트랜잭션을 고민하며 작성한다.

✅ 작업 내용 겸 체크리스트

• Sign in ( 로그인 )
• Sign up ( 회원 가입 ), Create User
• ReadOne
• Update
• Delete
• Swagger 문서화

일기 쓰기 어려운 사람들을 위해 질문을 던져주는 기능을 만들자.

Originally posted by @kakasoo in #9 (comment)