소프트웨어 공학 수업에서 테트리스 프로젝트를 진행했다.
문제는 내가 팀장이었다. (왜인지는 모르겠음)
프로젝트 경험도 많이 없는데 팀장으로서 팀을 처음 이끌어갔던 과정에서의 회고록이다.
잘한점:
아쉬웠던점:
1) 구조 설계에 너무 집착했다.
요구사항 관련한 자료들은 첨부하였다.
1차는 시작하고 바로, 2차는 중간고사 3주 전, 3차는 중간고사 이후에 나왔다.
1차때는 기본적인 테트리스 게임에 대한 요구사항이 정의되어 있었다. 내가 본래 조금이라도 내 기준으로 납득이 안되면 못넘어가는 성격이어서 1차때 비기능적 요구사항인 자바 1.8 이상의 로컬환경에서 돌아가야된다는 워딩을 1.8 이상의 모든 버전 즉 8부터 현재 최신 버전까지 모든 로컬에서 돌아가야된다고 해석했다. 자바를 이용하여 어플리케이션을 만들기 위해서는 JavaFX 라이브러리를 이용해야했는데 1.8기준으로 본래 자바 패키지에 해당 라이브러리가 분리되어 따로 Dependencis를 추가해야 했고, 그 이전 버전은 JavaSwing으로 또 다른 라이브러리를 사용해야 했다. (이것은 기존 Java 언어 라이브러리에 포함되어 있음)
그래서 모든 버전에서 돌아갈 수 있게 하는 방법을 계속 찾았다. 프로젝트 끝나고 생각해보니 그냥 패키징할때 Swing이든 FX이든 그냥 자바 8 기반으로 일단 개발하고 패키징때 라이브러리 폴더까지 같이 묶어버리면 되는데 패키징에 대한 경험이 없다보니 상당히 골치였다.
추가로 테트리스 게임 로직에 대한 설계를 할때, 쓰레드에 대한 개념이 부족해서 일어난 문제였다. FX는 기본적으로 원래의 main함수 쓰레드는 돌아가고 있고 여러 이벤트 행위에 대한 쓰레드도 돌아간다. 하지만 나는 이런 이벤트에 대한 이해가 부족해서 Main함수에서만 코드가 읽히면 어떻게 이렇게 많은 일들을 처리할 수 있지? Scene이 바뀌는데? 라고 생각했었다. 자연스럽게 쓰레드에 대한 이해가 잡히면서 그 후 설계에 대해서는 수월했지만 이걸로 2~3주는 아무것도 못하고 날렸던 것 같다.
2) 시간 설계 미스와 역할분담의 서투름
설계 이후에는 빠르게 진도를 나갈것 같았는데 어림도 없었다. 생각대로 되면 그게 인생인가? ㅋㅋ
역할 분담 자체를 내가 다 떠안았다. 설계를 팀장인 내가 하다보니 다른 팀원들도 이에 대한 고지를 제대로 듣지 못했고(내가 하지도 않았고) 그러다보니 너무 큰 부분인 로직을 나혼자 맡고, 나머지 UI에 관련된 것들을 나머지 3명에게 맡겼다. 그러다보니 너무 진도가 나가지를 않았다.
해결 : 따라서 1차, 2차까지는 너무 힘들었는데 3차부터는 도저히 내가 혼자 어떻게 할 수 있는 상황이 아니라서 "내가 역할은 정해줄테니 내 코드 알아서 해석해서 구현해" 라는 식으로 가버렸다. 오히려 이게 더 효율적인 수행이 되었고 진도가 쭉쭉 나갔다. SE 수업을 나가다보니 결국엔 너무 세세한 룰을 부여하는것보다 "팀원을 믿고 크게크게 역할을 분배" 하는것이 기본이더라. 이걸 너무 늦게 알아서 시간도 빠듯해졌었다.
또한 그때그때 선행되어야 하는 파트를 맡은 팀원은 해당 시간에 붕 뜨기 마련인데 항상 그때는 Release Testing 및 User Testing을 시켰었다. 개발하느라 바빠서 실제로 게임 진행 중 버그가 없는지 따로 깊은 확인이 불가능했기에 그냥 쉬는겸 해당 버전에 대한 테스팅과 사용자 환경을 바꿔서 User Testing을 진행시켰다. 문제가 있으면 그때그때 다시 이슈사항으로 기록하고 구현팀들에게 현재 구현 중에 같이 버그 픽스를 위해 기록하였다.
3) 의사소통의 아쉬움
처음에는 줌으로 진행했다. 설계를 어떻게 할것인지, 구현을 크게 어떤식으로 할것인지 정하기 전에는 내가 팀원들에게 룰을 부여하기가 어려워서 우선 줌으로 진행했다. 줌으로 진행하면서 왜 요즘 기업들이 재택근무를 안하는지 뼈저리게 느꼈다.
마이크는 너무 겹치고 이 사람이 집중을 하고 있는지도 확실하지 않았고 서로 깃허브 없이 간단하게 코드를 봐야될 부분이 있으면 그것도 화면공유하랴 뭐하랴 힘들었다.
해결: 해결한 방법은 그냥 일주일에 한번정도 직접 모아서 Pair Programming을 진행했다. 이런 방식을 채택하니 진도가 쭉쭉 나갔고 다 같이 한자리에서 개발하다보니 여러 이슈사항을 딜레이 없이 그때그때 처리할 수 있어서 효율적이었다.
4) 리팩토링
확실히 패키지 구조나 클래스를 배치한 위치나 전체적인 배치 설계는 좋지는 않았다. 구현 사항에 대한 설계는 Bottom Up 방식을 사용하여 추가 요구사항이 나왔을때 잘게 나눴던 컴포넌트들 덕분에 조립하다 보면 잘 구현되었다. 성능도 괜찮았다.
하지만 확실히 엄청나게 작은 컴포넌트들의 집합으로 이루어지다보니 메서드 배치라던가 클래스들을 어떻게 구성해야될지 애매했다. 그러다보니 리팩토링 과정에서 다시 재배치를 시도하였지만 쉽지 않았었다.
해결: 최대한 SOLID 원리를 이용하려 했다. 하나의 클래스는 하나의 기능만 담당하게 쪼갰고, 키설정과 단순 설정들은 DTO처럼 하나의 Class로 모아서 뺐다.
시간 상 못했던 점: 매번 테스트삼에 실행시킬때마다 .idea, target, build와 같은 IDE 설정이나 빌드 결과물은 버전 관리에서 제외하지 못하여 매번 실행 후 따로 한번 커밋을 다시 했었어야 됐다.
데드라인에 걸려 상수값들을 의미있는 이름을 붙여 상수로 처리하지 못했었다. 이건 간단한 것들이었는데 데드라인이 오전 9시에 발표였는데 크런치 모드로 달리다보니 못했었다 ㅠ
