같이 일하고 싶은 개발자

이번에 정리한 내용은 팀 문화 중 하나인 지식 공유 시간에 Redis에 대해 간략하게 발표한 자료입니다.  [서론]레디스(Redis)를 설명하기에 앞서 캐시(Cache)에 대해서 먼저 간단하게 설명하고자 합니다.범용성 있게 일반적으로 3 tier Architecture의 구조 채택ClientServerDataBase이러한 계층형 구조를 Layerd Architecture(레이어드 아키텍쳐 / 계층형 아키텍쳐 ) 라고 칭함 그러나!!! 윗 구조에서는 명확한 한계점이 존재!바로 서비스가 폭발적으로 성장해 사용자가 많아지고, 실시간으로 요청하는 API 수가 많아짐에 따라 서비스의 부하가 상승하는 경우우리는 아키텍쳐를 분리하거나 캐싱이라는 기능을 사용해 서비스 어플리케이션에서 발생하는 성능의 문제를 해결할 수 ..

[ 목차 ] 들어가기 레이어드 아키텍쳐 장점> 참고 레퍼런스 [ 들어가기 ] 개발자는 어떻게 하면 더욱 코드를 효율적으로 작성하고, 유지보수가 쉽고, 성능이 좋은 코드를 작성할 수있을지 고민을 해야합니다. 이러한 내용을 바탕으로 서비스를 개선하고, 기술이 변하더라도 쉽고 빠르게 대응 가능하고 좋은 코드를 만들 수 있습니다. 이러한 고민속에는 아키텍쳐 설계가 코어로 자리잡고 있다고 생각합니다. 아키텍쳐를 설계하다보면 자연스레 계층과 관련된 레퍼런스를 접할 수 있습니다. 결국 잘 설계된 아키텍쳐를 기반으로 품질이 좋은 코드와 유지보수가 좋은 코드, 유연성 있는 소프트웨어가 나온다고 해도 과언이 아닙니다. 저 역시도 Layered architecture과 같은 내용을 많이 접했습니다. 그래서 과연 Layere..

서론 본론 결론 서론 다들 트랜잭션에 관한 고민을 해보신 적이 있으신가요? 저는 서비스 로직을 짜거나, TestCode를 작성하거나 JPA와 같은 ORM을 사용할 때 트랜잭션에 대한 고민들이 많이 있었습니다. " 어떤 단위까지 한 트랜잭션으로 간주해야 할 까?" " 외부 API를 호출하는 로직에서 만약 트랜잭션을 걸고, 해당 로직에서 문제가 발생하면??" " 만약 A 라는 서비스 로직에서 @Transactional 어노테이션을 추가하거나, 추가 하지 않거나 두 결과값이 어떻게 다를까? " " 그럼 과연 어느 서비스 로직에서는 @Transactional을 추가해야하고, 어떤 서비스 로직에서는 추가하지 않아야 할까? " 이렇게 다양한 고민들이 있었습니다. 오늘은 제가 입사하고 맡은 업무에서 경험한 트랜잭션과..

공부를 하던 도중 궁금한 점이 생겼다. 우리가 DB와 관련된 작업을 하기 위해선 Repository와 Service를 만들어야하는데, 다른 사람들이 작성한 코드를 보면 기능을 Repository에서 구현하기도 하고, Service에서 구현하기도 하는데, 왜 이렇게 구분하는지가 궁금했다. (기존에 나는 service에서 구현) 김영한 님이 말하길 DB에 접근하는 코드는 Respository에 위임하고, Service 패키지에는 비즈니스 로직과 관련된 코드를 위임하는데, 이렇게 구분해두면 비즈니스 로직및 관련 부분에 오류가 발생하면 Service를 확인하고, DB 접근과 관련된 문제가 발생하면 Repository를 확인하면 된다고 한다. 서비스에서 DB계층을 연결하려고 하면 Repository라는 저장소를 ..

서비스를 개발하고 테스트를 할 때, 그 로직이 잘 동작하는지를 확인하는 방법은 다양하다. 그 중에서 나는 보통 출력문 하나를 넣어서 잘 출력이 되는지를 확인하고는 했는데, 이러한 방식은 실무에서 사용하지 않고 사용을 권장하지 않는다. 그래서 출력문이 아닌 별도의 로깅 라이브러리를 사용해 로그를 출력하는데, 이 로깅 라이브러리의 종류가 매우 많다. 그래서 몇 개의 예시를 통해 정리해보고자 한다. @RestController public class LogTestController { // 이 코드는 로그를 선언하는 방법이다. private final Logger log = LoggerFactory.getLogger(getClass()); // 5번라인의 로그 선언 방법 외에도 아래 2개의 방법이 있다. pr..

1. REST API란? REST(Representational State Transfer)의 약자로 '대표적인 상태 전달'이라는 의미를 가진다. 웹과 같은 분산 하이퍼미디어 시스템에서 사용하는 통신 네트워크 아키텍쳐와 비슷한데, 웹은 HTTP 프로토콜을 전송방식으로, URI를 식별 방식으로 사용하며 HTTP는 웹에서 GET, POST, PUT, DELETE 등 메소드를 이용해 정보를 주고받는 프로토콜이다 여기서 REST는 URI의 단순,간결한 장점을 계승한 네트워크 아키텍쳐라 보면 된다. 쉽게 요약해보자면 화면인 HTML을 리턴하는 방식이 아닌 사용자가 필요한 데이터 결과만 리턴해주는 방식이다. URI ? URL? URL : URI의 하위개념으로, 네트워크 상의 자원의 위치를 알려주기위한 규약으로 웹의..

백엔드 개발자를 희망하는 사람들이라면 한 번쯤은 사용해보거나, 어디서 보거나 뭐 어찌저찌해서 관심을 가질만한 부분이다. 바로 의존성(depencency)부분이다. 스프링부트는 gradle, maven과 같은 도구들을 이용해 의존성을 관리하는데, Gradle을 기준으로 의존성 관련해서 정리를 해볼려고 한다. (Maven은 사용하기 뭔가 귀찮았음 XML이, Gradle이 더욱 간단하고, 익숙함.) 1. Gradle? 소프트웨어는 거의 단독으로 작동하지 않고, 다양한 라이브러리의 형태나 모듈들, 프로젝트등이 서로 의존하며 모듈화된 시스템을 구성하기 위해 분할되는데, 이때 종속성 관리를 통해 자동화된 방식으로 프로젝트에 필요한 종속성을 선언, 해결, 사용 하는 기술이다. Gradle은 빌드 자동화 도구 中 1개..

결국 테스트 코드를 작성하는 이유는, 기능이 잘 동작하는지 확인을 하기 위함이다. 테스트 코드는 내가 작성한 로직이나 기능들을 테스트 코드를 통해 잘 동작하는지 확인해보는 것이다. 테스트 코드 작성 전 개발 방식은 보통 1. 코드의 작성 2. 프로그램 실행 3. 테스트 도구를 통해 HTTP 요청 (Postman) = 브라우저를 통해 서버에 접속하고 테스트 대상 메소드를 동작시키는 요청 4. 요청 결과를 System.out.println()을 통해 눈으로 확인. 5. 결과가 이상하면 프로그램 실행을 중지하고 코드를 수정 이런 방식으로 많이 진행 되었는데, 테스트 코드를 작성하게 되면, 1. 코드를 작성 2. 테스트 코드의 작성 후 실행 3. 결과에 따른 동작(코드를 수정한다, 정상 작동하니 다음 로직을 개..

현재 인프런이라는 강의 서비스에 CTO로 계신 김동욱님의 책인 '스프링부트와 AWS로 혼자 구현하는 웹 서비스' 라는 책을 통해 다시 웹 백엔드 부분을 공부하고 있다.(유툽에서 분명히 많이 본 이름이였는데, 아 그분? 하면서 얼굴이 떠올랐다. 그분이 그 분인거 같다....) 책에서는 인텔리제이와, JPA, JUnit테스트, Gradle, 소셜로그인, AWS 인프라로 무중단 배포까지를 망라해 책을 공부하는 독자들에게 지식을 전수해준다. 이 책이 끝판왕 개발 서적은 아니지만 더 깊은 내용을 공부하고 싶다면 다른 책을 찾아봐야한다. (인프런의 김영한-JPA수업 추천) 해당 책은 이미 서버 개발자(주니어 급)를 꿈꾸는 학생 또는 취준생이라면 한 번쯤은 봤거나, 접해볼 만한 책일 것이다. 내가 여기서 얻고자 하는..