[TIL] 중간 발표회 및 피드백

오늘 한 것

 

- 중간 발표회 : 다른 팀의 발표 내용이 매우 흥미로웠다. 다들 3주간 열심히 하신 것이 보였다!

- 피드백 및 개선 사항 정리

- 자신 & 팀원 다면평가

- 약간의 html&css

 

 

 

 

 

 

 

돌아본 지난 3주간의 나

-> wil에 정리했지만 또 다면평가는 다르니까 호호

매일의 목표를 설정하고 달성하기 위해 3주간 꾸준히 노력했다.
맡은 기능 및 추가 기능을 끝까지 완수하기 위해 책임을 지고 시간 내에 기능을 완성했다

 

머신러닝을 배울때 느꼈던 어떤 매너리즘 같은 것은 새로운 기획을 작성하고

코드를 구현하는 사이에 고맙게도 열정과 대체되어 사라졌다!

 

 

특히 공동구매 게시글을 기획하고, 기획한 것을 바탕으로 view외에도

models.py, serializers.py에 여러 함수와 로직을 구현해보며 실력이 향상된 것 같다.

 

 어떤 방향으로 함수를 구현할지 생각하고 주석으로 작성한 후 필요한 점검 로직을 추가하거나
불필요한 것을 삭제하는 등의 코드를 정리하며 기능을 완성하였고,
테스팅하는 것도 비교적 여러 부분을 고려할 수 있게 된 것 같다.

 

 

 그리고 코드 리팩토링에서는 팀원들의 도움이 커서 감사함을 느꼈다.
아직 어떤 부분에서의 상세한 점검이 필요한지에 대한 감이 부족했는데,

나는 항상 코드를 과하게 작성하는 편이어서^^; 불필요하거나 이중으로 점검하는 코드가 들어가는 경우가 있었다.
팀원분들이 필요없는 코드에 대해 의견을 제시하고 수정 및 삭제하는 과정을 도와주셔서 잘 해결해나갈 수 있었다.

 

소통에 있어서 약간의 의견 마찰이 있었는데,
2주차 말이었고 아무래도 긴 프로젝트에 피로가 쌓이다보니 대화할 때 약간 가시가 섰던 것 같다.
자세한 대화 후에는 서로의 입장을 이해하고 조금 더 존중하며 대화할 수 있어서 다행이었다. 

피로와 조급함에 조금 더 너그럽지 못했던 스스로에게 반성을 하며,
앞으로는 느긋한 마음으로 필요한 내용을 명확히 알리는 대화를 하도록 나도 연습해야겠다:) 

 

 

 

중간 발표회 피드백 정리 및 개선 사항

 

→ 피드백

• AI 채팅 기능 개선
  • 단순하게 1번 실패하면 잠시 후 다시 요청해주세요 라는 alert이 뜨고있지만 에러가 안 나도록 하는 것이 베스트!
  • 이런 경우에는 retry count를 지정하여 ‘ex:3’ 프론트에서 백에 반복해서 요청하는 방식도 생각해보기. 지정한 횟수만큼 반복 요청을 받게될 것임! 사용자가 에러메세지 적게 볼 수 있도록 수정하면 좋겠음
• View에서의 베이스 카테고리 지정
  • db에서 따로 관리하도록 하는 것이 좋을 것 같음 → 분량이 많아지면 처리가 힘들어지므로 카테고리는 db에서 관리하도록 하는 것이 좋다
• 테스트/레거시 코드 & 선언 후 사용되지 않는 코드 삭제하기
• if문 작성시 true/false가 아닌 if a/if not b와 같은 형태가 더 장고스럽고 깔끔하다
• 공구 마감시 실제 마감에 대한 확인이 필요하다 (현재 print문)
• 동일한 클래스 네임이 여러번 중복되고 있음
• 리드미 작성하기
  
  
  

→ 개선 방향

1. 튜터님이 말씀해주신 retry count를 적용하되 어느정도의 시간이 소모될 경우 다시 요청하도록 하기. gpt가 요청을 받아오는 최대 시간을 확인 한 후 적용필요
2. View에서 create_user의 프로필 object 생성처럼 create_community 함수 생성하여 처리하기
3. 전체적인 코드 리팩토링 필요
4. 공구에서의 if문인듯. 수정 필요
5. 인원제한이 있어 모집 인원이 채워질 시 더이상 모집은 못 받게되어있고, 글 자체가 종료되는 필드인 is_ended = True는 close_at을 기준으로 크론이 5분마다 체크하도록 되어있음🥲
6. 클래스 네임 확인 후 변경하기!
7. Readme 작성하자

 

 

어떻게 개선할지에 대해 함께 고민하는 것도 즐거운 협업의 과정!