8월 2일 금요일

결론

데이터의 타입과 데이터를 관리하는 구조를 변경했다.

본문

우선 데이터 클래스들을 조금 급하게 만들긴 했었다. 내가 빨리 만들어줘야 팀원들이 빠르게 작업을 시작할 수 있을 것 같아서, 우선 과제를 완전히 이해하기도 전에, 필요할만한 기능이나 클래스를 적당히 나누고 만들었다. 팀 과제 2일차가 되고, 과제에 대한 이해도가 높아지면서, 지금까지 만들었던 데이터 클래스들의 구조에 불필요한 요소가 너무 많다고 느껴졌다. 기존에 만든 구조는, StudentData 클래스가 ScoreData와 SubjectData 클래스를 종속하는 관계였고, 각각의 클래스에서 이름과 연관된 기능이나 변수들을 관리하고 있었다. 근데 이제 와서 살펴보니, 굳이 나눌 필요성이 없었다. 학생 객체가 생성되지 않는 이상, 과목이나 점수 클래스가 단독으로 사용될 일이 전혀 없었다. 논리적으로도 학생이 있어야 점수가 있으니, 점수와 학생 클래스를 나눌 것이 아니라, 점수가 학생에 존재하면 되는 것이었다. 그래서 점수 클래스를 삭제하고, 학생 클래스에 전부 옮길 계획을 가지게 됐다. 다행히 팀원들도 크게 수정할 부분은 없다고 하셨고, 제 의견에 동의해주셔서 학생 클래스에 점수 관련 필드와 메서드를 넣기로 했다. 이 외에도 팀원들에게 필요할 것 같은 테스트로 사용하기 편한 메서드들을 만들기도 했다.

 

 

 

 

 

바뀐 학생 클래스의 구조에서, 대부분의 필드값과 성적 안에 들어가는 변수들을 전부 String 타입으로 받고 있었다. 왜냐하면 배열에서는 여러 타입을 혼용해서 사용할 수가 없었고, (자세히는 기억 안 나는데)조회 기능 부분에서 과목 타입과 과목 이름으로 조회하는 기능이 있었다. 그래서 팀원들이 만들고 있거나 만들어낸 기능들이 있기 때문에, 맞춰서 다른 변수들도 String으로 받는 것이 추가 작업할 일이 없을 것 같아서 String으로 통일하기로 팀원들과 정했다. 근데 혼자 생각해보니, 이럴 경우에는 계속 값을 변환 시키고 다시 넣을 때도 변환 시켜서 넣어주고 하는 반복적인 작업이 계속해서 발생되고, 모든 변수를 String으로 저장하는 것이 괜찮은 것인가에 대해서 고민하게 되었다. 이 부분은 빠르게 결단을 내리지 않으면, 더 이상 걷잡을 수 없을 것 같아서, 최대한 괜찮은 방법을 모색하게 되었다. 그 결과 ! 몇 가지 약속을 만들어내고, 전부 int 타입으로 관리할 수 있을 것 같았다. 예를 들면, A등급은 1, B등급은 2 이런 식으로 약속을 하고, 필수 과목은 0 선택은 1 등등 이런 식으로 하면, 입력 받고 넣을 때나, 조회 정렬 등등 데이터를 넣고 빼고 정렬하기 위해서 가공할 필요가 없어지고, 데이터도 전부 int로 관리하는 것이 꽤나 괜찮은 생각이라고 느껴졌다. 그래서 생각이 정리된 순간 팀원들과 바로 회의를 진행했고, 팀원분들이 코드를 수정해야하는 부분은 발생했지만, 추후를 생각해봤을 때, int로 통일해서 가는 것이 좋은 방법이라는 결론이 내려져서, 바로 타입을 뜯어 고치는 작업을 진행했다. 금요일 저녁에 갑자기 뜯어 고치게 돼서 팀원들께는 죄송했지만, 그래도 괜찮은 방법을 찾아낸 것 같아서 뿌듯했다. 근데 확실히 데이터쪽은 섬세하고 치밀하게 구상을 하고 작업을 해야 하는 업무라고 크게 느끼게 되었다. 데이터에서 하나 수정하면, 모두가 수정을 해야하는 경우도 발생해서, 수정을 염두할 부분들을 전부 리스트로 만들어서, 자주 회의하는 방식으로 진행했다. 이번에는 팀원들이 의사소통을 잘 해주셔서 팀원들 능력으로 이겨냈지만, 애초에 섬세하고 치밀하게 데이터를 관리할 구조를 만드는 것이 정말 중요하다고 느낀다.