(협업) 팀프로젝트 캠프 관리 프로그램 개인회고, 팀 KPT회고

18일차

개인 회고

• 깃허브 Pull request때 팀원들의 코드를 이해하기가 어려워 시간이 많이 걸렸다. 이후 팀원분들이 주석을 작성 해주셔서 코드를 이해하기가 쉬워져서 좋았다. 앞으로도 코드를 작성할때 주석을 많이 작성 해둬야겠다.
• 나눌 기능은 나누고 더욱 더 객체지향적으로 만들수있었을것 같은데 아직 실력이 많이 떨어지는것 같다. 자료구조도 그렇고 더 증진해야겠다.

팀 KPT회고

[Keep]

• 현중
  • 클래스 나누기, 템플릿 사용하기
• 성주
  • 자주 소통(코드리뷰, 베이스라인), 클래스 나누기
• 이건
  • 적극적 역할 가져가기, 튜터 도움 적게, 서로 물어본것
• 대현
  • 코딩도전 성장 good, 일단 돌아가면 된단 mind, 일단 되면 good
  • cowork - 타인이 만든 코드 수정시 양해 구하기(충돌방지), 정해진 시간, 주석처리
• 철희
  • 주석 많이 작성해주셔서 이해하기가 편했다.
  • PR올리면 코드 리뷰를 해줘서 부족한 면이나 다른사람의 의견을 알수 있어 좋았다.

[Problem]

• 현중
  • 객체지향 적 프로그래밍, UML다이어그램(패키지 나누기)
  • 자료남기기 (Merge 할때 사진찍기, 클래스 나눌때 사진찍기, Trouble 생겼을때 사진찍고 해결 후 사진찍기)
  • getter 메소드 메인대신 다른 곳에 만들기, 인터페이스 사용하기
• 성주
  • 인터페이스 아쉬움, 리팩토링 더 했으면
  • 자료구조를 체계적으로 게획 세우고 시작..
• 이건
  • 템플릿 있어서(설계과정 없이 코딩했던게 아쉬움)
  • 다형성 활용 low
• 대현
  • 객체지향(저수준 캡슐화)
  • 상속 인터페이스 다형성 부족
  • PR봐주실분(실시간) - 효율?
    ㄴ현중 : 좋았다
    ㄴ성주 : 좋았다
    ㄴ이건 : 좋다 무조건 (바로바로 봐주는거)
    ㄴ철희 : 좋았다
• 철희
  • 출력의 통일성이 없었던게 아쉽다
  • PR올렸는데 merge가 늦어진거?

[TRY]

• 현중
  • PR봐주실분(실시간) -검증 , 코드짜다 막혀있을때 '팀원'에게 공유하기
  • 자료 사진으로 남길 '구간'을 미리 정하고, 팀에 공유하기
    ex)코드짜다 막혔을 때, PR반려 당하고 feed back 받았을 때
  • PR 사용하기 - develop단에서 PR 계속 사용하기
  • PR 이후 merge 시간 정하기 ex)PR이후 5분이내 Approval해줍시다-!
    ㄴPR은 하루에 1번/1인
• 성주
  • 코딩 전 스케치(객체지향) -
  • 코드 완성할 때마다 - 튜터님께 검토받기
    (- 큰그림을 일단 스케치라도 하고 코딩시작 (객체지향적 구조포함)

• 계획짜고 튜터님꼐 검토/피드백 한 번 받기 -> 뭔가 우리가 생각하지 못했던 것들 을 봐주실 수 있을 것 같아요.)

• 이건
  • 객체지향적 보완
  • 설계(가장 어렵다) : 실력차이
• 대현
  • 객체지향 공부(5원칙, 구성요소), 프로젝트 경험 = 설계능력
  • 문제생기면 그때그때 얘기하기
• 철희
  • 처음에 다같이 그림을 그려나가며 어떻게 객체지향적으로 할지 회의
    (인터페이스 다형성 부족, 저수준 캡슐화, 다형성...등)
  • 트러블이나 다같이 활동할때 혹은 Q&A때 자료 찍어두거나 저장해두기
  • pr올리면 올스탑하고 코드리뷰하고 merge하기
    ㄴ피드백 : 올스탑은 힘들고 빠른시간내에가 좋겠다

[TRY & ACTION]

• 문제 생기면 바로바로 팀원과 공유하고 해결해내기
• 자료 사진으로 남길 '구간'을 미리 정하고, 팀에 공유하기
  ㄴPR은 하루에 1번/1인
• 자료구조용 다이어그램 + 클래스용 다이어그램
  (틀 용기 )
• 객체지향적으로 할지 회의
  (인터페이스 다형성 부족, 저수준 캡슐화, 다형성) - 내용 안건 꼭 넣기