KPT회고(수강생 관리 프로그램)

Keep - 현재 만족하고 있는 부분

👍 회의를 통한 프로젝트 기획

• 개인 개발은 회의를 통한 기획 이라는 단계가 존재하지 않는다. 스스로 요구사항을 분석하고, 그를 토대로 개발을 진행하기 때문에 자기 주관적인 생각만을 이용해서 작업을 진행한다. 하지만 이런 특성이 팀 개발에서도 이어질 수 있다. 팀원들이 매우 소극적인 경우 팀장의 주도하에 개발을 진행하면 팀장의 생각대로만 개발이 행해지는 경우도 있는데, 본 프로젝트의 경우 모두가 의견을 제시해서 각자의 의견중 타당한 부분을 채택해 개발을 진행했다. 이 부분이 팀 프로젝트의 장점을 살린거 같아서 만족스럽다. 

👍 정기적 회의로 상황 공유 및 코드리뷰

• 업무를 분담하고 기능을 구현할때 까지 개발만 진행하면, 같은 객체를 이용해서 다른 기능을 구현하는 사람과 메소드 명, 리턴 타입 등등의 차이가 발생할 위험이 있다. 본 프로젝트의 조의 경우 잦은 회의를 통해 공동으로 사용되는 객체의 타입, 이름등을 계속 공유하면서 통일시켜 개발 과정이 수월할 수 있었다. 

👍 깃헙 커밋을 통해 업데이트 된 부분 표기

• 팀 프로젝트의 경우 각자의 작업을 대략적으로 인지하고 개인 작업을 진행한다. 이를 위해서 보게 되는것이 commit message인데, message의 수준에 따라 추가적인 질문이 생길수도, 아닐수도 있다. 본 프로젝트의 경우 message를 완벽하게 작성하진 않았지만, 대략적으로 해당 push 버전이 어떤 method를 구현했고, 수정한지 파악이 가능하도록 작성해서 개발 과정을 더욱 수월하게 해주었다. 

👍 코드 작성만 하는게 아닌 다이어그램, flow 차트, 노션 작성 등을 이용해서 개발 과정을 기록함

• 코드를 작성하다 보면 구조에 혼란이 오고, 어느 부분 까지 된건지, 다른 팀원은 뭘 하는지 파악하기 힘든 경우가 발생한다. 이를 방지하기 위해서 본 프로젝트에선 다이어그램, 노션 작성 등을 이용해서 각자의 진행사항을 공유했고, 이를 통해서 개발 과정과, 계획을 전부 파악할 수 있었다. 

Problem & Try- 불편하게 느끼는 부분과 Problem에 대한 해결책

⚠️ IDE 문제 발생시 도움을 줄 수 있는 지식이 없음

• 작성한 코드에 대한 에러는 내용에 맞게 수정을 거치면 되지만 IDE와 관련된 문제는 해결하기가 쉽지 않았다. 각자 개발하고 있는 로컬 환경도 모두 다르기 때문에 팀원들끼리 서로 도움을 주는 것에도 어려움을 겪었다.
• Try
  • 가장 중요한건 설정파일은 최대한 gitignore에 등록을 하는것이며, 개인 로컬에서 발생하는 에러는 따로 작성을 해서 정리를 해둬야 한다. 

⚠️ 프로젝트 초기 Git Branch를 메인으로 다 merge해서 최종 백업을 진행하지 못했음

• 프로젝트 초기 각자 맡은 부분을 Branch 화 하여 커밋을 하였는데, Github pull request & merge가 익숙하지 않아 main branch에 모두 merge를 해버렸다.
• Try
  • 3번째 구조로 작업을 시작할때 중간 main인 dev branch를 생성해서 dev에 PR을 하고, 작동 확인을 하는등 배포용인 main을 사용하지 않은 방식을 사용했다.
  • 항상 main은 최종만 PR한다는 생각을 지녀야한다. 

⚠️ Github 사용 미숙으로 시간을 낭비함

• GitHub를 사용한 개발이 익숙치 않아 push시 충돌이 발생한걸 해결하지 못하거나, 커밋을 선행하지 않아 pull을 하지 못하는 오류등으로 시간을 빼앗긴 경우가 종종 있었다.
• Try
  • 사실 이런류의 오류는 접하는 횟수가 늘면서 익숙해지는 것이기 때문에 당장 완벽하게 하지 못하지만, 자주 발생하는 오류는 정리를 하고, 오류 발생시 마다 해당 문서를 보면서 익숙해져야 한다. 

 

개인회고

이번 프로젝트를 진행하면서 저번과 다르게 브렌치를 나누어서 협업을 진행하였다. 그러기에 브렌치를 따로 생성하는 git branch명령어와 다른 팀원의 브렌치를 불러와야 하는 상황이 있을땐 git switch를 사용하고, 원격으로 다시 연결할때 git remote, 다시 origin하고 동기화가 필요할때 git fetch를 이용하는 방법을 터득하는 계기가 되었다. 나는 해당 과제에서 updateScore부분 점수 수정부분을 맡았지만 아직 자바에 대해 익숙하지 않은 수준이기에 빠른 일처리는 불가능 하였다. 더구나 나 제외하고 다른 팀원들은 전공자 분들이라 내가 하나의 일처리를 끝내면 나머지 팀원들은 3개를 처리할정도로 일처리가 정말로 빨랐다. 하지만 컴퓨터학부 4년을 공부하니 나보다 빠른건 당연하기에 내가 일처리가 늦는건 미안한 마음은 있지만 그들에게 많은걸 배우는 심정으로 프로젝트에 임했다. 어떤부분이든 그들이 더 아는게 많기 때문이다. 초반에 프로젝트 진행할때 다이어그램은 어떻게 작성하는지, 회의는 어떻게 진행하는지, 그들의 코드 스타일, 주석 작성 스타일을 배우게 되었다. 

 

배운점

• 메서드명, 필드명 통일
• 다이어그램을 통해 해당 프로젝트의 진행상황 파악
• 회의를 통해 각자가 맡을 기능 분배
• git checkout, fetch, remote, branch 학습
• List보다 HashMap이 더 나은점
• 기능에 맞게 패키지 나누고 클래스 나누는 법