[프로젝트/KPT] 프로젝트를 끝 마치며

프로젝트 소개

 

'NBCStudentManager' 프로젝트는 Java학습 기간 동안,
팀원들과 협력하여 학생 관리 프로그램을 만드는 프로젝트입니다.

사용 기술은 Java만을 활용하여 개발했고, IDE는 IntelliJ, 버전 관리는 Github를 통해 진행되었습니다.

 

' NBCStudentManager'는 다음과 같은 내용으로 구성되어 있습니다,

 

1. 학생 관리

• 학생 정보 추가
• 학생 목록 조회
• 학생 상태 수정

2. 점수 관리

• 수강생의 과목별 시험 회차 & 점수 등록
• 수강생의 과목별 회차 점수 수정
• 수강생의 특정 과목 회차별 등급 조회

3. 데이터 저장

• 데이터 저장
• 데이터 불러오기

4. 더미데이터 생성    

• 랜덤한 정보를 담고 있는 Student 데이터 생성
• 랜덤한 정보를 담고 있는 Score 데이터 생성

팀 내 역할

안예환님	수강생 정보 등록 & 상태 수정	https://davidan94.tistory.com
이시우님	수강생 상태별 목록 조회	https://vir8467.tistory.com/
박지민님	과목별 시험 점수 등록	https://note994.tistory.com/
오현택님	과목별 시험 점수 수정	https://oht2050.tistory.com/
저	특정 과목 등급 조회, Json 형태로 데이터 저장, 더미데이터 생성 Class	https://choni.tistory.com/

 

코드 규칙

 

협업을 진행하는 시간 동안, 물론 내가 작성한 코드를 보는 시간이 제일 길겠지만,

팀원이 작성한 코드를 보는 시간 또한 그와 준 할 정도로 많은 시간을 차지합니다.

그렇기에 팀원이 작성한 코드를 이해하는 시간을 줄이기 위해 팀원간의 코드 규칙을 만들어 사용하게 됩니다.

 

물론 모든 사람이 공통된 규칙으로 작성하게 된다면, 어쩌면 특색없는 코드처럼 보일 지도 모릅니다.

하지만, 각자 다른 환경에서 개발해 오며 적응된 코드 스타일을

다른 팀원이 이해하고 분석하는데에는 오랜 시간과 노력이 필요하게 됩니다.

 

그렇기에 코드 규칙은 협업에서 서로에 대한 배려이자, 중요한 요소 중 하나라고 생각합니다.

 

그래서 저희팀은 시작하기 전, 유지보수와 서로의 코드를 더 깊게 이해하기 위해

앞으로 작성할 코드에 대해 규칙을 정했습니다.

1. class작성시 class명 첫 글자는 대문자로 작성 ( ex : class Student )
2. 변수와 메서드는 camel형식으로 작성  ( ex : int drinkType, getStudent() )
3. 주석은 주석달 곳의 한 줄 위에 작성
4. boolean타입의 변수, 메서드를 선언할 경우 is로 시작하게 작성 ( ex : isUsed )
5. 캡슐화를 위해 instance 변수는 private로 설정( 상속시 protected )

다른 코딩 스타일을 갖고 있는 서로가 다른 팀원들을 위한 배려를 할 수 있는  위와 같은 규칙을 적용했습니다.

그리고 모든 팀원분들께서 해당 규칙에 맞춰 작성해주신 결과

함수, 메서드, Class의 구분이 수월했고 각 함수의 구조를 파악하고 사용하는 것이 수월했습니다.

 

결과물

 

[ NBCStudentManager 최종 결과물, 데이터는 Dummy 데이터 삽입 ]

KPT

 

지난 1주일 동안 팀 프로젝트를 진행하면서,

소통, 개발하는 과정에서 저 혹은 팀원분들이 느꼈던 내용을

K( Keep ) 좋았던 점, P( Problem ) 아쉬웠던 점, T( Try ) 앞으로의 노력 순으로 정리했습니다.

 

오래 걸리더라도 확실하게 - 소통

 

' NBCStudentManager'를 진행하는 과정에서 많은 회의와 소통이 오갔습니다.

 

크게는 프로젝트 기능부터 UML작성부터, Class 설계, 자료구조와 같은 세세한 내용까지 회의를 진행했고,

그 과정에서 느꼈던 좋았던 점과 아쉬웠던 점, 앞으로 도전해야 할 점은 다음과 같았습니다.

1. Keep

저희 팀원분들의 소통에 있어 제일 좋았던 점은 다음과 같았습니다.

1. 회의가 길어지더라도 적극적으로 질문하며, 서로 갖고 있는 지식과 정보를 공유했다는 점
2. 내용에 있어 아쉬운 점이나 보충해야 할 내용이 있다면, 적극적으로 피드백 해주시며 건설적인 회의를 진행 할 수 있었던 점

협업을 진행하면서 질문은 설계도 작성과 같다고 생각합니다. 

질문을 통해 서로가 이해한 내용을 공유하거나, 다른 점이 있다면 조정해나가며

프로젝트가 어긋나지 않을 수 있기 때문입니다.

 

그러한 점에 있어 저희 팀원분들은 꼼꼼하게 같이 설계도를 작성해 나갔습니다.

 

또한, 질문과 피드백에는 많은 용기가 필요합니다.

심지어 처음으로 협업을 진행하게 된 낯선 사이에서는 더 큰 용기가 필요하게 됩니다.

 

그럼에도 저희 팀원 분들은 회의의 내용 중 추가 설명이 필요한 내용이 있을 경우,

적극적으로 질문하거나 또 대답하며 서로가 이해하고 있는 내용의 중간점을 찾으려 노력했습니다.

 

그리고 수 많은 피드백이 쌓여 완성된 설계도를 토대로

지금과 같은 멋진 결과물이 탄생할 수 있었습니다. 

 

2. Problem

이번 프로젝트에 있어서 소통 부분에서 아쉬웠던 점은 

서로 만든 함수에 대한 교류가 미흡했습니다.

 

협업을 하다보면 같은 기능을 구현해야 하는 상황이 발생합니다.

이러한 부분에서 교류가 미흡할 경우

동일한 기능을 하는 함수가 2개 이상 생성 돼 함수 사용에 혼동을 야기하거나,

코드의 부피가 커지는 현상이 발생하게 됩니다.

 

지금 프로젝트에서는 과목들 중 특정 과목을 찾는 기능이나, 특정 학생을 찾는 기능이 그러했습니다.

 

이번 프로젝트에서 저를 포함하여 특정 과목이나 학생을 찾는 기능을 사용해야 하는 사람들끼리의 교류가 미흡했었습니다.

그 결과 각 함수마다 특정 학생을 찾는 기능이 별도로 구현되어 있었고,

스케일이 크지 않은 프로젝트 임에도 코드의 길이가 800줄이 넘어가 코드를 분석하는데 어려움을 겪었습니다.

3. Try

Java에서의 첫 협업에서 발생한 이슈이다 보니, 저도 그렇고 여유가 부족해 내가 작성한 코드만 보게 되는것 같았습니다.

이러한 점은 협업을 계속 하다가 여유가 생기면 나아질것이라 생각합니다.

 

그럼에도 앞으로는 동일한 기능이 필요한 사람과 회의 외적으로도 소통하며, 내용을 공유하기로 했습니다.

 

빠르고 정확하게 - 개발

 

' NBCStudentManager ' 프로젝트는 첫 회의부터 난항이었습니다.

캠프에서 제공하는 템플릿 프로젝트를 사용할 것인지에 대한 회의부터,

'Class설계는 어떻게 할것인가?', '역할은 어떻게 나눌것인가' 까지 하루를 회의 하는 곳에 써야만 했습니다.

 

하지만 그렇게 열띈 회의를 진행한 결과, 프로젝트 진행과 개발이 더 수월했습니다.

이번 프로젝트 개발 중 느낀, 좋았던 점과 아쉬웠던 점, 앞으로 도전해야 할 점은 다음과 같았습니다. 

 

1. Keep

제일 좋았던 점은 역할을 기능별로 나눠 개발을 진행했다는 점입니다.

기능별로 나눠 개발을 했다는 것이 꼭 좋다고는 못 하지만,

적어도 현재 프로젝트와 저희에 대해서는 최선의 선택이었습니다.

 

협업을 하다보면 제일 골치 아픈것이 충돌처리 입니다.

서로 같은 부분을 작업하거나, 서로 구현해야 하는 Class 메서드를 작성하는 중 충돌이 발생할 경우,

어떻게 처리를 해야할지에 대해 시간을 투자해야하기 때문입니다. 

 

이러한 이유에는 역할 분배를 기능별로 나눈 전략이 큰 도움이 됐습니다.

 

우선, Class별로 역할 분배를 했다면, Class가 완성되기 전까지 그 뒤의 일정을 딜레이가 될 수 밖에 없습니다. 

하지만 저희는 짧은 시간 속에서 최대한의 효율을 뽑기 위해,

Class의 내용을 최대한 빼고 각자 맡은 기능을 개발하는 것에 시간을 더 할애 했습니다.

 

그 결과 부족한 시간 속에서, Class에 투자되는 시간을 최대한으로 아낄 수 있었고,

충돌이 최소화되어 각자의 코드에서 해당 Class 메서드와 변수를 활용한 기능 구현을 빠르게 진행할 수 있었습니다.

 

또한, TestCase를 작성하는 과정에서 특정 기능에서 문제가 발생할 경우

해당 코드에 대해 제일 이해도 높은 팀원이 수정을 진행해 깔끔하고 빠르게 오류를 해결할 수 있었습니다.

 

[ 왼) 테스트 시나리오 1차, 오) 테스트 시나리오 2차 ]

2. Problem

이번 프로젝트에 있어서 개발 부분에서 아쉬웠던 점은

코드 분할이 제대로 이루어지지 않아 코드의 부피가 지나치게 커졌다는 점입니다.

 

코드의 부피가 커질 수록 코드의 흐름과 내용을 이해하기 어려워집니다.

수 많은 내용 속에서 흐름을 확인하는 것도 일이겠지만,

확인하는 과정에서 지나치게 많은 정보를 봐야만 하기 때문입니다.

 

Class를 간소화 했기에 필요한 기능을 전부 각자 구현을 해야 했습니다.

그러는 과정에서 main문의 부피가 커져만 갔고,

나중에는 마우스 휠만 굴려야 하는, 흐름을 파악하기도 어려운 상태가 되었습니다.

[ 941줄이나 하는 Main.java ]

 

또한, 템플릿 코드를 사용하지 않고 저희만의 프레임워크를 작성하지 못한 점 또한 아쉬웠습니다.

맨 땅에 헤딩을 하듯, 어떤 시나리오를 가져갈 것인지 생각하고, 그대로 작성하며,

팀만의 프로그램을 만들지 못 한 점이 한층 더 성장할 수 있는 기회를 놓친 것 같아 아쉬웠습니다.

3. Try

Java환경과 개발을 거듭할 수록 이 문제는 해결될 것이라 생각합니다.

 

하지만, 조심하고자 하는 마음으로 예를들면 Console창에 정보를 띄우거나,
입력을 받는 것과 같은 함수를 Communication이라는 Class에 묶어 관리하기와 같이

동일한 기능을 하는 함수를 별도의 파일이나 Class에 작성하여 관리를 하기로 했습니다.