일일회고 피드백(50")

• 테스트는 잘못되면 어떻게 되나?
  • 서버가 뻗을 땐 없었고 정상적인 접근이 아닐때 사후 수정을하였다. 서버에 관련된 실시간 대응을 한 적은 없었다.
  • 미래의 행동 계획에서는 테스트를 정리를 해놓고 기록을 해놓고 기록을 해놓는 습관을 들이자. 어떤 기능을 만들었을때 사이드 이펙트에 대해서 기록을 해놓고 체크리스트를 만들어가지고 체크해나가는 습관을 들이자. 예전회사에서는 업무 플로우가 있었는데 여기 회사는 규모가 작어서인지 좋게 말하면 자유롭고 나쁘게 말하면 아무것도 없고.
• 토이 프로젝트 근황은?
  • 서비스에서 새로 개발해야할 것들 큰 그림은 많은데 세부적인게 안 되어있어서 개발을 못하는 상황인데 손놓고만 있는게 그래서 내부적인 서비스에 기능개발해야겠다. 라는거였다 . 예를들어 묶은 판매 기능을 만드는데 어떻게 진행할지 모르는 상황에서 그냥 묶음 판매 기능을 만들었다. 늘 기획대로 안되어서 좀 어렵긴하다. 현재 회사에서 개발하는 언어가 노드인데 웹사이트를 노드로해보고 자바로 진행해서 비교해보고싶다. 
• 혹시 기능이 추상적인 기능이면 다른 개발자들과 공유 할 방법은 없나요?
  
  • 예전회사에서는 물어보면 코드는 봐봤냐? 코드에 다 있다. 라고 한 경험이 있어서  클라이언트쪽에서 요청이 온다. 이상한것 같다고 봐달라고했다. 그 로직도 말한거랑 동일한거여서 수정을하는데 그 API는 예전에 만들어놨다가 안쓰는 거였다. 자바는 스웨거가있고 편리하고 직관적인데 노드는 그런게 없나 찾아보려다가 못찾아봤다. 

• 요구사항 분석은 어떻게 놓치게 되었나?

  • (개발한 앱 관련 설명…)

  • 요구사항이 기획서에 매우 작게 기록되어 있었다. 확인이 어려웠음.

  • 기능을어떻게변경할것인지에대해서는아직도고민중에있다.

라이트닝 토크 (45")

주환석 - DB 시간 timezone 이슈

문혜영 - 

스터디 마무리 회고 (

...

15")

## 주환석

...

• KEEP 
  • 둘이서 이야기 하니까 집중되고 더 자세하게 이야기 할 수 있어서 좋았다.

...

• PROBLEM 
  • 둘밖에 없다보니 다양한 의견 공유가 안되는게 아쉬웠다. 둘이서도 시간 맞추기가 조금어려운듯?
• TRY 

...

• • 일일회고, 주간회고시간이부족한느낌미리질문을공유해서해당하는사람이답변을준비를사전에해오기?

  - 혜영 : 알아서 당일 스터디 점심시간까지 질문지 슬랙에 올려 놓기. 답변할 시간이 필요.

## 문혜영

• Keep :
  • 라이트닝톡 시간이 충분히 주워지니 찾아보기 좋았고 공유하는게 많아져서 좋았다.
  • 시간분배가 초과했지만 그럼에도 깊게 질문할 수 있어서 좋았고
Problem
•  Problem :
  • 주간회고를 안쓰고 있다. 이것 또한 하자고 격려가 필요한것인가 아니면 꼭 필요한것인가 의문이 든다.
  • 사람이 적으니 피드백이 적어서 아쉬웠다.
Try
•  Try :
  • 4명이서 진행하면 분명히 시간이 계속 초과할텐데 시간분배시 타이머 기능 이용해서 타이머 시간이 알림이 나면 저절로 멈추는 기능이 필요 할거같다. 2명이서 하는데도 얘기할 거리가 많다.
  • 실시간 기록하는 구글 공유 문서 필요.