이번 project에서 배운 부분을 크게 협업, 기술 두 부분으로 나눌 수 있습니다.
협업에 필요한 능력과 요소들은 수 없이 많겠으나, 제일 중요한 것은 대화와 소통이라고 생각합니다.
단순히 팀원들간에 말이 많고 재미있는 분위기를 만드는 것이 아니라, 팀원들이 서로의 생각과 업무을 이해하고 서로를 인정할 수 있는 것이 진정한 소통이라고 생각합니다.
2회의 스프린트에서 첫번째 스프린트는 이러한 부분이 다소 부족했습니다.
팀원 간 업무 진행에 대한 공유가 적었고 서로가 블로커가 되어 첫번째 스프린트의 목표달성을 하지 못했습니다.
두번째 스프린트에서는 이 부분에 대한 피드백을 했으며, Scrum의 추구 가치에 따라 작업 내용을 투명하게 공개했고 프로젝트 진행에 잘못된 방향은 용기있게 말하며 진행을 조율했습니다.
또한, 상대적으로 기술적인 부분에 어려움을 겪고 있는 동료의 개발 상황을 같이 체크하고 백업해주며 제 개발만 붙들고 있는 것이 아닌 팀으로서 함께 프로젝트를 달성할 수 있도록 적극적으로 나섰습니다.
첫번째 스프린트 이후, 특정 기능의 진척이 프로젝트 완성여부에 영향을 줄만큼 지연되었다고 판단하고, 맡은 파트를 재분배하여 진행할 수 있도록 소통했습니다. 제가 개발 내용은 포기해야했지만 팀적인 차원의 달성을 위해 재분배한 개발 파트를 성공적으로 달성, 프로젝트를 완성할 수 있었습니다.
코드를 작성하는 것은 컴퓨터와 나, 혹은 나와 또다른 개발자간의 의사소통 수단 중 하나라는 것을 배웠습니다. 효율적이고 정확한 대화를 위해서는 간결하고 명확한 용어로 말해야하듯이 코드 또한 깔끔하고 명확한 표현을 해야함을 배웠습니다.
처음 작성한 코드는 가독성 떨어지는 if~else 등의 분기가 쓸데없이 많아 디버깅은 커녕 Process Flow를 그려보지도 못했습니다.
불필요하게 반복되는 변수는 제거하고 가독성이 떨어지는 for문은 list comprehension 등으로 처리하여 한눈에 보이도록 리팩토링 했습니다.
쓸데없는 분기를 제거하고 정리된 코드는 버그가 발생하여 에러 코드를 띄우는 컴퓨터의 표현을 더 빠르게, 명확하게 이해하고 디버깅할 수 있었습니다.
위의 내용과 이어지는 부분으로 가독성의 개선을 위해 한 Class내에서 정의하는 Method가 지나치게 길어지거나 복잡해지는 상황, 또는 한개 이상의 기능을 수행하는 경우에는 또 다른 Method로 기능을 분리하여 처리해야 함을 배웠습니다. 비록 해당 프로젝트에서는 코드가 짧아 분리할 기능이 많지 않았지만 그럼에도 가독성을 개선하고 함수가 명확한 기능을 할 수 있도록 구성할 수 있었습니다.
더 나아가 이를 변수와 함께 묶어 Class로 새로 처리하는, 다른 객체로 생성해서 처리하는 추상적이던 객체지향의 python 언어의 특징을 이해할 수 있었습니다.
project의 디테일은 아래에서 확인하실 수 있습니다..
링크된 페이지를 통해서 백엔드 아키텍처와 Page Demo를 볼 수 있습니다.