안녕하세요 😊
제가 아는 내용을 이해하기 쉽고, 재미있게 설명드려 여러분들이 성장하실 때 행복함을 느끼는 개발자 최태현입니다.
(현) 캐치테이블[와드] 소프트웨어 엔지니어
(전) 스타트업 소프트웨어 엔지니어 리드
(전) 배달의민족[우아한형제들] 소프트웨어 엔지니어
(교육활동) Next Step 리뷰어 다수 참여, 공기관 & 스타트업 경진대회 강사 및 멘토, 스파르타 코딩클럽 멘토
한국과학기술원 (KAIST) 졸업
Khóa học
Đánh giá khóa học
- Coroutine trong 2 giờ
- Hướng dẫn dành cho người mới bắt đầu sử dụng Java và Kotlin
- Hướng dẫn dành cho người mới bắt đầu sử dụng Java và Kotlin
- Hướng dẫn dành cho người mới bắt đầu sử dụng Java và Kotlin
Bài viết
Hỏi & Đáp
궁금한게 있습니다.
안녕하세요!! 🙂 질문 주셔서 감사합니다~1 : N 이란 표현은 이해해주셨는데요~~ 이렇게 생각하시면 되어요!A 데이터가 B 데이터 N개와 연결될 수 이으면 1 : N 관계이다.즉, 한 유저는 대출 기록 여러개를 가질 수 있죠반대로 한 유저는 주민등록번호를 반드시 1개만 가질 수 있으므로 1 : 1 관계라고 할 수 있을거에요! 자 다음으로 그게 어떻게 User 객체와 user_id bigint 컬럼과 매핑이 되는지 잘 모르겠습니다라고 해주셨는데요!JPA를 사용하게 되며@Entity가 붙은User 클래스는 테이블과 매핑이 됩니다.객체에서는 long id 로 표현된 데이터가 실제 데이터베이스에는 bigint id 로 저장되는 것이죠여기까지 이해가 되셨다면, 이제 1번 유저가 있다고 생각해 보겠습니다.User 클래스의 id 필드에는 1이 들어 있고, user 데이터베이스 id 필드에도 1이 들어 있습니다. 이 유저가 100번 책과 110번 책 2권을 빌렸다면 대출 기록은 이렇게 생겼을거에요!단순화한 대출 기록 스키마 = (user_id, 책 id)(1, 100) -> 1번 유저가 100번 책을 빌렸다(1, 105) -> 1번 유저가 105번 책을 빌렸다이렇게 되면 유저 테이블에는 데이터가 1줄 들어 있겠고, 대출 기록 테이블에는 데이터가 2줄 들어있겠네요~ ☺ 많은 개념이 동시에 들어오며 1:N 이라는 워딩, 그것이 데이터베이스에서 표현되는 방법론에 대해서 질문 주신 것 같아요! 답변의 흐름을 따라 하나씩 이해해보고, 직접 실행하며 데이터를 확인해보시면 이해가 더욱 잘 되실거에요!답변이 도움이 되었으면 좋겠습니다. 감사합니다. 🙇
- 0
- 2
- 20
Hỏi & Đáp
DTO 관련
안녕하세요! eovnfjfpa님~ 🙂 크~ 많이 물어보시는 질문인데요!살짝 복잡한 내용일 수 있지만, 스프링은 들어오는 문자열 (HTTP Body에 들어 있는 json 이죠!) 을 객체로 변환하는 과정에서 객체의 생성자를 필요로 합니다!그리고 어떤 생성자가 필요한지는 스프링 버전에 따라, 객체 필드 수에 따라 조금씩 다르더라고요... 😅때문에 개인적으로는 기본 생성자 (= 아무것도 받지 않는 생성자) 를 항상 넣어주는 편입니다. lombok을 사용할 경우 @NoArgsConstructor 를 항상 붙이는 것이죠~ 자바 17이 넘어가게 되면서는 record class가 등장해 record 클래스를 사용하면 조금 더 쉽게 대응이 되는 편입니다. 또 궁금한 점 생기시면 언제든 편하게 질문 주세요~ 감사합니다.
- 0
- 2
- 20
Hỏi & Đáp
궁금한게 있습니다!
안녕하세요~ eovnfjfpa님~ 🙂 현업을 기준으로 말씀드리면, "이 정도는" 미리미리 분리해서 구현하는 편입니다!제가 "이 정도는" 이라고 강조한 이유는 Layered Architecture 혹은 어떠한 디자인 패턴에 대한 이해는 보통 실무자 간의 이해도가 모두 존재하기 때문에 시작부터 각 클래스에 대한 역할을 적절히 정의하고 코드를 작성할 수 있기 때문입니다.반대로, 낯선 패턴을 적용해야 하거나, 코드를 작성 하다 보니 코드가 길어져 유지 보수성이 떨어지는 경우는 "리팩토링"을 통해 코드를 재배치 하곤 합니다. (이런 경우는 꽤 자주 일어납니다!)답변이 도움이 되었으면 좋겠습니다. 감사합니다. 🙇
- 0
- 2
- 21
Hỏi & Đáp
35강에서 returnBook 에서 userLoanHistory 값 중복에 관하여
안녕하세요!! ☺ 커디널스님! 정말 좋은 질문이시네요~ 항상 이와 비슷한 질문이 들어올 때마다 훌륭한 수강생을 만난 것 같아 기분이 좋습니다.AI 인턴이 답변해준 것처럼 아래 글을 함께 보시면 더 좋습니다.- 35강 책 대출 반납 기능 리팩토링과 지연로딩 적용 후의 문제 결론부터 말씀드리면, 한 사람이 이미 같은 책을 빌렸고 반납한 기록이 있다면 중복으로 잡힙니다.는 위 로직에서 고려되지 않은 로직입니다.이와 비슷하게한 책이 2권 이상 존재하는 경우도고려되어 있지 않습니다. 어떠한 로직을 볼 때 어떤 요구사항까지 반영되어 있고, 어떤 요구사항이 반영되어 있지 않은지를 확인하는 것은 매우매우 좋은 습관이라고 생각합니다. 동시에 반영되지 않은 요구사항을 구현할 때는 어떤 변경이 어느 정도의 비용 (= 소요 시간) 으로 필요할까 생각해보는 것도 좋습니다. ☺예를 들어, 말씀해주신 것 한 사람이 과거에 빌린 책을 다시 빌린 후 반납한다면, returnBook 에서 단순히 책의 이름으로 특정 Book 객체를 찾는 것이 아닌, 책의 이름과 상태를 함께 고려하도록 변경되어야 하고 이는 5분 내외의 짧은 비용이 들겠네요~ 답변이 도움이 되었으면 좋겠습니다. 감사합니다. 🙇
- 0
- 2
- 25
Hỏi & Đáp
질문있습니다!
안녕하세요!! eovnfjfpa님~ 오~~ 좋은 질문입니다!! ☺제 생각에는 정말 비슷하면서도 약간 다른 것 같아요!API : 프로그램 간 정해진 약속을 해서 정해진 기능을 수행하는 것프로토콜 : 시스템 (혹은 프로그램 보다 더 큰 단위) 에서 어떠한 규칙을 정해 그 규칙을 각자가 수행하는 것과 같은 느낌인데요... 프로토콜이 훨씬 더 큰 영역에 적용되는 규칙/규약 이라고 봐주시면 될 것 같습니다. 약간.. 프로토콜은 도로교통법, API는 버스 정류장 노선 같은 느낌이랄까요~~답변이 도움이 되었으면 좋겠습니다. 감사합니다! 🙇
- 1
- 1
- 21
Hỏi & Đáp
자바와 코틀린의 함수형 프로그래밍,
안녕하세요~ 나구리님! 🙂 좋은 질문 감사합니다.자바는 '일급 시민이 된 것 처럼' 동작하도록 함수형 인터페이스를 통해 함수형 프로그래밍을 할 수 있게 된 것이지 근본 자체가 일급 시민이 아니라는 말씀이신건지가 궁금합니다..이라고 표현해 주셨는데요! 표현해주신 내용이 정확합니다.자바는 함수형 프로그래밍을 사용하기 위해 interface를 활용했고, interface의 구현체는 class로 함수와는 엄연히 다르게 취급된다고 할 수 있습니다. 즉, 함수형 프로그래밍이 가능은 하지만, 함수가 1급 시민은 아닌 셈이죠~중요한 내용은 아니라고 생각하실 수도 있지만, 이런 차이를 정확히 이해하면 코틀린에만 존재하는 inline function, noinline 등이 왜 등장하게 되었는지도 쉽게 이해하실 수 있을 것 같아요! 간략히만 말씀드려 보면 다음과 같습니다. 🙂JVM은 함수를 일급 객체로 보지 않는데, Kotlin은 함수를 일급 객체로 보면서도 JVM level에서 돌아갈 때는 함수형 인터페이스로 .class 파일이 만들어 져야 한다.이를 위해 Kotlin이 컴파일 될 때 함수는 FunctionN 이라는 특수한 타입으로 컴파일 되는데 이는 결국 class의 method 호출을 의미한다. (= 약간의 오버로드)따라서 오버로드를 완전히 줄이기 위해 진짜 함수 그 자체를 사용 지점에서 사용하고 싶다면 inline 키워드를 붙여 .class 파일이 만들어 질 때 함수 구현체 자체를 붙여 넣게 되고상황에 따라 inlining 하고 싶지 않은 경우는 noinline 키워드를 사용하게 된다. 답변이 도움이 되었으면 좋겠습니다. 또 궁금하신 내용 있으시면 언제든 편하게 찾아주세요~ ☺ 감사합니다.
- 1
- 1
- 27
Hỏi & Đáp
38강 editConfiguration에 active profiles 가 없어요
안녕하세요! 커디널스님~ 🙂아마 Community 버전을 사용하고 계시는 듯 합니다.이 경우https://lucas-owner.tistory.com/22https://jojoldu.tistory.com/547와 같은 블로그를 확인해서 profile을 설정해 주시면 됩니다! Ultimate 버전과 Community 버전의 방식 차이가 있어서요~감사합니다. 🙏
- 1
- 1
- 20
Hỏi & Đáp
플랫폼 타입 설명 문의
안녕하세요! 🙂 다행히 이전 답변을 보고 해결 되셨군요! 다행이네요~이렇게 어떠한 자원을 한 곳으로 모아 관리하는 기법은 꼭 언어 레벨이 아니라 DB 레벨, 컴포넌트 레벨 등 다양하게 사용되는 패턴입니다.언제든지 또 궁금한 점 생기시면 찾아주세요~ 감사합니다! 🙇
- 2
- 2
- 24
Hỏi & Đáp
application.yml파일에 작성한 username과 password는 암호화 안해도 되나요?
안녕하세요! ennno님 🙂 네 비슷합니다!아마 강의에서도 구두로 언급 드렸을 텐데요! 실제 실무를 진행하실 때에 application.yml 에 들어가는 주요 정보는외부 암호 저장소 (ex. AWS Secrets Manager)를 사용하는 것이 좋습니다. 암호화를 한다고 해도 결국 그 암호화된 문자열 자체가 노출되면 안되기에 외부 암호 저장소를 사용하는 편입니다. 물론, 현실적으로 private github repo를 쓰는 경우 회사 규모가 어느정도 되기 전까지 외부 암호 저장소를 사용하지 않고 암호를 코드 파일에 바로 쓰는 경우도 있습니다.답변이 도움이 되었으면 좋겠습니다. 감사합니다. 🙇
- 0
- 2
- 33
Hỏi & Đáp
DTO 관련 질문
안녕하세요! 이번에도 좋은 질문이시네요~ 🙂본격적인 답변을 드리기 앞서 모든 것은 trade-off (장점과 단점이 공존) 이며 상황에 맞는 적절한 방법을 쓰는 것이 중요하다는 말씀드립니다. DTO를 용도에 따라 다르게 만드는 이유는 유지보수를 보다 잘 하기 위해서 입니다.예를 들어 데이터를 생성하는 요청이나, 데이터를 변경하는 요청이 지금 당장은 매우 비슷해 보여서 중복된 코드를 제거하는 것이 중요해 보일지 몰라도, 시간이 지나며 데이터를 생성할 때 필요한 데이터와 데이터를 변경할 때 필요한 데이터가 조금씩 달라지게 되면 결국 의미를 알 수 없는 객체가 되어버리는 경우가 많거든요!예를 들어 최초에 유저 생성, 수정에 이름만이 필요했다고 해보죠. 그러면 두 경우 모두 이름만 있으면 되니까..public class UserRequest( private final String name; )처럼 만들고 싶을 수 있습니다. 자 그런데 시간이 지나며 생성 과정에서는 "이메일"도 받는다고 해봅시다. 그러면 데이터 수정할 때는 이메일이 없으니 nullable email이 생깁니다.public class UserRequest( private final String email; // 없어도 된다 private final String name; // 있어야 한다. )이렇게 필드가 하나 둘 생기다가 5개, 10개, 15개를 넘어가면public class UserRequest( private final String f1; // ? private final String f2; // ? private final String f3; // ? private final String f4; // ? private final String email; // ? private final String name; // 있어야 한다. )이 필드들은 도대체 언제 쓰이는건지, 언제 값이 있고 언제 값이 없는건지, 반드시 필요한 경우는 언제이고 선택적으로 쓰이는 경우는 언제인지, 어떤 역할을 하는건지 파악하기가 점점 어려워집니다. 때문에 이럴거면 처음부터 다른 사용처에 대한 DTO를 분리해서 명확하게 그 객체를 표현하는 것이 유지보수를 하는데 좋은 경우가 많습니다. 🙂 또한 이렇게 각 상황에 따라 DTO를 나누는 것 외에도 DTO, Model, Entity 등 객체의 계층에 따라 class를 나누는 것도 중요한데요, 이는 https://youtu.be/OV8e88kIU-U?si=fdnSUHSJY_RDYCJw를 한 번 봐주시면 감사드리겠습니다. ☺감사합니다. 🙇
- 0
- 2
- 31