기술면접 준비, Product DataAccess 계층 내 유스케이스 추가, 육각형개발자 독서: 아키텍처
오늘은 새로운 한주의 시작임에도 불구하고, 왜 인지 모르게 활기찬 느낌보다는 많이 지친(?) 하루였다. 아무래도 내가 컨디션 조절 및 마인드 컨트롤이 부족했던 것 같다.
나는 책을 보며 심리적인 안정감(?)을 많이얻는 편인데, 이번 독서한 부분은 기술면접에서 이야기 할 수 있는 주제라는 생각이 들면서, 자꾸만 면접과 관련된 생각을 하다보니 책을 읽는다는 느낌보다는 면접준비의 연장선처럼 되어버린 것 같다.
그래도 저녁 이후, 운동을 다녀오면서 조금 많이 지침이 사라졌다. 역시 사람은 육체적으로 움직여야하나보다. 몸도 마음도 활력은 다시 찾은 것 같아 오늘의 TIL을 쓰는 이 순간, 기분이 좋다.
기술면접 준비
오늘은 아직 면접관련된 연락은 오지 않았지만, 앞으로 있을 수 있는 전화면접, 기술면접에 대하여 대비를 하기위해 기술면접 항목을 정리하기 시작했다. 시작 전에는 이전에 계속해서 공부하던 부분들이라서 크게 어렵지 않을 것이라 생각했다.하지만 지금 다시보니, 내가 부족하게 알고 있는 부분이 꽤 많았고 또 정리가 말씀하게 되지 않은 내용들이 많았다.
그래도 내가 부족하고 잘못된 부분이 어디인지 알 수 있다는 것에서 기쁘다. 과거에는 그저 어렵다고만 생각했던 부분이었는데, 과거보다 분명히 성장했는 생각이 들었기 때문이다.(물론 아직 많이 부족하지만...)
무튼 오늘은 이제 내가 면접전에 반드시 알아둬야 할 내용과, 계속해서 공부해야할 영역에 대한 질문 및 답변을 찾아 정리해보았다. 사실 정리라 하기에 부끄러운, 기술면접질문 리스트를 찾고 이에 대한 답변을 복붙해두었다..^^ 반복해서 읽고 수정하겠다는 생각으로 이렇게 해주었다. 그리고 아마도 오늘 많이 지친 원인이 이 부분에 대한 것이 아닐까 싶다.
내가 스스로 질문할 수 있는 부분을 정의하는 것이 생각보다 많은 시간과 기운이 빨려들어갔다. 그리고 이 부분에서 내 스스로 정리가 가장 안되있었구나를 많이 인지 할 수 있었다.
갈길이 정말 멀다.. 분명 힘든 길이 되겠지만, 이 길을 지나고나면 분명 성장할 수 있을 것 같다. 어서 한걸음을 내딛어야겠다.
Product DataAccess 계층 내 유스케이스 추가
오늘은 "Product DataAccess 계층 내, 다양한 Product 의 속성 값을 가지고 조회할 수 있는 유스케이스를 추가한다. #45" 이슈를 마무리 지었다. 사실 아직 PR을 작성하지 못했지만.. 그래도 목표한 작업은 다 완료하였고, PR만 작성하면된다!
Product DataAccess 계층 내, 다양한 Product 의 속성 값을 가지고 조회할 수 있는 유스케이스를 추가한
설명 제품을 좀 더 다양한 조건을 가지고 검색한다. #4 의 기능 구현을 위한 Product DataAccess 계층(영속성계층) 내 해당 유스케이스를 개발한다. 필요에 따라 ProductSearchPersistenceRequest 를 리팩토링 한
github.com
각 계층의 책임이 분명해서인지, 이번 DataAccess 계층 내 유스케이스를 추가하고 테스트를 하는 일은 크게 어렵지 않았다. 물론 내가 잘못알고있던 부분에서는 헤멨긴하지만, 그래도 처음 DataAccess 계층을 작업할 때에 비하면, 많이 나아졌다.
특히 내가 잘못 알고 있었던, Optional 에 대한 부분 및 테스트에 관한 부분은 포스팅으로 정리를 하고 있는데, 아직 완전히 작성되지 않아 비공개로 해두었다.
프로젝트를 통해 새롭게 알게된 내용은 바로바로 기록하고 정리해두었어야하는데, 이전까지는 생각만 하고 행동을 하지 못했다. 앞으로는 내가 겪은 문제를 기록으로 잘 남기는 습관을 들이자!
육각형개발자 독서: 아키텍처
나는 어울리지 않게(?) 아키텍처에 관심이 많다. 프로젝트를 이해하기위해 공부한 코드설계(디자인패턴)을 하다보니, 프로젝트를 근본적으로 이해하기 위해서는 아키텍처를 이해하는 것이 필요하다는 생각에 도달하였고 그 때부터 아키텍처를 공부하기 시작했다.
아키텍처를 공부하면서 실제로 프로젝트를 좀 더 깊게 이해할 수 있었고, 프로젝트의 잠재적인 문제점 및 유저(창고관리자)가 원하던 요구사항을 만족시켜줄 수 있는 방법을 알 수 있었다.
하지만 아키텍처를 공부하면서 좋지못한(?) 이야기를 많이 들었다. "벌써 그걸 공부할 때야?", "지금 그것도 좋은데.." 등 다소 부정적인 이야기를 많이 들었다. 해당 의견들의 공통적인 부분을 고려해본다면, "지금은 그것보다는 리팩토링같은 현재 업무에 적용할 수 있는 것을 공부해" 였던 것 같다. 근데 나는 내 업무에 필요한 것이라 생각하여 아키텍처를 공부한건데, 아이러니했다. 그리고 리팩토링은 다봤단말이다!(지금 기억나는건, 메서드 추출 뿐인것은 비밀이다..)
이를 통해 이야기 하고싶은 것은, 책에서도 이와 비슷한 이야기를 했다.
주니어 개발자와 시니어 개발자를 구분짓는 요소 중 하나로 아키텍처 설계 역량을 꼽을 수 있다. 능력 있는 시니어 개발자가 되고 싶다면 아키텍처도신경써야 한다. - 책의 일부분 -
내가 생각이 꼬인 것일 수도 있지만, 결국에는 "시니어 레벨에 올라갈 때, 아키텍처 설계 능력이 필요하다." 라고 받아들여졌다. 그런데 나는 아무리 생각해도 아키텍처를 이해하는 것이 정말 중요하다고 생각이 드는데.. 왜 다들 이렇게 생각들을 하시는것인지 궁금하다.
아키텍처를 먼저 공부해야 하는 이유
내가 아키텍처를 먼저 공부해야한다는 이유는 다음과 같다.
아키텍처는 도메인의 기능적 요구사항과 비 기능적 요구사항(품질속성)를 고려하여 설계된다.
- 기능적(functional) 요구사항: 시스템이 제공하는 기능 또는 서비스에 대한 기술
- 비 기능적(non-functional) 요구사항(=아키텍처 특성): 시스템 속성이나 시스템에 의해 제공되는 서비스나 기능에 대한 제약사항
이말은 즉슨, "아키텍처를 이해한다면 내가 제공할 수 있는 기능적, 품질적 측면의 한계점을 인지할 수 있다." 이를 통해 신규 요구사항을 개발할 때, 보다 현 상황에 알맞는 선택을 할 수 있다고 나는 생각한다. 또한 이는, "성장(변화)에 따라 언제 아키텍처를 개선해야할 때인지를 명확하게 이해할 수 있다" 나는 생각한다.
단순히 시스템이 고도화되고, 복잡해지면 모놀리식에서 MSA로 서비스를 분리한다. 와 같은 무책임한(?) 이야기가아닌, 기존 아키텍처의 @ 한 아키텍처 특성의 한계점을 극복하기 위해 MSA 혹은 다른 아키텍처로 전환 및 분리한다 와 같은 좀 더 근거있는 판단을 할 수 있게 된다고 생각한다.
다른 이유들을 더 이야기할 수 있지만, 이정도로도 충분히 아키텍처를 먼저 공부할만하다고 나는 생각한다.
오늘은 많이 정신을 못차린 하루였던 것 같아 조금 아쉽지만, 내일 오늘 부족한 부분을 다는아니더라도 많이 채울 수 있도록 좀 더 부지런히 움직여야겠다. 무리하지 않고, 꾸준하게!!
일단, 면접준비 복습하고... 복습하면서 정리하는 글을 작성하고.. PR 작성하고.. main 브랜치 반영하고.. 재밌는 책도 보고.. 운동도하고...할수있다!