Jaime's 기술 블로그

이 포스팅은 프로그래머의 뇌를 읽고 작성하였습니다. Overview 코딩 중에 발생하는 다양한 혼란의 방식과 그 차이점을 이해하고, 코딩에서 작동하는 세 가지 인지 과정을 비교합니다. 그리고 이 세 가지 인지 과정들이 어떻게 서로 보완적으로 작동하는지 이해합니다. 프로그래밍을 하다 보면 늘 혼란이 일어납니다. 새로운 언어나 개념 또는 프레임워크를 배울 때 지레 겁부터 먹는 경우도 있습니다. 익숙하지 않은 코드, 자신이 오래 전에 작성한 코드를 다시 확인할 때, 그 코드가 왜 그렇게 작성되었는지 이해가 안 갈 수도 있습니다. 또는 새로운 도메인에서 일을 시작할 때 새로운 용어나 누적되며 쌓여온 히스토리 때문에 파악이 어려운 경우도 있습니다. 이런 혼란을 필요 이상으로 오래 가져가면 안 되겠죠? 따라서 책에..

소스 코드는 여기 있습니다. 문제는 여기 있습니다. Problem Given a list of strings words and a string pattern, return a list of words[i] that match pattern. You may return the answer in any order. A word matches the pattern if there exists a permutation of letters p so that after replacing every letter x in the pattern with p(x), we get the desired word. Recall that a permutation of letters is a bijection from letter..

소스 코드는 여기 있습니다. 문제는 여기 있습니다. Problem Given an array of integers nums sorted in non-decreasing order, find the starting and ending position of a given target value. If target is not found in the array, return [-1, -1]. You must write an algorithm with O(log n) runtime complexity. Example 1: Input: nums = [5,7,7,8,8,10], target = 8 Output: [3,4] Example 2: Input: nums = [5,7,7,8,8,10], target = 6 ..

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