1. 컨벤션

• 클래스 이름
  • DTO, URI, ID같은 약어의 경우 Dto와 DTO가 많이 섞여있음
    • 클래스 이름의 경우 통일이 되어도, 실제 초기화를 할 때 객체 명에 고민이 됨.
    • 처음에는 DTO로 약어는 대문자로 표기해주는게 낫다고 생각했지만, 뭔가 통일성도 낮아지고, 하면서 생각없이 Dto로 만드는 경우가 많음
    • 추가로 ID의 경우 약어임이 명확하지만 워낙 Id로도 많이 써서 이런 단어들이 더욱 혼란을 만듦
• 메소드 이름
  • 메소드의 이름을 명령어 형식으로 동사명사() 형태임은 같지만, 뭔가 의미적으로 애매한 메소드들이 많은 것 같음
• 커밋
  • 나름대로 규칙을 갖고 작성은 하고 있지만, 커밋 제목의 경우 어디까지 표기할 지 고민됨
  • 브랜치를 잘 나누면 될 것 같지만 개발하다 보면 이것 저것 만지게 되다보니 브랜치의 주제와 다른 기능들을 개발하게 됨
• 객체 이름
  • 객체로 초기화를 할 때 의미적인 이름을 할지 어느건 축약시킬 지 고민이 됨

2. 코드 가독성

• 잘 짜여진 코드들을 보고 내 코드를 보니, 전에는 '그래도 이정도면 의미는 알지 않을까?' 했지만, 실제로는 더러워서 짜증이 남
  • JpaRepository로 Entity들을 받고 Response로 넘기기 위해 추가적인 작업이 필요한 경우 이를 서비스 영역에서 따로 다 처리하려다 보니 더러워 짐(Request -> Entity 의 경우도)
    • List로 여러 데이터를 받는 경우 더욱 심함
    • 처리를 어디에 맡길지 잘 정했어야 했을 것 같음. 개발자분은 DTO에서 Entity로 매핑하고, Entity에서 DTO로 매핑하는 메소드, 생성자를 만든 것 같음
  • 몇몇 로직을 Entity에 작성하면 좋을 것 같음

3. 구조?

• 잘 짜여진 코드를 보고 내 것을 보다보니 나름대로 나눠놓았던 영역들의 세부적인 부분의 개념을 놓친 것 같음
  • 개발자분은 Controller에서 Service를 호출해 데이터를 받고 이를 Response로 보내줌
  • 나는 Service에서 데이터를 받아 Response 객체까지 만들어 Controller에 넘겨줌
  • Controller에서 Response를 다루니까 더 깔끔하기도 하고, 상태코드같은 내용을 정하기 좋음

4. Validation

• 파라미터 위변조를 대비해 게시물 수정 요청에 대비해 권한이 있는지 확인해주는 과정 같은 코드들은 어디에 위치시켜야 할 지 모르겠음.
• 일반적인 유효성 검사같은 경우는 @valid 로 처리하긴 하지만, 실제 로직에서 검사를 해야할 경우 잘 모르겠음.
  • ex) 소유주를 알기 위해 실제 데이터의 id값을 확인해야 하지만, id값을 확인하려면 JPA로 데이터를 불러오고 나서 요청값과 비교해야함. 메소드로 통일은 시켜놨지만 안보이게 하고싶긴 함.