22년 10월 1주차 회고

Introduction

오랜만에 쓰는 주차 회고 글. 확실히 트래킹을 주 단위로 짧게 가져가는 게 더 좋다. 이번주에는 주중에 크게 약속이 없어서 월-목 모두 11시까지 충분히 공부하는 시간을 가졌다. 글 역시 쌈빡하게 썼다. 저번부터 예제 코드만 짜두고 미뤄두고 있던 내용이었는데 이번에 털어내니 속이 다 시원하더라.

이번주에 한 것들은 아래와 같다.

• 9월 월간 회고
• Spring Controller에서 String -> 날짜 타입 자동으로 변환하기
• 서치 기능 작업 완료(PR)

Keep

다시 제대로 쓰기 시작한 데일리 회고 & 리포트

아아주 바람직하다. 역시 환경설정의 힘이란..포스트잇 하나 붙였다고 중간마다 데일리 리포트를 더 의식하면서 쓰게 되더라. 목적이 명확하니 저걸 봤을 때 핑계댈 게 없다. 앞으로도 이렇게만 합시다.

 

Github: 블로그 전용 리포지토리 생성 & ReadMe 작성

 

GitHub - woonys/blog-code

 

이전까지는 블로그 포스팅할 때마다 매번 새로운 리포지토리를 팠어야 해서 여간 귀찮은 게 아니었다. 이번에 그동안 만들었던 예제를 모두 하나의 리포지토리로 옮겼는데 생산성이 더 좋아져서 만족스럽다.

뿐만 아니라, 이전에는 깃허브에는 그냥 덩그러니 코드만 올렸는데 이제는 블로그 포스팅에 쓰는 내용까지 ReadMe로 작성해 같이 올리고 있다. 대표적으로는 요번에 쓴 글인 Spring Controller에서 String -> 날짜 타입 자동으로 변환하기(Feat. @DateTimeFormat 적용 안되는 이유 & JAVA에서 JSON을 변환하는 과정).

 

이렇게 하니 블로그 글을 한 번에 다 써야 한다는 부담감도 사라질 뿐더러 블로그 글 쓰며 공부한 내용까지 커밋으로 올릴 수 있어 확실히 좋더라. 현재 작업 중인 글은 자바에서 null과 빈 문자열("") 데이터의 크기는 얼마나 될까? 인데 이 역시 아직 작성 중인 글을 Readme에 올려두고 있다. 앞으로도 이렇게 계속 해보자.

비즈니스 관점에서 고민하기 & 엔지니어링 관점에서 깊이 있게 공부하기

이번주에 개인적으로 가장 만족스러웠던 내용이었다. 요번에 쳐냈던 피쳐인 대출 심사 엔진 내 룰 검색 기능을 만들면서 작업 전후로 많은 걸 깨달았다.

1. 요구사항을 비즈니스 관점에서 고민하기. “검색 기능”을 만드는 건 추상화된 요구사항이다. 실제로 어떤 문제의식에서 이 요구사항이 만들어졌는지를 알아야 한다. 똑같은 검색 기능이라도 어떻게 구현하느냐에 따라 무엇을 검색하게 할 것인지, 어떻게 생겨야 하는 지 등 UX/UI가 천차만별로 달라지기 때문. 그런 측면에서 풀스택으로 하나의 기능을 통째로 만드는 경험을 계속 하고 있는 것 역시 정말 감사한 경험이다. 사용하는 룰 엔진은 프론트는 AngularJS, 백은 자바/스프링으로 구성되어 있는데, 현재 앞단과 뒷단 모두 작업하고 있는 상황. 자유도가 많이 주어지는 만큼 비즈니스 관점에서 고민해야 할 부분 역시 넓다. 많이 고민할 수 있어서 좋은 경험.
2. 엔지니어링 관점에서 깊이 있게 이해하기. 이번에 검색 기능을 만들면서 LIKE 쿼리의 동작 원리를 심도 있게 공부했다. 공부하면서 “아, 이런 게 깊이 있게 파고드는 것이구나”라는 깨우침을 얻었다. 예컨대 “검색 기능 하나 만들어주세요.”라는 요구사항을 받으면 어찌어찌 방법 찾아서 만들어주고 끝!이 아니라 그 방법은 대체 어떤 원리로 동작하는 거지?를 파고드는 것. 지금 상황이라면
   • 검색 기능은 어떻게 동작하는 거지?
   • 아, LIKE 쿼리로 부분 키워드만 던져도 이를 포함하는 엔티티를 전부 가져오는구나.
   • 그럼 LIKE 쿼리는 어떤 원리로 동작하는 거지?
   이런 식으로 공부하니 훨씬 깊이 있게 이해할 수 있었다.

역시 엔지니어링에서 막상 코딩이 차지하는 비중은 크지 않음을 이번 작업에서 크게 느꼈다. 코딩 전에는 비즈니스 요구사항에 대해 다각도로 고민한다. 코딩 후에는 엔지니어링 측면에서 더 향상할 수 있는 방법을 고민한다. 코딩이 점점 익숙해질수록 전체 작업에서 코딩이 차지하는 비중이 줄어드는 게 느껴진다. 이번에 크게 배운 경험.

Problem

제에발 조급해지지 마라 + 한 번 더 생각하고 행동해라

시니어께서 계속 피드백 주시는 내용이다. 예전보다 나아지긴 했지만 여전히 조급한 감이 있다고. 자꾸 빨리 만들려고 하는데, 그런데 그게 중요한 게 아니라고. 속도가 안 중요한 건 아니지만 그냥 기능 쳐내는 건 조금만 배우면 누구든 다 할 수 있는 일이라고. 그런데 그런 거 시키려고 뽑은 거 아니라고.

조만간 올릴 기술 아티클에 나올 내용이지만, 저번에 작업하던 내용에 순환 참조 관련 이슈가 있었다. 문제는 그 이전에도 동일한 문제를 만난 적이 있다는 것. 사실 한 번 더 고민하고 생각했으면 미리 찾았을 수도 있는 문제인데 빨리 approve받고 싶은 마음에 휘리릭 고쳐서 올렸던 게 화근이었다.

이번 주도 마찬가지. 시니어 분과 TDD로 페어 프로그래밍하는데, 분명 같이 확인하고 만들었던 예상 결과에 대해 내가 짠 코드로 뱉은 결과와 다르다고 예상 결과를 아무 생각 없이 고쳐서 테스트가 pass되도록 변경했다. 다시 생각해보니까 진짜 어이없네.. 사전에 이렇게 나올 것이라고 생각한 값과 실제로 코드로 나온 결과가 다르면 왜 다른지 한 번은 생각해봐야 되는 거 아니냐고..자꾸 손이 먼저 나간다. 하지만 나는 엔지니어다. 엔지니어면 엔지니어답게 결과를 해석할 줄 알아야 하거늘.. 이건 진짜 진짜 반성하고 꼭 고쳐야 한다. 절대 무지성으로 코딩하지 말자.

Try

실수 방지 매뉴얼 작성

• PR 올리기 전에 스스로 먼저 체크해볼 수 있는 체크 리스트를 만들어볼 것.