[세미나] 왜 이렇게 코드를 짰을까? 제 코드의 선택과 이유들 (작성중)

작성중인 게시글 입니다. 2024-11-05 진행했던 세미나 입니다.

세미나 특성상 사내 내부 코드가 많이 들어가 있어서, 그대로 올리질 못해 비슷한 예시 코드로 바꿔야하는데 총 90장짜리라 시간될 때 할 것 같습니다. 어쨌든 진행했던 세미나 기록용으로 올려두었습니다.

표지만 우선..

 

 

세미나 개요

  저는 단순히 잘 돌아가는 코드보다, “왜 이렇게 짰어요?” 라는 물음에 답할 이유가 있는 코드가 더 가치 있다고 생각합니다. 물론 때로는 ‘일정이 바빠서요’와 같은 현실적인 이유도 이유가 될 수 있습니다.

이번 세미나에서는 최근 프로젝트를 진행하며 했던 선택과 그 이유를 회고하며, 제가 코드를 작성하며 했던 고민과 선택의 이유들을 공유해보려 합니다.

다소 어려운 얘기가 될 수 있고, 어느정도 개발 지식이 없다면 이해 못하실 가능성도 높습니다. 그럼에도 "어 어디서 들어봤는데?" 느낌만 가져가셔도 좋을거라 생각합니다.

 

- jpa 사용 시 그냥 jpa interface만 있어도 잘 동작합니다. 그럼 제가 굳이 interface로 한번 더 래핑해둔 이유가 뭘까요?

- abstract로 된 추상 메서드를 동일한 클래스 내에서 호출한다니, 너무 구조가 복잡해보이는데 굳이 이걸 왜 한건가요?

- 왜 이렇게 복잡하게 interface가 많은거죠? 그리고 왜 지저분하게 import를 안하고 저렇게 풀 패키지명으로 사용한건가요?

위의 얘기들에 궁금증이 생기신다면 한번 들어보시면 좋을 것 같습니다. 

이외에도 객체지향언어로 왜 절차지향으로 짰나요, 네이밍이 왜 이런가요, 책임의 분리, 불필요한 exception, 테스트 코드와 리팩토링, 아키텍쳐 선택 등 제 ‘선택과 이유’와 관련된 다양한 얘기를 간략히해보려 합니다.

개발에는 정답이 없습니다. 설계는 균형의 예술이고, 모든 선택에는 트레이드 오프가 존재합니다. 트레이드 오프에 대한 고민이 쌓일수록 더 나은 결정을 할 수 있게 된다고 생각합니다.

당연히 세미나에서 제가 하는 말도 틀린 말이 있을 수 있습니다. 또 이해하기 어려우실 수도 있고, 공감하지 못할수도 있습니다. 이번 세미나에서 제 최근 프로젝트 개발시의 고민과 생각을 나누고, 서로의 생각과 사고방식을 넓히는 기회가 되었으면 합니다.