스파르타 최종 프로젝트 회고록[Django]

손성수·2023년 7월 5일
0
post-thumbnail

백엔드 GIT 저장소


구현 로직 안내


배우게 된 것

데이터 베이스 설계

ERD Cloud

  • 설계의 중요성
    기능 구현을 위해 Model Field를 추가해도 되는지, 안해도 되는지
    망설이곤 했다.
    이런 필드를 추가해도 되는건가?
    꼭 필요한 필드인가?
    내 마음대로 필드를 추가해도 되는건가?
    이러한 고민을 하는건 좋았지만, 그 기간이 너무 길고
    최대한 필드 추가를 안하고 데이터를 구현해 보려곤 했다.


    그 중 내 프로젝트에서 가장 대표적인 Model이다.

    핸드폰 인증을 했는지, 안했는지 필요한 데이터 였으며
    또한 마지막으로 인증 코드를 발급 받은 시간이 언제인지 알기 위해서
    update_at과 같은 DateTime을 기록할 필드가 필요 했다.
    사진에는 update_at필드가 없지만 공통 상속 필드를 사용하고
    one-to-one model로 관리하여 server와 사용자는 서비스의 신뢰성을 높일 수 있도록 보완 성능을 개선 했다.

Serializer

위의 Serializer Trouble Shooting에서 기재한 내용과
Serializer 응용에서 기재한 내용에 관한 이야기이다.
APIView에서 유효성 검사, 데이터 직렬화, 데이터 처리, 데이터 암·복호화, 예외 처리 등 너무나 많은 기능이 Views.py에서 진행되었다.
문제의 원인은 Serializer의 이해도가 낮아서 유용한 기능을 쓰지
못하고 있었던 점이다.
views.py는 API status값을 적절히 반환하는 용도로만 사용하고 싶었기 때문에 Serializer의 오버라이딩 메서드를 적절히 이용하게 되었다.


모듈 관리

데이터 유효성 검사, 이메일 발송, 핸드폰 메시지 발송, 데이터 암 복호화
위의 네가지 기능은 여러 API에서 사용되는 기능들 이므로
각각의 API에서 사용 된다면 중복된 코드들이 더러 발생하게 될 것이다.
따라서 StaticMethod와 ClassMethod를 이용하여 데이터를 모듈로서 관리하게 되었다.


암호화 알고리즘 AES

  • 사용자의 주소지 정보, 사용자의 핸드폰 번호, 통관번호와
    판매자의 계좌 정보를 암호화하여 데이터 베이스에 저장할 필요성을 느끼게 되었다.

  • 이 과정 속에서 AbstractBaseUser의 set_password,make_passwrod등
    비밀번호 해시 알고리즘을 활용해 암호화 하는것을 알게 되었다.

  • AES의 ECB MOD는 보완성이 낮으나, 구현이 쉽고 성능적인 기대 측면이 있어 토이 프로젝트에 적합하다 생각하여 채택하여 구현하게 되었다.

Oauth 2.0

  • 카카오, 네이버, 소셜 로그인 기능을 구현 하면서
    Oauth 2.0의 인증 시스템에 관해 알게 되었다.

아쉬운 점

너무 긴 리펙토링의 시간

구현한 회원 기능에서 지속적인 리펙토링의 시간을 갖게 되었다.
이메일 인증과 핸드폰 인증, 회원 가입 및 수정,
소셜 로그인, 배송 및 판매자 정보 CRUD, 데이터 암·복호화
많은 기능을 구현한 것 같으면서도,
분명히 나는 더 많은 기능을 구현 할 수 있었다.
그럼에도 구현을 하지 못한점은 어떤 기술 스택을 가져와서 사용할지
또한, 지금 구현한 기능이 만족 스럽지 못한다는 점이 계속해서 머리에 맴 돌았고, 다시 리펙토링하고, 롤백하고, 리펙토링에 리펙토링을 계속해 나갔다.


과감하지 못했던 점

잘못되면 어떻게하지, 이런 데이터가 꼭 필요할까? 등등,
스스로 의심하고 구현을 꺼려했던 부분이 있었다.
그런데 돌이켜 보니, 개발 환경에서 과감하지 못한다면
언제 과감해 질 수 있을까 싶기도 했다.
고민과 걱정끝에 미뤄둔 것들이 뒤늦게 꼭 필요한 데이터와 기능임을 알게 되고서 리펙토링의 시간은 또 이어지게 되었다.
나의 프로젝트에서 대표적인 사례는 핸드폰과 이메일 인증을 원투원 필드로 빼지 않았다는 점에서 과감하지 못했다.


간과 했던 점

Git의 사용 목적은 효율적인 버전 관리와 협업이지만
중요한 포인트가 기록이 남는다는 점 이다.
팀원들과 항시 소통할 수 있다는점은 언제든 서로의 코드를 리뷰하고 리펙토링 하며 게더와 슬랙을 통해 지속적인 의사 소통을 진행 했는데,
막상 Git을 이용한 의사 소통은 없었다.


웹 소켓과 배포에 대한 지식 부족

기능 구현에만 집중하느라 정작 중요한 포인트를 놓치고 있었다.
팀원들과 나누어진 역할이 분명하다보니 서로의 기능 구현에 있어
이해도가 부족했고, 결국 중요한 웹 소켓과 배포에 관한 지식이 부족하게 되었다.



내가 현재 무엇을 알고, 무엇이 부족한가?

내가 알고 있는 점

  • serializer를 이용한 데이터 직렬화
  • 모델 설계와 AbstractBaseUser를 이용한 유저 모델 설계
  • REST FUL한 API 설계를 위한 views.py 설계
  • 모듈을 이용한 코드 축약과 유지보수성 개선
  • Oauth 2.0의 인증 방식의 이해와, 소셜 로그인 구현
  • EmailMessage를 이용한 이메일 발송 구현

부족한 점

  • AWS를 이용한 배포
  • 웹 소켓
  • 더 효율적인 쿼리셋
profile
더 노력하겠습니다

0개의 댓글