Jaime's 기술 블로그

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 단일 책임 원칙 이 원칙의 일반적인 해석은 "하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다." 이지만 실제 의도는 "컴포넌트를 변경하는 이유은 오직 하나 뿐이어야 한다." 입니다. 책임을 하나의 일을 한다라기보다는 변경해야 할 이유로 해석해야 하는 것이죠. 아키텍처에서 이것을 어떻게 적용할 수 있을까요? 컴포넌트를 변경할 이유가 오직 하나라면 어떤 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해 전혀 신경 쓸 필요가 없습니다. 소프트웨어가 변경되더라도 여전히 기대했던 대로 동작할 것이기 때문입니다. 구현하다보면 위 그림같이 됩니다. A는 다른 여러 컴포넌트에 의존하고있고, E는 의존하는 것이 전혀 없..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 개요 계층으로 구성된 전통적인 웹 애플리케이션 구조는 보통 아래 그림과 같습니다. 웹 계층에서는 요청을 받아 도메인(또는 비즈니스) 계층에 있는 서비스로 요청을 전달하고, 서비스에서 비즈니스 로직을 수행한 뒤, 도메인 Entity의 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출합니다. 계층형 아키텍처는 견고하고, 잘 이해한다면 독립적으로 도메인 로직을 작성할 수 있으며, 도메인 로직에 영향을 주지 않고 웹 계층과 영속성 계층을 변경할 수 있습니다. 잘 만들어진 아키텍처는 요구사항의 변화에 유연하고 외부 요인에 빠르게 적응할 수 있게 해줍니다. 반면 계층형 아키텍처는 코드에 나쁜 습관이 생기기 쉽고 시간이 지날수록 점점 더 ..

이 글은 Heinrich Hartmann 님이 작성하신 글을 한국어로 번역한 것을 퍼온 글 입니다. 원문은 여기에서 확인하실 수 있습니다. 글쓰기는 큰 조직에서 영향력을 발휘하는 데 중요합니다. 경력 있는 소프트웨어 엔지니어로서의 글쓰기는 직무 범위를 확장하고 경력을 발전시키기 위해 획득해야 하는 가장 중요한 기술입니다. 글쓰기는 어렵습니다. 많은 소프트웨어 엔지니어들이 글쓰기와 씨름하죠. 저도 개인적으로 문학에 대한 관심이 없기 때문에 글쓰기가 자연스럽지 않았습니다. 저는 긴 글을 써야 할 때 고민하고 미루는데 며칠이나 몇 주씩 고민하고 미루기도 했습니다. 그리고 지금까지도 마감에 맞춰 수준 높은 글을 준비하는 압박감 때문에 악몽에 시달립니다. 이 글은 지난 15년에 걸쳐 제가 보다 생산적인 글을 쓸 ..

본 포스팅은 함께자라기 책을 읽고 작성하였습니다. 애자일 파트에서 감명깊게 본 부분, 다시 찾아봐야 할 것 같은 부분들 위주로 정리하였습니다. 고객에게 매일 가치를 전하라 책에서 애자일을 한 문장으로 압축해서 표현한 문장입니다. 문장을 이루는 단어들은 모두 중요하므로 각 단어에 대해 아래와 같이 질문해 볼 수 있습니다. 고객에게 우리의 진짜 고객은 누구인가? 매일 어떻게 점진적으로 가치를 전할 것인가? 어떻게 보다 일찍, 자주 가치를 전할 것인가? 가치를 무엇이 가치인가? 지금 하고 있는 일이 정말 가치를 만드는 일인가? 지금 가장 높은 가치는 무엇인가? 비슷한 수준의 가치를 더 값싸게 전달하는 방법은? 전하라 가치를 우리가 갖지 않고 고객에게 전달하고 있는가? 고객이 가치를 얻고 있는가? 이런 질문들은..

본 포스팅은 함께자라기 책을 읽고 작성하였습니다. 함께 파트에서 감명깊게 본 부분, 다시 찾아봐야 할 것 같은 부분들 위주로 정리하였습니다. 객관성의 주관성 새로운 개념을 주변에 설득하기 위해 노력하는 분들이 많이 있습니다. 저도 설득하기 위한 입장, 설득 당하는 입장을 모두 경험해 보았습니다. 저를 포함해 설득에 가장 효과적인 것은 객관적인 자료일 것이라고 생각하는 분들이 많이 있습니다. 하지만 책에서는 상대방에 대해 얼마나 이해하고 있는가(주관성)를 이야기하고 있습니다. 누군가에게 예를 들어 설명할 때, 별 도움이 안 되는 주관적이고 추상적인 예를 드는 경우가 있습니다. 그리고 많은 용어들이 주관적으로 해석되고 쓰이기도 합니다. 다른 사람을 설득하기 위해 객관성이 필요할 것이라고 생각하는데 이 객관성..

소스 코드는 여기 있습니다. 문제는 여기 있습니다. Problem Given the head of a linked list and a value x, partition it such that all nodes less than x come before nodes greater than or equal to x. You should preserve the original relative order of the nodes in each of the two partitions. Example 1: Input: head = [1,4,3,2,5,2], x = 3 Output: [1,2,2,4,3,5] Example 2: Input: head = [2,1], x = 2 Output: [1,2] Constraints..

소스 코드는 여기 있습니다. 문제는 여기 있습니다. Problem Given the head of a singly linked list and two integers left and right where left test(ListNode.of(1, 2, 3, 4, 5), 2, 4, ListNode.of(1, 4, 3, 2, 5)), () -> test(ListNode.of(3, 5), 1, 1, ListNode.of(3, 5)) ); } private void test(ListNode given, int m, int n, ListNode expected) { // when Solution reverseLinkedList2 = new Solution(); ListNode actual = reverseLin..

본 포스팅은 함께자라기 책을 읽고 작성하였습니다. 함께 파트에서 감명깊게 본 부분, 다시 찾아봐야 할 것 같은 부분들 위주로 정리하였습니다. 함께 파트에서는 협력 방법을 배우고 수련합니다. 개선 우선순위 조엘 스폴스키가 만든 개발팀 평가 테스트라는 것이 있습니다. 소스 컨트롤을 사용하는가? 한 번에 빌드를 만들어낼 수 있는가? 일일 빌드를 만드는가? 버그 데이터베이스를 가지고 있는가? 새로운 코드를 작성하기 전에 버그를 고치는가? 최신 업데이트된 스케줄이 있는가? 스펙이 있는가? 프로그래머가 조용한 작업환경에서 일하는가? 돈이 되는 한 최고의 툴을 사용하는가? 테스터가 있는가? 채용 면접 때 후보가 코드를 짜게 해보는가? 복도 사용성 테스트를 하는가? 이 테스트는 한 때 많은 인기와 비판을 받았다고 합니..

본 포스팅은 함께자라기 책을 읽고 작성하였습니다. 자라기 파트에서 감명깊게 본 부분, 다시 찾아봐야 할 것 같은 부분들 위주로 정리하였습니다. 실수를 대하는 자세 책에서 소개하는 실수 문화에는 두 가지가 있습니다. 바로 실수 예방과 실수 관리 입니다. 실수 예방은 실수로 가는 경로를 차단하려고 합니다. 이 말을 실무에 대입하면, 수직적인 조직에서 상사가 부하직원에게 "이번에 실수하면 죽어!" 정도가 되겠습니다. 모든 실수를 예방하는 것은 불가능에 가까운 일입니다. 아무리 전문가라고해도 1시간에 평균 3~5개의 실수를 저지른다고 소개되어있습니다. (개인적인 궁금점인데 여기서 말하는 실수가 어떤 것일까요? 개발자로 따지면 실시간으로 오타냈다가 수정하는 것도 포함이 될까요? 전문가가 1시간에 3~5번 저지를 ..

warp는 macOS에서 terminal과 iterm2를 대체하기 위한 강력한 터미널 애플리케이션 입니다. 사실 갈수록 터미널을 사용할 일이 많이 없어지긴 하지만, 아직도 git 명령어나 ssh 접속을 터미널을 이용하는 경우가 많이 있습니다. 전 알게되자마자 다운받아 사용한지 이제 10일정도 되었는데, 간단한 기능 소개와 함께 사용 후기를 남겨보려고 합니다. 설치 방법 brew brew install warp 직접 다운로드 https://app.warp.dev/get_warp 첫인상 이게 IDE야 터미널이야? UI가 정말 이쁘고 기능이 다양합니다. 기존 맥 기본 terminal을 사용하시던 분들은 프로파일 기능 등 부족한 부분을 대신하기 위해 iterm2을 많이 사용하시는데요, 보통 oh-my-zsh을 ..