5.6 회의록
- Dominant language
- JavaScript
- Stars
- 4
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
# ISSUE
* Group: `client`, `server`, `sr`
* Type: `bug`, `feature`, `delete`
* Detail:
# TODO
- [x] KPT 회고제출 오늘 9시반까지
- [x] 특이사항 공유
- 깃허브 소셜로그인 구현 완료: 다만 마이페이지에서 깃허브는 비번변경, 이메일 안보이게. (네이버의 경우)!!, 소셜 성공모달은 보류
- 백엔드: 코드가 좀 더러워지는 것 같아서 파일 구조 조금씩 정리해보면 좋겠다. (데이터 내려주는 코드도.):
- 반응형 UI
- [x] 당일 할 작업 공유(express validator, 비번분실 자료조사,마이페이지 로그인타입정보 내려주기, 반응형 ++)
- [x] 스몰톡 때 나누고 싶은 이야기: 11:00-11:45
- 현재 우리 팀 진도는? 베어미니멈 완료. 검색, 정렬기능 추가 & 소셜로그인 기능구현 &반응형 시작
- 앞으로의 계획은?? 반응형 마무리, 비번 분실, 무한스크롤(페이지네이션), 관리자 페이지 등
- 궁금한점??
수현) 갠적으로는 리팩토링 부분이 신경쓰인다. 기능을 더 붙이는거에 신경쓰다보니 리팩토링이 뒷전으로 되는데,
기능, 리팩토링 중요도를 비중으로 따지자면 어떻게 봐야할까요..회사에선 뭘 더 중요하게 볼까요?
(중간에 리팩토링 하고 기능 붙여나가는게 나을수도?)
그리고 많으면 11일, 적으면 일주일 정도 남긴 했는데 이 기간에는 기능 몇개 정도 더 붙이고, (어떤 기능을 좀 더 우선으로?)
버그 수정하는 기간은 어느 정도로 잡는게 스케줄상 괜찮을까요?
- 체력적, 정신적으로 힘든부분??
수현) 그래도 백엔드 적응되서 재밌고, 저번주보단 스트레스는 덜 받는것 같다.
- [x] 스몰톡 이후 잠깐 (스케줄 잠시논의)
- [x] 5시 회의안건
- 다음 주 버그 수정하고 테스트하는 기간 하루 이틀 정도 잡는거 괜찮을지? (필요하다면 리팩토링도?)
- 다음 주 adv: 네이버 로그인, 비번분실, 무한스크롤, 관리자페이지, 채팅 모든 걸 다 할수 없을수도 있음
- 구현할 기능 개수 정하기(3개정도가 적당), 정말 꼭 해야될것만 고르고 작업순서정하기
- 오늘 저녁-주말 중엔 자료조사하고, 이를 바탕으로 와이어프레임이나, api, DB 설계, 로직(필요시 궁금한점은 오늘저녁에디코)
- 고려사항:
- 작업 기간
- 와이어프레임, 디자인
- api 논의
- DB 테이블
- 주말간에 작업계획 공유:
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.