반응형 전체 글98 [스프링] 트랜잭션과 스프링의 @Transactional 스프링에서 데이터베이스와 관련된 처리를 하는 작업을 진행하다 보면 @Transactional 어노테이션을 사용하게 된다. 한번 알아보도록 하자. 트랜잭션(transaction)이란? "Transaction" 는 사전적 의미로 "거래", "매매", "처리(과정)" 이라는 의미를 가지고 있다 (네이버 사전). 일반적인 "거래"를 생각해보면 내가 무언가를 얻기 위해서는 무언갈 주어야 한다. 예를 들어, 사과 하나를 사기 위해서는 일정 금액의 돈을 지불해야 한다. 돈은 지불하지 않은 상태에서 사과만 획득하고 거래를 마칠 수는 없다. A 가 돈을 지불하고, B 는 그 돈을 받고 A 에게 사과를 건내 준다 까지 성공적으로 완료되어야 "거래"가 성사된다. 데이터베이스에서도 트랜잭션은 데이터베이스와 관련된 하나의 논리.. 2023. 2. 2. [스프링] @NotEmpty, @NotBlank, @NotNull 비교하기 API 를 작성하다보면 요청을 받는 DTO 에 대한 유효성 검증을 해야한다. 값이 없어도 되는 필드가 있는 반면, 값이 꼭 필요한 필드가 있다. nullable 에 대한 유효성 검증은 다양한 방법으로 할 수 있는데, Controller 레벨에서 조건문을 활용할 수도 있고 Objects 또는 Collections 의 유틸 함수를 활용할 수도 있다. @NotEmpty, @NotBlank, @NotNull 라는 표준 Validation 을 활용할 수도 있는데, 유사하지만 다른 역할을 하는 3개의 Validation 에 대해 정리해보고자 한다. Bean Validation Bean Validation 자파 기술 표준으로 유효성 검증 어노테이션과 인터페이스의 모음이다. 이 인터페이스 모음을 구현하여 우리가 자주 .. 2023. 2. 2. [협업] 프론트엔드 개발자와 협업하기 위한 API 스펙 백엔드 개발자 입장에서 프론트엔드 개발자와 효과적으로 협업하기 위해서는 API 스펙을 미리 작성해서 공유하는 것이라 생각한다. 프로젝트를 진행하다 보니 이런 부분은 선택이 아닌 필수여야 한다고 생각이 들어 정리해보고자 한다. API 스펙을 만드는 목적은 무엇인가? 왜 API 스펙을 만드는지를 먼저 생각을 해보면: 백엔드+프론트엔드 개발자가 플래닝한 결과에 대해 서로 같은 페이지 (on the same page) 에 있는지 확인하기 위함 백엔드+프론트엔드 개발자가 작업에 대한 소통을 할 때, 레퍼런스가 되는 문서가 필요하기 때문 플래닝 이후에 도출된 세부 작업들을 백엔드는 백엔드끼리, 프론트엔드는 프론트엔드끼리 작업을 하고 나중에 한꺼번에 연동을 해도 되지만, 그렇게 되면 비용이 엄청 비싸진다. 그래서 미.. 2023. 2. 1. [회고] 백엔드 개발에 대한 원데이 클래스 후기 들어가며 광운대학교 정보융합학부에 계시는 박규동 교수님의 학생들과 함께 원데이 클래스를 진행했습니다. 오랜만에 대학생들과 함께 시간을 보내다보니 왠지 모를 학생들의 열정을 느낄 수 있어서 너무 좋았습니다. 원데이 클래스를 진행한 이유 저는 제가 알고 있는 정보를 남에게 알려주고 가르쳐주는 것을 좋아합니다. 누군가가 제가 알려준 정보로 도움이 된다면 그것 자체로 즐겁습니다. 또 저 스스로가 어떤 내용에 대해 충분히 이해하기 위해서는 누군가를 가르쳐주는 과정에서 꼭 필요하고, 더 많이 배우게 된다고 생각합니다. 학부생활과 대학원 생활을 하며 취업을 해본 경험이 있는 저로써는 막상 준비할 때 어떻게 뭐부터 준비를 해야할 지 감이 잘 안왔습니다. 그래서 취업을 목표로 준비 중인 학생들에게 현재 개발자들은 어떻게.. 2023. 1. 30. [회고] '왜'가 왜 중요할까? 들어가며 회사 생활을 이어가다 보면 자연스럽게 그 문화에 익숙해지기 마련입니다. 처음에는 낯설게 느껴지지만 어느덧 적응을 하다보면 매일 반복되는 업무의 연속입니다. 개발자들도 똑같습니다. 매일 아침 "스크럼" 이라는 회의를 통해 전날 무엇을 했는지, 오늘은 무엇을 할건지, 특이사항은 없었는지에 대해 공유합니다. 프론트엔드 개발자들과 소통하기 위해 API 스펙 문서를 작성하고 새로운 비즈니스 요구사항에 대해 논의하기 위해 미팅도 참석합니다. 코드 작업을 하고, 테스트 케이스를 작성하고, 개발존에서 테스트까지 하고 배포를 합니다. 중간에 코드 리뷰도 받습니다. 가끔 이렇게 쳇바퀴같은 일상을 살다보면 내가 이 프로젝트를 왜 하는지, 이 업무가 왜 중요한지, 목적을 잊어버릴 때가 종종 있습니다. How, Wha.. 2023. 1. 29. [회고] 귀찮은 회의록은 왜 작성해야 할까? 회의는 회의록까지 작성해야 정말 끝이 난다. 들어가며 직장 생활은 정말 회의로 시작해서 회의로 마무리된다고 해도 과언이 아닌 것 같습니다. 백엔드 개발자로 일하고 있지만 코드를 작성하는 시간보다 작업 내용 공유, 아이디어 정리, 프로젝트의 방향성 등에 대해 논의하는 시간이 훨씬 더 많을 때가 있습니다. 회의에 쏟는 시간은 연차가 쌓임에 따라 더 많아지는 듯 합니다. 회의를 한 직후에는 어떤 이야기를 했는지 명확히 기억이 나지만, 나중에 돌이켜보면 막상 무엇을 이야기했는지, 무엇이 핵심 포인트였는지 기억이 잘 나지 않았습니다. 이 부분을 개선해보고자 최근에 진행한 프로젝트에서는 회의록 작성에 에너지를 많이 쏟아보았는데 느낀 점에 대해 공유해보고자 합니다. 어떤 스타일의 회의? 최근에 진행했던 프로젝트에서는.. 2023. 1. 29. [회고] velog 에서 tistory 로 옮겨온 이유 기술 블로그 작성을 위해 velog 에서 시작을 했습니다. 작년 하반기부터 조금씩 작성을 한 것 같네요. 깔끔한 velog 처음에는 velog 가 깔끔하고 마크다운으로도 작성하기가 편리해서 지속적으로 작성을 했습니다. 코드도 잘 정리가 되고, 작성하는 글을 바로 미리보기 기능을 통해 확인할 수 있었습니다. 20-30개의 글을 작성하다보니 과연 다른 사람들이 저의 글을 읽고 어떤 생각이 들까? 도움은 되는 글을 작성하고 있는걸까? 와 같은 생각이 들었습니다. 조회에 대한 통계가 아쉬웠던 velog 전체적인 통계를 확인해보고 싶었는데, velog 는 현재 각 포스트에 대한 조회수만 확인할 수 있었습니다. 그러다 예전에 활용하고 있었던 tistory 가 있다는 사실이 기억이 났고, tistory 에서 다시 기.. 2023. 1. 29. [회고] 기술 블로그를 작성하게 된 계기 교학상장: 가르치고 배우면서 서로 성장한다. 2022년 4분기쯤 이런 생각이 문득 들었습니다. 대학원을 졸업하고 개발자로 회사 생활을 시작한지도 벌써 5년차가 되었는데, 막상 되돌아보니 회사 생활만 열심히 했지 정작 그 기록이 남아 있지 않아 많이 아쉬웠습니다. 나름 공부도 꾸준히 하고, 열심히 살았다고 생각하지만 어디까지나 그건 제 생각인거고 증명할 수 있는 근거와 데이터가 부족했습니다. 점점 연차가 쌓이면서 동료들에게 자신있게 아는 개념에 대해 설명할 수 있어야 하는데 활용은 할 줄 알지만 세부 개념에 대해서 설명하기가 힘들었습니다. 3년차쯤 이직을 위해 면접을 보았는데, 스프링에 대해 전혀 설명하지 못하는 스스로를 보며 많이 부끄럽고 부족하다고 느꼈습니다. 그 뒤로 공부를 꾸준히 하면서 PPT 나 .. 2023. 1. 29. 이전 1 ··· 9 10 11 12 13 다음 반응형
