결론
오늘부터 수요일까지 할 일 정리(팀, 과제)
과제 : 팀원들에게 필요한 수정 사항 반영
기용 튜터님 코드 피드백 해주신 부분 공부와 생각
오늘 겪은 문제
나는 아메바다. 나는 원시인이다. 우끼끼 우끼.
본문
우선, 주말 동안 과제에 더 손 댈 부분이 없는지 생각을 좀 해봤다. 금요일 저녁에 갑자기 데이터 형태를 통일하자는 명분으로 좀 큰 규모의 수정을 감행해서, 아무래도 허술한 부분이나 생각하지 못했던 부분이 있을 것이라 생각했다. 생각해본 결과, 다행히 논리적으로는 큰 결함은 없는 것 같다. 오늘 아침 팀 회의 결과, 학생의 성적표에서 굳이 받지 않아도 괜찮을 매개 변수를 받고 있는 것과 자잘한 수정 사항 정도만 반영하고, 화~수 회의 때마다 팀원들이 구현한 기능들 보면서, 필요하면 수정이나 추가하면서 진행하기로 결론을 내렸다.
public void subjectDetailsInput(int subjectId,int subjectType, int score,int round){
subjectDetails = new int[5];
//초기화 안해주면 고장남!!
this.subjectDetails[0] = subjectId;
this.subjectDetails[1] = subjectType;
this.subjectDetails[2] = score;
//점수 범위0~100
this.subjectDetails[3] = round;
//회차 범위 1~10
subjectList.add(subjectDetails);
}
이 메서드에서 원래는 매개변수도 5개를 받았고, 배열의 크기도 5였다. 5번째 값은 과목 등급이었는데, 성적표에 굳이 등급까지 넣고 있을 필요가 없다고 팀원들과 결론을 내렸다. 그래서 등급을 받는 배열의 크기도 줄이고, 매개변수도 안 받게 수정한 것이다.
이번 주 팀 계획
- 과제 마감은 수요일 오전까지.
- 자잘한 수정 사항, 주석 추가 또는 삭제, 필요 시에 추가 기능 구현 정도는 화요일 오전부터 논의하면서 진행.
- 팀 노션에 ERD, 테스트 케이스, 분담 업무 등 작성은 화요일에 시작해서 수요일까지
- 화요일 기능 구현된 상황 봐서, 코드 리뷰
- 수요일 오전부터는 완성된 기능 테스트 해보면서, 발표 준비
- 기용 튜터님의 조언 : 팀 머지 전략 고민. 어떤 순서로 머지해야 충돌을 최대한 피할 수 있는지 팀과 논의
기용님 튜터님 코드 피드백
성적표 : RDB 관점으로 생각해 보기.
내 코드가 틀린 것은 아닌데, 다른 관점에서 생각해 보면 재미도 있고 유익할 것이라는 의미로 말씀하신 것 같다.
결론부터 말하자면, 난 아메바였다. 이 2차원 배열의 성적표는, 과제의 헛점을 찌르면서, 좋은 효율인지는 모르겠으나 괜찮게 논리적인 데이터 관리 방법이라 생각했었다.. 내 이해가 제대로 된 것인지는 모르겠지만, 그냥 성적표라는 객체를 잔뜩 만들고, 그 안에 학생ID만 같이 넣어주면, 오히려 관리도 편하고 책임도 나눌 수 있어서, 이 RDB 관점으로 만드는 방법이 훨씬 훨씬 효율적이고 논리적이고 멋있고 간편하고 직관적이고 나는 원시인이다. 학생 클래스 안에서 모든 것을 해결하고 싶었다. 그게 직관적이고 데이터 관리도 편하고 팀원들도 사용하기 좋을 것이라고 착각을 해버렸다. 그래도 배웠으니 나는 발전했다. 팀원들은 고통 받았지만.. 팀원들도 고통 속에서 발전을 했을 것이다..! 죄송합니다. 다음에는 생각을 두 번은 더 많이 하겠습니다.
어쨌든 객체를 많이 생성하는 것이 나는 효율이 나쁘다고 생각했다. 그래서 객체를 만드는 것을 최소한으로 하면서, 데이터를 일을 여러 번 하지 않고 관리하는 것이 좋은 것이라고 생각을 해버렸다. 객체가 많으면 관리나 검색, 추가, 수정 등등 아무튼 불편할 것이라고 생각했는데, 아니었다. 어쩌면 오히려 모든 측면에서 편할 수도 있다고 생각이 된다. 데이터베이스를 아직 잘 써보질 않아서 이해력이 많이 딸렸던 것 같다. 하지만 약간의 데이터베이스에 대한 느낌과 어떤 식으로 데이터를 관리하고, 자바에서도 객체 단위로 만들어서 관리하는 것이 더 편할 것 같다는 배움을 얻었다. 화이팅..!
