Self-diagnosis

프로젝트를 마치며...

• real_world 프로젝를 무사히(?) 마쳤다. 하지만 실무에서 신경써야 할 부분을 모두 반영한 것은 아니다.
  • 왜냐하면 해당 프로젝트의 목적은 RealWorld에 명시된 스펙에 맞춰 구현하는 것이기 때문이다.
• 그렇기 때문에 여기에는 해당 프로젝트에서 아쉬운 부분들을 작성 할 생각이다.
  • 그래야 다음 프로젝트에서는 해당 부분을 인지하고 반영 할 테니까
• 다음 프로젝트는 아마 취업을 위한 포트폴리오가 될 것 같다.
  • 그 전에 먼저 JPA와 Spring Security에 좀 더 알아볼 생각이다.
  • Diagnosis List는 위에서 말한 내용에 대해 학습하며 해당 프로젝트를 다시 확인하고 천천히 추가해 볼 생각이다.
• 분명 첫 프로젝트라 아쉬운 부분이 있을 테지만 다음 프로젝트는 이를 토대로 좀 더 발전했음 한다.
  
  
  

Diagnosis List

해당 프로젝트에서 아쉬웠던 점과 다음 프로젝트에는 적용 할 방향에 적어보자.

TEST 작성

real_world를 진행하면서 계속 아쉬웠던 부분이다.

• 프로젝트 진행동안 계속해서 Postman을 통한 구현 상태를 확인했다.
  • 처음에는 편했지만 계속해서 기능이 늘어남에 따라 해당 조건을 만족하는 데이터를 저장해야하는 것이 불편했다.
  • 물론 DB 초기화 전략을 update로 하면 일부분 편해졌지만 기능 확인시 필요 데이터가 달라지면 결국 말짱도루묵이다.
• 만약 TEST 코드를 작성하면서 개발을 했더라면 구태여 Application을 동작시키지 않더라도 작성 코드에 대해 확인 할 수 있는 부분이 많을 것이다.
  • 오류 -> 수정 -> 오류의 반복을 겪어 본 개발자들이라면 다들 공감 할 것이다.
• 처음부터 TDD(테스트 주도 개발)을 하긴 힘들테니 적어도 추가한 기능에 대해 테스트 코드를 작성하는 습관을 먼저 들이도록 하는 것이 어떨까 싶다.

동시성 문제

현재 프로젝트에는 동시성 문제를 유발 할 요소가 있지만 해당 부분을 방지하는 코딩이 되어있지 않다.

• 작성된 부분을 상당히 고쳐야 할 부분이 있다고 판단
  • 아무래도 고려해야 할 부분이 적지 않다고 생각했기 때문이다.
• 가볍게 건드리기엔 중요한 부분이기도하고 추가적인 학습이 필요하다고 판단
  • 고려해야 할 부분에 대해서 명확하게 인지 후 방지 대책을 구현해야 함

메서드 네이밍

아직 실무 경험도 없고 코딩 경험도 적어서 그런지 메서드 네이밍 작성이 만족스럽지가 않다.

• 관례적으로 사용하는 get, set을 너무 자주 사용하는게 제일 문제
  • 처음에는 괜찮았지만 보면 볼 수록 유의미한 메서드 명이 더 유용하다고 생각이 듬
  • 메서드 이름만 보고도 '아! xxx를 할 때 쓰는 거구나!'하는 생각이들 수 있게 작성해야 할 필요성을 느낌

비즈니스 로직

강의나 개발 블로그 등을 참고 할 때 항상 나오는 용어, 하지만 스스로 느끼기에 해당 용어의 개념이 정립되지 않음

• 한 마디로 '이 부분은 비즈니스 로직이야'하는 강함 느낌을 아직 스스로 느껴보지 못 함
• 개념은 알고 있지만 뭔가...뭔가임
• 추가적으로 더 알아보고 해당 부분에 대해 개념을 정립해 둘 필요가 있다고 판단

DDD (Domain Driven Design)

해당 설계 방법을 사용했지만 장점을 제대로 활용하지 못하는 느낌을 받음

• 해당 설계의 장점을 제대로 이해하고 활용해야 할 필요가 있음
  • 대표적으로 패키지 루트가 있음, 기껏 해당 설계로 구현해두고 루트를 망치는 코딩이 보임