전체 글 188

2024년 회고

지금의 회사에 합류한 지 만으로 1년 10개월이 넘어가고 있습니다.벌써 2년이라는 시간을 향해 달려가고 있다고 생각이 들면서 또 한편으로 아직 2년도 안 지났어?라는 생각이 드는 시점인 것 같습니다. 입사하게 된 23년의 한 해보다 24년의 한 해가 무척이나 심적으로 힘들었지만 한편으로는 또 많은 것을 알게 되고 정말 스스로를 되돌아보는 그런 한 해였지 않나?라는 생각이 들었고 많은 것을 배운 그런 한 해였기에 24년도 한 해를 생각을 정리하고 기록하며 털어버리기 위해 회고록을 작성해 봤습니다. 24년 키워드  배움, 스트레스, 개인과 조직 그리고 성장, 같이 일하고 싶은 개발자 그리고 동료 1. 배움 1-1. 갈증23년엔 같이 입사한 동기 중 한 명을 제외하고 같은 팀에 배정이 되었습니다.  같은 직무..

그쪽도 홍박사(Redis)님을 아세요? (1)

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

스프링/백엔드 2024.12.11

[함께 자라기 애자일로 가는 길]

결론 선 공개개인과 팀의 성장의 영양분으로 애자일이라는 방식을 채택했다면 애자일적 사고 방식이 중요하다.애자일을 애자일 다운 방식으로 도입하는 것은 중요하다.본론가을의 냄새가 물씬 풍겨오는 어느 오후였습니다, 팀 동료와 합법적인 월급 루팡??을 하다가 이직과 관련된 이야기가 나왔습니다. 티타임이라 쓰고 합법적인 월급 루팡이라 읽는 현장을 다 같이 보시죠 본인 : 만약에 다음에 이직을 하게 된다면 어떤 도메인으로 가고 싶으신가요?팀 동료 : 가고 싶은 도메인이 특정해 있진 않은데 피하고 싶은 도메인은 있습니다본인 : 혹시 이런 상상 해보신 적 있으신가요? 만약 지금의 회사의 제휴사으로 이직하는 상상...팀 동료 : 해본적 있습니다... 재잘재잘.... 본인 : 우리 회사에 내가 제휴사로 미팅라하려고 온다?..

책 읽기 2024.11.17

[가상 면접 사례로 배우는 대규모 시스템 설계 1권]

취업 후 쉴 새 없이 달려오다보니 어느덧 2년차 백엔드 개발자가 되어 있었습니다.그동안 많은 일들도 있었고 다양한 영역의 지식과 도메인의 지식을 흡수하면서 나름대로 이제 어떤 문제가 발생해도 잘 해결할 수있으리라 생각했습니다.   그러나 개발이라는 거대한 야생에서는 얕은 지식만으로 해결되지 않는 문제들이 정말정말정말 많습니다. 한번은 어플리케이션 영역을 넘어선 인프라적 문제가 발생했던 경험이 있습니다. 당연히 인프라적 인사이트는 저에게 개방되지 않은 미지의 동굴과 같았기에 어떻게 해결할 수있는지에 관한 문제 해결 능력과 경험치가 부족했고 잘 모르는 영역이다보니 생각을 확장하기가 어려웠습니다. 어떻게 하면 조금 쉽고 편하게 지식을 습득하고 내가 가진 궁금증들에 관한 생각들을 확장할 수 있을까?에 관한 답변..

책 읽기 2024.11.02

지피지기 백전불태(부제 : JPA의 오해와 사실)

사내 팀 내 개발 문화를 도입하면서 공유한 내용입니다.  간단하게 어떤 개발문화를 도입했는지에 설명하자면 다음과 같습니다. - 팀원들 개인의 경험 공유 및 지식 나눔으로 매주 목요일 번갈아가며 진행- 발표자는 자유 주제로 팀원들과 소통- 무거운 주제도 괜찮지만 되도록 가벼운 주제로- 다른 개발의 영역이라도 자유롭게 참가 가능- 주 목적은 같이 성장하기 이미 여러 다른 회사들에서는 이러한 개발문화를 도입했을겁니다.이는 팀 내의 역량을 증진하고 더 나아가 발표를 하기 위해, 발표를 듣기 위해 자신의 지식을 점검하며 같이 성장하기에 주 목적이 있습니다   간단한 설명은 이쯤에서 끝내고 발표 준비한 내용을 공유도록 하겠습니다. 목차N+1 문제의 흔한 착각여러분은 Page와 Slice를 아시나요?DirtyChec..

스프링/JPA 2024.10.20

[3] 긴 함수

본 내용은 인프런 - 백기선님의 리팩토링 강의를 듣고 정리한 내용입니다. 1. 짧은 함수 vs 긴 함수 함수가 길 수록 오히려 더 이해하기 어렵다. 그 이유는 긴 함수의 각 각 문장들을 해석하기 위해 에너지를 많이 써야하고 다양한 함수의 네이밍에 사용된 단어들을 해석하는데 사람마다 지식이 달라 다른 방향으로 해석될 여지가 있다. 짧은 함수는 더 많은 문맥 전환을 필요로 한다. "과거"에는 작은 함수를 사용하는 경우 더 많은 서브 루틴 호출로 인한 오버헤드가 있었다. (그러나 "오늘"에서는 미미함 ) 작은 함수에 "좋은 이름"을 사용했다면 해당 함수의 코드를 보지 않고도 이해가 가능하다. 어떤 코드에 "주석"을 남기고 싶다면, 주석 대신 함수를 만들고 함수의 이름으로 "의도"를 표현해보자 해당 내용에 사용..

Language/Java 2024.01.29

[2] Duplicated Code - 중복코드

효율적으로 코드를 짜기 위해선 앞서 설명한 네이밍 관련 규칙들과 중복된 코드를 줄이는 것이 중요합니다. 이번 챕터에서는 중복된 코드를 줄일 수 있는 방법론 들을 설명했습니다. 중복코드의 단점은 코드의 변경 시, 동일한 모든 곳의 코드를 변경해야합니다. 이러한 단점을 개선하기 위해 사용할 수있는 리팩토링 기술은 다음과 같습니다. Extract Funcation ( 함수 추출 ) - 동일한 코드를 여러 메소드에서 사용하는 경우 Slide Statements ( 코드 분리 ) - 비슷하게 생겼지만 완전히 같지는 않은 경우 Pul Up Method( 메소드 올리기 ) - 여러 하위 클래스에 동일한 코드가 있다면 메소드 올리기 1. 함수 추출하기 "의도"와 "구현" 분리하기 의도와 구현? 어떤 일을 하려는지

Language/Java 2024.01.22

[1] 이해하기 힘든 이름

우리는 코딩을 처음 시작하면 변수명, 메서드명, 클래스 명 등등 여러가지 이름을 고민해서 짓기 마련입니다. 당연히 이름을 지을 때, 해당 기능이나 단위 등 명확하고 직관적인 이름을 짓고싶을 것입니다. 그러나 시간이 지나면 왜 이렇게 지었을까? 라는 의문이 들기도 하지만 우리는 그 순간에 최선을 다해서 네이밍을 했을 것입니다. 위에서 발생한 문제를 해결하기 위해 3가지의 리팩토링 기술을 전수해주고 있습니다 1. 함수 선언 변경하기 (Change Function Declaration) 함수 이름 변경, 메소드 이름 변경, 매개변수 추가,삭제, 시그니처 변경 당연히 좋은 이름을 가진 함수는 이름만 보더라도 이해가 가능할 것이다. 그럼 과연 좋은 이름을 찾아내는 방법이란 무엇인가? - 함수에 주석을 작성한 다음..

Language/Java 2024.01.22

@Mappings 사용하기

[ 바로가기 목차 ] 들어가기 알아보기 마무리 [ 들어가기 ] 여러 테이블 혹은 DB에서 데이터를 가져와서 원하는 작업을 하는 방법에는 여러가지가 있습니다. 가져온 데이터를 원하는 형식이나 여러 객체를 하나의 객체로 합치는 일은 매우 흔한 일입니다. 이때 이러한 매핑 작업을 직접 개발자가 하게 된다면 문제가 발생할 수 있습니다. - 코드의 중복 - 생산성 저하 - 실수로 인한 데이터 누락 - 복잡한 로직까지 추가된다면 코드 가독성 저하 이러한 문제를 해결하기 위해 스프링(Spring)에서는 라이브러리를 지원합니다. - Mapstruct - ModelMapper 맵 스트럭트(MapStruct) 와 모델 매퍼(ModelMapper)의 차이점을 간단하게 설명하자면 객체의 생성 방식에 조금의 차이를 가지고 있습..

스프링 2023.12.13

Backend Layered Architecture

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

스프링/백엔드 2023.11.06