23. 04.17 TIL

오늘 한 것

발표준비
발표 및 피드백 받기
KPT회고 작성
선발대 강의 정리(링크)

장고 기초 프로젝트가 오늘부로 마무리 되었다.

API명세와 ERD를 포함한 SA 수정 및 발표 자료를 준비하였다.

새로 만들어진 모델들을 반영하였다.

피드백 정리

발표 후 피드백을 받은 내용을 정리하였다.

테스트 코드, 주석처리한 코드는 배포전에 지워라

코드에 쓸데 없는 군더더기가 남지 않는 것이 좋다.

필드명, app 폴더명, 모델 명등의 이름을 잘 지어주자

한번에 알아볼 수 있는 이름으로 잘 지어주는 것이 좋으며 네이밍 컨벤션에 알맞은 이름을 지어야한다.

백엔드에도 검증(validation)이 필요하다

프론트 엔드에서 적합하지 않은 입력값을 걸러낸다고 해도 백엔드에서도 한번 더 검증을 할 필요가 있다. 왜냐하면 postman 등을 통해 프론트 없이 요청을 보낼 때에는 걸러낼 수 없기 때문이다.

액세스 토큰, 시크릿 키 등 민감한 데이터가 깃헙에 올라오게 하지 마라

gitignore, .env 등을 활용해 보안 취약점을 숨길 수 있는 한 숨기거나 제거하는 것이 좋다.
비슷하지만 조금 다른 것으로, 미디어 이미지 파일 등 굳이 git hub에서 관리할 필요가 없는 파일들도 원격 repo에서는 제거되어있는 것이 좋다.

한번의 요청에 너무 많은 DB접근을 하지 마라

데이터 통신량이 적은 경우는 괜찮지만 많은 경우에는 DB에 부하가 올 수 있으므로 접근 횟수를 줄일 수 있다면 최대한 줄이는 것이 좋다.

커밋 컨벤션을 정하라

커밋 메시지를 잘 작성해 두는 것은 자신을 증명하는데 있어 중요하다. 시작부터 유형별로 어떤 메시지를 적을지 컨벤션을 정해주는 것이 좋다.

템플릿 구조를 정리하라

꼭 필요한 경우가 아니라면 몇개씩 파고들어가는 태그 구조는 피하는 것이 읽기 좋은 코드를 만드는데 도움이된다.

동일한 대상에 대한 처리라면 url을 나누지 마라

대신 method로 나누는 것이 좋다. 메소드에 따라 나눌 수 있는 것을 굳이 API 주소 늘려가며 분리할 필요가 없다.
또한 Django에서도 PUT, DELETE 등의 메서드들을 사용가능하다.

늘 코드 중복을 줄일 길을 찾아라

if문을 나열하는 제어문은 더이상 좋은 코드가 아니다. 더 좋은 코드를 만들기 위해 고민하라.

KPT 회고

발표까지 마친 뒤 프로젝트에 대한 회고록을 KPT 형식으로 작성하였다.

K: 다음에도 할것

• PR 발생시 일정시간안에 코드 읽어보기 의무화. 서로의 코드에 대한 이해도를 높이고 코드리뷰를 통해 문제가 발생할 확률을 줄일 수 있다는 것을 실감하였다.
• 시작부터 반드시 시간안에 구현해야할 필수 기능들과 상황에 따라 구현할 수 있는 추가기능을 분리하여 모두 목록화하고 구현하게 된다면 어떤 방식을 사용할지 대략적으로라도 상의해두니 추가 기능을 작성할 때 늘어지는 일 없이 바로바로 새로운 기능에 착수할 수 있었다.
• 처음부터 api 명세를 엄격하게 정해놓고 시작하니 매우 편했다

P: 다음에 개선할 것

• 네이밍 컨벤션이 잘 지켜지지 않았다. 솔직히 폴더명(앱 이름)까지 컨벤션을 지켜야하는지 몰랐는데 이번 기회에 알게되었으니 최대한 컨벤션을 지키면서 네이밍 하도록 하자.
• 같은 주소의 다른 메소드들로 처리할 수 있는 부분도 다른 url로 처리하는 문제가 있었다. Django에서는 PUT, DELETE를 못쓴다는 잘못된 정보로 부터 비롯된 문제로, 다음부터는 제대로 된 정보를 찾아 반영해보도록 하자.
• 새로운 기능을 구현할때 API명세의 업데이트가 조금 느린 문제가 있었다. 습관적으로 갱신하도록하자.

T: 다음에 시도해볼 것

• 깃헙에서 제공하는 이슈 기능 과 깃헙 프로젝트 기능을 사용해 프로젝트 진행해보기: 이번에 진행한 방식은 구현할 기능들 중 상황에 맞는 것을 선별해 적합한 인원 혹은 자원한 인원에게 분배하는 방식이었는데, 이 과정을 좀더 명시적으로 표시하면서 진행할 수 있을 것이다.
• 일간 회의를 할때 SA문서와 프로젝트 페이지를 열어놓고 함께 편집하며 진행해보자. 즉각적인 피드백으로 SA의 업데이트가 제때 이루어지고 참여 집중도가 더 올라가지 않을까?

F: 느낀점

3명이서 진행하느라 쉽지 않았지만 오히려 PR관리도 잘되고 코드 리뷰도 수월한 등 여러 이점도 있었다. 또한 팀원분들도 함께 문제를 해결하고자하는 의지를 보여주셔서 git hub 활용이 더 능숙해 지고 협업이 전보다 훨씬 원활해져서 이를 통해 좋은 결과를 만들어 낸것 같아 뿌듯하고 감사하다. 그렇지만 아직 갈길이 멀다. 다음에는 더 발전된 협업능력, 개발능력을 갖출 수 있게 스스로 갈고닦도록 하자.