WOONY's 인사이트

Intro 와..진짜 어떻게 지나가는 줄 몰랐던 한 달이었다. 일적인 면에서도, 사적인 면에서도 많은 일들이 있었다. 잠깐 짚어보면 회사 관련 백엔드 엔지니어 신입 3명(모두 정글 4기!)이 회사에 입사했다. 후임이라 하기엔 나 역시 쪼렙이기에..민망하지만, 이들에게 우리 회사를 선택하는 것에 후회가 없을 것이라 설명회에서 떵떵거리며 말한 것에 대한 책임을 지기 위해서라도 한층 마음가짐이 달라졌다. 매일 혼자 밤늦게까지 씨름하며 고민했던 내용들을 이들에게 잘 전파해줘야겠다는 사명감이 생겼달까. 더 잘해야지. CTO 스쿼드 TF에 합류해 신입 분들과 2인조로 잠시 함께 일하게 됐다. 이제껏 사실상 혼자 일하다 밑에 누군가를 같이 챙기며 일하게 되니 책임감이 막중해졌다. 일도 잘 끝내야 하고, 이제 막 들어..

2장 - 의미 있는 이름 들어가면서 이름 잘 지으면? 여러모로 편하다는 걸 명심할 것. 여기서는 이름을 잘 짓는 규칙 몇 가지에 대해서 알아보도록 하자. 의도를 분명히 밝혀라 의도가 분명한 이름이 정말로 중요하다. 더 나은 이름이 떠오르면 개선해야 한다. 모든 클래스의 이름은 아래의 질문에 답변해야 한다. 변수/함수/클래스의 존재 이유는? 이들의 수행 기능은? 사용 방법은? 이때 주석이 필요하다면 -> 변수명을 제대로 짓지 못했다는 것(의미를 잘 반영하지 못했다는 것이니)! 예시를 보자. int d; // 경과 시간(단위: 날짜) d에는 어떤 의미도 없다. 측정하려는 값과 단위를 표현하는 이름이 필요함. int elapsedTimeInDays; // 날짜에서 잰 시간 int daysSinceCreatio..

Introduction 지난 주 카카오 화재 사건으로 티스토리까지 먹통이었다. 이를 변명삼아 복구되면 2주차 써야지..하던 게 결국 3주차 회고에 얹어서 쓰게 됐다. 이를 더 깊이 파고들어보면, 원인은 회고를 쓸 때마다 "이거 언제 다 쓰나.."하는 부담이 생기기 때문이다. 이를 위해서라도 회고글은 최대한 짧게 쓰는 것을 기본 원칙으로 삼아야겠다. 이번 회고부터 큰 변경사항 하나가 추가됐다. 바로 기존 프레임워크였던 KPT(Keep/Problem/Try) 회고에서 → KLT(Keep/Learn/Try) 회고 프레임으로 변경한 것. 회사에서는 이슈가 발생한 것이니 Problem을 써도 별 이상하지 않지만, 개인 관점에서 Problem을 쓰면 "난 늘 문제가 있는 사람"이라는 프레임이 알게 모르게 발생한다...

Introduction 같은 회사 동료분과 이야기 나누다가 한 가지 질문을 받았다. 자바에서는 빈 문자열과 null의 크기를 어떻게 정할까요? 어라. 한 번도 생각해보지 못했다. 빈 문자열이면 당연히 크기가 0이지 않나? 하겠지만 데이터의 크기가 0이면 애초에 표시 자체를 할 수 없으니 말이 되지 않다. 그 자체를 표현하기 위한 데이터의 크기가 분명 존재할 것인데, 자바 자체적으로 정해놓은 크기가 있을 것이다. 1. 빈 문자열의 크기는 얼마나 될까? 찾아보기 전에 직접 테스트를 돌려보자. String 객체를 생성하기 전후로 힙 메모리의 용량 변화를 출력하는 코드이다. (아래 코드는 해당 링크에서 가져왔다. 사이트에서 말하는 결과값은 예전 자바 버전이라 요즘과 결과가 다르니 코드만 참고할 것.) publi..

Introduction 오랜만에 쓰는 주차 회고 글. 확실히 트래킹을 주 단위로 짧게 가져가는 게 더 좋다. 이번주에는 주중에 크게 약속이 없어서 월-목 모두 11시까지 충분히 공부하는 시간을 가졌다. 글 역시 쌈빡하게 썼다. 저번부터 예제 코드만 짜두고 미뤄두고 있던 내용이었는데 이번에 털어내니 속이 다 시원하더라. 이번주에 한 것들은 아래와 같다. 9월 월간 회고 Spring Controller에서 String -> 날짜 타입 자동으로 변환하기 서치 기능 작업 완료(PR) Keep 다시 제대로 쓰기 시작한 데일리 회고 & 리포트 아아주 바람직하다. 역시 환경설정의 힘이란..포스트잇 하나 붙였다고 중간마다 데일리 리포트를 더 의식하면서 쓰게 되더라. 목적이 명확하니 저걸 봤을 때 핑계댈 게 없다. 앞으..

Introduction 모든 예제는 github에 올려뒀습니다 예전에 했던 작업에서 클라이언트로부터 날짜값을 받는데 쓰는 requestDTO를 만들었다. 날짜값이 클라이언트로부터 String 타입으로 들어오기에 requestDTO에서는 String으로 받고 서비스 로직에서 String을 LocalDateTime으로 변환하도록 로직을 짰다. UpdateDateRequestWithString package com.woony.core.domain.request; import lombok.AllArgsConstructor; import lombok.Getter; import lombok. import lombok.NoArgsConstructor; @Valid @Getter public class UpdateDa..

Introduction 9월도 잘 놀면서 보냈다. 잘 일했는지는 글쎄..확실히 월간 회고만 쓰니 주간에 뭘 했는지 잘 트래킹이 안 된다. 이번주부터 무조건 주간 회고 작성 시작한다. 하면 한다. 반성 및 체크해야 할 점을 몇 가지 블로그에 글 쓰는 횟수가 줄어드는 게 보인다. 위험 신호인데 이거. 다시 주간 회고 글부터 올리기로 바꿀 필요가 있다. OKR 내용도 수정이 필요해보인다. 6월 경에 세웠던 하반기 OKR과 현재의 방향성이 달라졌기 때문이다. 저번 8월 월간 회고에도 썼듯, 요즘은 실무 작업 중에 만난 이슈를 깊게 파고 드는 식으로 공부하고 있다. 특정 커리큘럼을 따라가지 않고 있다. 요 두 가지 유의하면서 KPT 회고를 작성할 예정. 9월 Try 체크 뽀모도로 타이머 구매 구매는 완료했으나 실..

Introduction 지난 시간에는 트랜잭션의 개념과 어떨 때 트랜잭션을 사용해야 하는지에 대해서 배웠다. 그런데 1부에서 얘기했던 것과 같이, @Transactional을 제거했더니 Exception이 발생했다. 이 문제는 어떻게 해결할 수 있을까? 다시 코드를 살펴보도록 하자. Code UserController @PutMapping("/user/{Id}") public void moveDateTime(@PathVariable long userId) { userService.moveDateTime(userId); } UserService public void moveDateTime(long userId) { Timestamp targetDateTime = Timestamp.valueOf(ZonedD..

1. 끝날 때까지는 끝난 게 아니다. 회사 접어야 할지 고민할 때 인생 다 망한 것만 같았다. 어떻게 얻은 기회인데 이렇게 놓아도 되나 싶었다. 웬걸 지금은 정말 잘살고 있다. 포기해야겠다고 생각할 때 결심한 게 하나 있었다. “지금은 IT 비즈니스에 대한 이해도가 부족하니 충분히 배우고 다시 도전하자. 세일즈랑 비즈니스는 잘할 자신 있으니 장벽이 높은 것부터 먼저 해보자. 그러니 개발자부터 해야겠다.” 얼마 전에 이 마음 먹은 지 정확히 일 년이 지났고, 코딩 한 번 제대로 해보지 않았던 사람은 지금 개발자를 하고 있다. 여전히 많은 날이 남아있었고, 끝날 때까진 끝난 게 아니었다. 2. 인생은 게임처럼 임하자. 디자이너가 되고 싶을 때는 패션을 공부했고, 전공에서 제대로 해보자고 생각했을 때는 대학원..

Introduction 현재 작업 중인 프로젝트와 관련해 올렸던 PR에서 아래와 같은 리뷰를 받았다. Can you do it without getting @Transactional? @Transactional is not cheaper. Please think about why we use Transaction on RDBMS DB. 왜 이런 말이 나오게 됐을까? 먼저 원래 코드부터 살펴보자. 유저의 필드 중 하나인 날짜를 특정 시점으로 수정하는 API이다. 내부 코드를 공개할 수 없기에 간단한 형태로 수정했다. Code UserController @PutMapping("/user/{Id}") public void moveDateTime(@PathVariable long userId) { userSer..