[WIL],[0814...0821],[Anabada_15조]

WIL

Keep

1. 문제상황을 팀과 공유

이번 팀프로젝트의 경험 중 좋았던 부분은 문제상황을 팀단위로 고민할 수 있었던 것이다.

물론 시도도 해보지 않고 문제를 공유하는 것과 다양한 시도를 한 뒤 공유하는 것은 다른 이야기이다

하지만 다양한 시도를 해본 뒤 문제를 공유하는 것은 팀에게도 다양한 경험을 줄 수 있다고 생각하며

문제를 해결해 나가며 문제 해결 능력이 향상될 수 있다고 생각한다.

2. 정확한 목표를 설정

프로젝트를 시작할 당시 우리 팀은 팀원 개인의 역량을 정확히 가늠할 수 없기에 막연한 목표보다는 달성가능한 목표를 잡은 후

추후 달성했을 시에 목표를 더 확장할 수 있도록 설정하였다. 물론 처음부터 더 큰 목표를 가지고 도전하였다면

모두가 분발하여 더 큰 목표에 도달할 수 있을 것 같다는 생각도 하였다.

하지만 도달 가능한 목표를 잡아 팀원들 모두가 코드를 이해하며 직접 구현할 수 있는 시간이 있었다고 생각한다.

상황에 따라 다르겠지만 지금처럼 배우고 있는 상황이라면 직접 적어보며 이해하는

코드가 중요하다 생각이 되어 달성가능한 목표를 둔 것이 지금 우리의 상황에서는 조금 더 나은 선택이었다고 생각한다.

3. 팀과의 소통을 활발히 

저번 조에도 그러했듯이 이번에도 팀과의 소통은 원활히 진행하였다고 생각한다.

Problem

1. 초기 설계의 부족

저번 회고에서도 느꼈던 부분이기에 조금 더 잘하고자 시도해 보긴 하였다.

하지만 개발을 시작하고 보니 초기에 설계를 해야 하는 부분에 대해 부족한 부분이 많이 보였다

그 경험으로는 데이터 모델을 처음부터 조금더 엄밀하게 생각하여 구성을 했어야 한다고 생각한다.

이 부분을 놓친 우리 조는 공용 클래스인 DataManager를 자주 변경해야 하는 문제가 발생하였고

UI의 가이드가 부족하여 각기 다른 UI를 통일시키느라 시간을 소비하였다.

2. 주석의 부족

이번 프로젝트는 급하게 해서인지 나를 포함한 전 팀원들의 코드에는 주석을 찾아볼 수 없었다.

그렇다 보니 문제가 있는 부분을 파악하는것에도 어려움을 겪었고 내가 쓴 코드조차 한눈에 알아볼 수가 없었다.

또 한 팀프로젝트인 만큼 다른 사람들의 코드를 보게 되는데 설명 없이 코드를 보게 된다면 가독성이 좋지 않아

코드를 파악하기에 불편함을 겪어야 했다.

Try

1. 초기 설계 접근을 자세히 하기

앞서 설명하였듯 개발을 하기에 앞서 깃 전략, 디자인 패턴, 명칭의 통일, UI의 통일 등을 보다 엄밀히 정하여

향후 개발에만 전념할 수 있는 환경을 미리 만들어 두는 것이 조금더 효율적이고 시간을 단축할 수 있다 생각하기에

와이어 프레임을 자세히 짜보는 노력을 해보는 것이 좋다고 생각한다.

2. 코드의 문서화

다른 팀월들이 나의 코드를 보았을 때 쉽게 코드가 읽히도록 코드의 문서화를 해야 한다고 생각했다.

향후 유지보수 측면에서도 코드의 문서화는 지금부터 시작해야하는 필수적인 요소라고 생각한다.

3. PR

좋은 경험과 좋은 결과물이 있더라도 다른 사람들에게 전달을 잘하는 것 까지가 마무리라고 생각한다.

우리 팀은 준비가 미흡한 상태에서 발표를 하였지만 팀장님의 활약으로 발표를 무사히 끝마칠 수 있었지만

준비가 미흡했던 탓에 우리의 코드와 우리의 경험을 온전히 전달하지 못한 아쉬움이 남는다. 그렇기에

다음에 발표할 기회가 찾아온다면 최선을 다해 코드와 경험을 전달할 생각이다.