개발 기간 : 2024-08-01 ~ 2024-08-07
2024-08-01
오늘부터 팀 프로젝트를 시작했다. 팀 프로젝트의 주제는 수강생 관리 프로그램이다.
오전은 요구사항을 정리하고 메소드 접근법, 예상되는 예외, 데이터의 구조에 대해 이야기하고 결정했으며, 다이어그램을 통해 메소드간 연관성을 파악했다.
대략적으로 프로젝트의 요구사항을 정리하자면 다음과 같다.
- 수강생 (고유 번호, 이름, 과목 목록)
- 점수 (과목 고유 번호, 수강생 고유 번호, 회차, 점수, 등급)
- 과목 (고유 번호, 과목명, 과목타입) 를 통해 CRUD를 구현하라.
오늘 내가 제시한 내용은 다음과 같다.
- 모든 모델이 고유 번호를 통해 관리되기 때문에 Map구조로 접근해야한다.
- 접수의 경우 수강생 고유 번호에 종속되나, 회차,점수,등급은 과목 고유 번호에 의해 제어되기 때문에 중첩된 Map으로 접근해야한다.
- 클래스 부터 구현을 하는게 좋아보인다.
팀 회의를 통해 1,2를 채택되었고 3은 기각 후 기능 구현을 우선하기로 했다.
내가 담당하게 된 부분은 수강생을 생성하고, 수강생이 선택한 과목을 필수 3개 이상, 선택 2개 이상을 받게 하고, 입력받은 값을 이용해 과목 번호로 변환해 저장하는 것과 특정 수강생의 번호를 입력하면 해당 수강생이 등록한 과목들을 종류별로 출력하는 것이다.
throw를 이용해서 과목 개수 예외, 타 과목종류 예외등등을 처리했으며, 필수+선택 과목이 연속된 숫자로 표현되는데 (1~9) 선택 과목 등록의 편의를 위해 1~5, 1~4로 분리하고, 선택 과목은 입력 +5를 통해 1를 입력받지만 처리는 6으로 하게 함으로 코드 수정량을 줄였다.
이후 Github를 통해 각 기능별 branch에서 add-commit-push를 진행하고, dev branch에 PR를 진행했다.
다만, 모든 기능이 구현이 완료된게 아니라서 2일차 오전에 오류를 파악하고 디버깅을 진행하기로 했다.
우선 사실상 처음 협업인데 프로젝트가 어렵지 않아서 협업에서 발생하는 기술적 문제를 최대한 경험하고 수정하는것에 집중을 해 볼 예정이다. 물론 기능을 최대한 객체 지향스럽게 구현할 예정이다.
2024-08-02
오늘 한 일
- 수강생 출력을 아이디 기준 오름차순으로 수정
- 클래스명 수정
- 추가 요구사항 추가
- Main 메소드에서 처리된 모든 기능을 여러개의 Class로 나눠서 각 메소드의 책임을 분리
- 각 메소드마다 중복되는 기능을 따로 메소드화
- 다이어그램 최신화
진행
오전에 어제 PR이후 발생한 자잘한 오류들을 수정하고 각자 구현한 기능에서 수정했으면 좋겠는 부분을 나눈후, 담당한 기능을 수정했다.
나의 경우 출력시 등록 순서가 의미 없다고 생각해서 keySet()으로 키를 받고 바로 출력을 진행했는데, 오름차순으로 정렬해서 출력했으면 좋겠다는 의견에 따라 Set -> List -> sort -> 출력의 과정을 추가했다.
이후 모두가 인지하기 좋도록 클래스명을 통일, 수정했고, 4명중 2명은 추가 요구사항 추가, 2명은 아직 완성 못한 기능을 완성하는 과정으로 진행했다.
나의 경우 추가 요구사항을 구현하는 팀이였는데, 수강생에 Status 필드와 관련 기능을 추가하는 것과, 수강생 정보 수정, 삭제, 상태별 조회 기능을 구현하는걸 담당했다.
필드 추가와 더불어 get, set을 통해 구현을 하는 것을 어렵지 않았으나, 하나의 파일에 모든 기능이 들어가있는건 수정해야한다고 생각했다.
이후 각자 담당한 파트 개발이 종료되고, 파일을 분리해야한다고 의견을 제시했고, 모두가 동의해서 일단 크게 3개의 파일로 분리했다. 메인 페이지를 출력하고 각 페이지를 호출하는 클래스, 수강생 관련 클래스, 점수 관련 클래스로 분리를 했다. 이 과정에서 각 메소드의 응집도와 결합도의 수준이 크게 작용을 하는데 각자 메소드를 중심으로 개발을 해서 인지 결합도는 낮고 응집도는 높아서 클래스 분리는 쉽게 이루어졌다.
이후 각자 개인 스케줄로 인해 같이 개발을 하는 시간은 종료되었고, 나의 경우 각 메소드마다 중복되는 코드를 메소드로 추출해서 리펙토링을 조금 진행했다.
바램
현재 Student, Score, Subject 클래스를 통해서 인스턴스를 생성하고있는데, 이 3개의 클래스의 공통점을 찾아서 인터페이스화 하거나 부모 클래스를 만들어서 상속하는 과정을 추가해도 좋을거 같다.
2024-08-05
오늘 한 일
- Student, Score의 기능을 담당하는 한 클래스 파일을 3개의 클래스 파일로 분할(view, update, check)
- 팀원의 인텔리제이 오류 함께 수정해보기
- throws로 처리한 오류 try-catch로 처리하기
진행
오전 회의에선 지금 프로그램에서 더 추가할 기능에 대해 회의를 나눴으나, 지금 프로그램은 전혀 객체지향적이 아니라고 판단해서 리펙토링 위주로 작업을 진행하기로 결정했다. 먼저 기능은 10가지 정도되는데, 구현체를 제외하고 class 파일이 3개뿐이 없어서 각 클래스 파일이 너무 많은 책임을 가지고 있다고 판단했고, 책임을 덜기 위해 목적이 비슷한 메소드끼리 묶기로 결정했다. 또한 자바의 꽃인 인터페이스를 이용하기 위해서 구현체인 student, subject의 공통점을 모아서 인터페이스 혹은 상위 클래스화 하기로 했따.
그 전, 팀원중 한명의 인텔리제이에서 문제가 발생해서 같이 해결을 해주려다가 iml파일의 역할을 알게 되었다. 이 파일 때문에 각자 설정이 출동해서 오류가 발생할 수 있고, 이 파일이 없으면 컴파일도 안되는것을 알게되어서 gitignore을 이용해서 iml을 제외하고 push하는 법을 배워서 사용했다.
이후 리펙토링을 하기 전 예외 처리 방식의 통일이 필요함을 느꼈다. 나의 경우 모든 예외를 throws해서 강제 종료한 반면, 다른 팀원들을 try-catch를 사용해서 프로그램 실행을 유지했다. 후자의 방법이 더 좋다고 판단해서 내 에러를 모두 try-catch를 사용하는 방식으로 교체하는 작업을 진행했다.
예외처리 통일 후 인터페이스 혹은 상위 클래스화를 하려고 했으나, 각 구현체의 공톰점이 사실상 의미 없는 수준이라 이는 진행하지 않았다.
이후 큰 클래스 파일을 세분화 하는 작업을 진행했는데, 기존의 파일에선, 예를 들면 StudentMenegement, UI출력과 데이터 입력, 데이터 수정 및 삭제, 예외처리 까지 모두 구현되어 있었다. 목적이 같다는 공통점으로 하나의 class에 작성했기 때문에 이를 3개의 목적으로 세분화 하고, 하나의 패키지로 묶는 방법으로 결정했다.
각 view, update, check로 나눠서 view는 UI 출력 메소드, update는 입력, 수정, 삭제, check는 예외처리 메소드를 위치 시켰다.
바램
이후 각 패키지 안에는 view, update, check로 분리된 클래스들이 존재하게 되었고, 여기서 최대한 공통점을 찾아서 interface로 구현을 해볼까 생각중이다.
2024-08-06
4일차 (main 브런치가 아니라서 나중에 PR하면 수정)
오늘 한 일
오전엔 프로그램이 대부분 완료되었고, 목요일에 있을 발표 준비와 더불어 코드의 가독성등을 높일 생각을 하고, 실제로 발표자를 뽑고 발표 내용을 정했다. 하지만 개인적으로 객체지향적인 프로그램은 아니라고 생각했고 이러한 점들을 아쉬운 점에 적었다.
그러던 중 프로젝트에 수정방향을 알려주시는 튜터님이 이런 프로그램은 C언어를 모듈화 한 거나 다름이 없는 프로그램으로 보인다고 하며 절대 객체지향적이지 않다고 했다. 그래서 비록 목요일 발표를 제외하면 하루밖에 남지 않았지만 기능 구현 메서드를 활용하면 충분히 객체지향으로 바꿀 수 있다는 생각에 프로그램을 전부 뒤집어엎었다.
크게 기능별로 Model-View로 나누고자 했지만, 클래스의 특성들을 살려 Display, Management, Model로 나눈 후, 최대한 객체를 활용하기 위해서 Student, Score를 전부 분리했다.
이후 HashMap을 통해서 관리한 StudentStore, ScoreStore, SubjectStore은 전부 객체화를 진행했다.
이를 통해서 전부 static으로 구현한 프로그램이 Main과 메인 UI을 제외한 모든 메서드에서 static을 제거하고 객체화가 되었다.
다만 각자 구현했던 기능을 객체화하는 작업에 있기 때문에 아직 프로그램 구동을 하진 못했다.
바램
우선 프로그램의 정상 작동을 확인하는 게 우선이고, 단일 클래스들이 너무 많은 책임을 갖고 있는 걸로 보이는데, 우선 작동확인 후에 책임을 분리해야 할 거 같다.
2024-08-07
오늘 한 일
어제 절차지향 -> 객체지향으로 구조를 변경하면서 merge를 못한 상태로 내 담당 메소드만 작동되는 걸 확인하면서 작업이 종료 되었는데, 오늘 오전에 각 팀원들이 올려주는 branch를 merge해서 최종 작동을 확인했다.
작동을 확인하고 불필요한 public을 private으로 변경하는 사소한 수정을 거쳐 최종 버전을 완성했고, 이를 이용해서 내일 진행할 발표에서 사용될 자료를 제작했다.
우리팀은 작업을 하면서 다이어그램, 노션 정리, ReadME작성을 동시에 했는데, 어제 급하게 작업하느라 이러한 것들을 하지 못해서 오전에 내가 다이어그램, 노션정리를 담당했고, 다른 팀원들은 각각 ReadMe작성, 구현 영상 촬영, 발표 PPT 제작등 각자가 담당한 부분을 처리했다.
내일 발표회를 보면서 다른 팀들은 어떻게 구현을 했는지, 우리의 수준이 어느정도인지 판단하고 정리를 할 예정이다.
github에서 branch를 생성하고 add-commit-push를 하고 Pull Request를 하며 협업하는건 처음이라 많이 기대 했는데, 기대만큼 꽤나 즐거웠던 협업이라서 다음 팀 프로젝트도 매우 기대된다.
KPT
Keep - 현재 만족하고 있는 부분
Problem & Try- 불편하게 느끼는 부분과 Problem에 대한 해결책
개인 회고
순수한 자바를 이용한 첫 협동 개발이 종료가 되었다. 기술적 수준으로는 매우매우 기초적이지만 본 프로젝트의 목표는 협업시 GitHub를 사용하는 것, 요구사항을 분석하고 그에 따른 설계를 공유 하는것, 코드의 규칙을 정해서 작업을 하는 것 등 혼자서는 경험할 수 없는 부분을 경험하는 것이 목적이였다. 본 프로젝트에서는 순수 코딩 시간 만큼 공유 문서 작업과 설계에 시간을 많이 사용했다고 생각하는데, 그럼에도 불구하고 2번의 구조 변화가 필요했던 것 만큼 앞으로는 설계 과정에서 더 많은 이야기를 나누고, 분석을 더 꼼꼼히 해야겠다고 생각한다.