첫 번째 프로젝트의 막바지에 이르러서

조호원·2020년 12월 20일
1

첫 번째 프로젝트가 어느덧 몇 개월이 지났다. 현재는 API는 완료되었고 프론트와 앱은 중간정도 진행된 상황이다. 학교 생활에 쫓기느라 내 프로젝트와 공부에 전념하지 못한 점이 정말 아쉬운데, 이러한 아쉬움을 제쳐두고 지금까지 해온 프로젝트를 돌아보여 반성의 시간과 내가 발전하고 배워야할 기술들을 살펴보는 시간을 가져보자.

팀원간의 소통

이번 내 기준으로 프로젝트는 대형 프로젝트라고 할 수 있다. 실제 현업에서 사용될 프로그램이기 때문에 더욱 무거웠다. 그런 만큼 팀원간의 소통이 필요했다. 하지만 각자의 공부와 학교 생활 때문에 팀원간의 소통은 그렇게 많지 않았다. 일주일에 주말마다 한 두번 만나기는 했다만, 이마저도 부족한 시간인 듯 했다. 팀원끼리 공유해야하는 가장 첫번째는 바로 프로젝트에대한 이해인것 같다. 이 프로젝트는 무엇이고 무엇을 위한 프로젝트인지 서로 이해하고 발전 방향과 기능들에 대해서 토론이 가능해야한다. 하지만 내가 주도해서 이끌었던 프로젝트 였는지라, 프로젝트에 대한 자신만의 의견을 내는 경우는 드물고 심지어 내 생각을 전달하기도 힘들었다. 그래서 내 의도를 이해하지 못하고 서로를 공감하지 못하는 상황에 이르게 되었다. 그래서 프로젝트하면서 대화가 상당히 중요하다고 느꼈다. 만약 대화를 할 수 없는 상황이라면, 혹은 팀원이 너무 많아 모든 사람이 대화를 참여할 수 없는 상황이라면 문서가 아주 좋은 매개체가 된다. 문서는 아주 자세하게 작성하여 오해가 일어나지 않도록 해야한다.(귀찮아서 문서를 대충썼더니 오히려 일일히 말로 알려주느라 더 힘들었다는) 문서는 내 생각에는 대화보다 더 유용하다고 생각한다. 왜냐하면 까먹었을 때 다시 찾아 볼 수 있기 때문이다.

TDD(Test Driven Develop)

두 번째로 부족했던 점은 바로 테스트다. 그리고 테스트하기 좋은 코드를 만드는 방법도 부족했다. 나는 애플리케이션이 잘 되는지 확인할 방도가 없었다. API를 다 작성할 때 쯤에 테스트를 알게되어 테스트를 작성했는데, 테스트를 하더라도 제대로 구조화되어 있지 않아서 테스트할 때 번거러움이 많았다. 그래서 테스트 주도 개발을 하기 위해서 좀더 구조화를 하고 기능 단위로 함수나, 메소드를 나눌 필요를 느꼈다. 비즈니스 로직이나 알고리즘은 모델 파일에 작성하고, 뷰 함수에서는 이러한 로직을 불러와서 사용하도록 해야한다. 즉 뷰 함수는 간단해야 한다. 그리고 하나의 API를 작성할 때마다 테스트를 작성하여 자신의 코드를 테스트한다.

코딩 기술

몰랐었는데, 이번 프로젝트를 통해서 내 코딩 기술은 한참 부족하다는 것을 느꼈다. 같은 코드를 여러번 기술하거나, 비즈니스 로직이 뷰 함수에 작성되어서 뷰함수가 난잡해지고 이 또한 같은 코드를 여러번 작성하게 했다.
파이썬의 데코레이터나 클래스의 메소드를 활용해서 이러한 코드 중복을 줄일 필요가 있었다. 또한 프로젝트 구조화도 많이 미숙했다. 에러는 에러대로 모델은 모델데로 각자 기능마다 나뉘어 프로그램을 작성해야되는데 이러한 기능들이 독립적이게 나누지 못해 서로 종속되어 복잡한 코드를 야기했다. 이러한 경험을 토대로 디자인 패턴에 대해서 공부를 해서 효율적이고 구조화된 코드를 코딩하는 법을 공부해봐야겠다.

  • 공부 해야될 리스트
    • TDD
    • Devops
    • Design pattern
    • python programming
    • 문서 작성법

프로젝트를 하면서 책을 통해 배우는 것 외의 다양한 경험과 깨달음을 얻을 수 있었다. 협업하는 Git과 배포 기술, 프로젝트 구조화, 파이썬 특유의 함수형과 객체지향형을 섞은 효율적인 코드, 테스트 주도 개발, 그리고 팀원간의 커뮤니케이션 등에서 나의 위치를 보고 내가 새롭게 배웠고 또 배우도록 하는 동기가 되어주었다.

profile
세상을 바꾸는 사람

0개의 댓글