poArlim poArlim

쿠버네티스를 사용하면서 가장 자주 사용하는 명령어는 단연코 kubectl 일 것이다. 이 길다면 긴 명령어를 매번 치기는 번거로울뿐더러, 긴 Pod 이름 등을 매 번 복사 붙여 넣기 하기도 여간 귀찮은 게 아니다.개발 편의성을 매우 중시하는 개발자들을 위해 kubectl 명령어를 좀 더 편하게 사용하기 위해 연구해 보자.1. Alias우선 'kubectl' 명령어의 길이 자체가 너무 길다! 적당히 헷갈리지 않으면서도 짧은 alias를 등록해 두고 사용하자. 보통 'k'를 많이 쓰는 것 같다.현재 등록된 alias 목록을 보고 싶다면, bash 창에 `alias` 명령어를 입력하면 된다. alias를 신규로 등록하는 것 또한 간단하게 alias 별칭='명령어'를 사용하면 된다. (일회성 등록)alias k..

Spring Boot 3.2에 새롭게 추가된 RestClient에 대해 알아보자.spring docs의 RestTemplate에 대한 설명에 위와 같은 NOTE가 추가되었다. Spring 6.1(Spring Boot 3.2) 버전부터는 RestClient가 더 모던한 API를 제공한다는 말이다. 그렇다면 RestTemplate은 사용하면 안 되는 것일까? RestTemplate이 Deprecated 된다?RestTemplate이 Deprecated 된다고 알고 있는 사람이 종종 있는데, 현재 RestTemplate의 JavaDoc에는 그런 말을 전혀 찾아볼 수 없었다. 이 말은 어디서 나온 것일까? 스프링 개발진의 의도를 유추해볼 수 있는 흐름을 찾아보았다.RestTemplate의 Deprecated에 ..

동작 원리와 구조를 간단하게 설명하기 위해, 사물의 특징과 관계를 그림으로 나타낸 것을 모델, 모델을 만드는 것을 모델링이라고 한다. 1. 악마를 불러들이기 쉬운 User 클래스 로그인 사용자를 나타내는 User 클래스는 웹 서비스에서 자주 볼 수 있다. 이러한 User 클래스는 사양 변경이 굉장히 잦아서 여러 문제를 일으키기 쉽다. class User { int id; String name; String email; String passwordDigest; String address; String phoneNumber; String bio; String url; int discountPoint; String themeMode; LocalDate birthday; String corporationNumb..

메서드 설계가 좋지 않으면 클래스 설계가 나빠지고, 반대로 메서드 설계가 좋으면 클래스 설계도 좋아진다. 클래스 설계 방법을 염두에 두고, 메서드를 어떻게 설계하면 좋을지 집중적으로 알아보자. 1. 반드시 현재 클래스의 인스턴스 변수 사용하기 인스턴스 변수를 안전하게 조작하도록 메서드를 설계하면, 클래스 내부가 정상적인 상태인지 보장할 수 있다(3장 참고). 각 메서드는 반드시 현재 클래스의 인스턴스 변수만 사용하도록 설계하는 것을 기본 원칙으로 잡는다. 여기에 각 메서드에 인스턴스 변수를 안전하게 조작하는 로직을 추가하거나, 생성자에는 완전 생성자 패턴을 사용해서 가드를 만들어두면 인스턴스 변수를 안전하게 사용하기 위한 첫걸음을 뗀 것이다. 다른 클래스의 인스턴스 변수를 변경하는 메서드는 응집도가 낮은..

주석은 코드를 더 쉽게 이해하는 데 도움이 되기 위해 작성하지만, 오히려 읽는 사람을 혼란스럽게 만들 수도 있다. 읽는 사람에게 도움을 주어 유지 보수와 변경의 정확성을 높이는 주석 작성 방법에 대해 알아보자. 1. 내용이 낡은 주석 서비스의 사양은 계속해서 변화한다. 하지만, 업무가 바쁘고 충분히 주의하지 않으면 코드가 변경되면서 주석은 변경되지 않는 경우가 생긴다. 이처럼, 정보가 오래되어 구현 상태를 제대로 설명하지 못하는 주석은 내용이 낡은 주석이므로 주의해야 한다. 가짜 정보를 담고 있는 주석은 읽는 사람에게 혼란을 주고, 이로 인해 버그를 발생시킬 가능성이 있다. 주석이 낡아 버리지 않게, 구현을 변경할 때 주석도 함게 변경하는 것이 좋다. 이 때, 주의해야 할 점은 아래와 같다. 주석은 실제..

이름을 짓는 기본적인 방법은 목적 중심 이름 설계이다. 이는 소프트웨어가 달성해야 하는 목적을 기반으로 이름을 설계하는 방법으로, 이름에서 목적과 의도를 읽고 이해할 수 있게 설계해아 한다는 것이다. 1. 부적절한 이름 온라인 쇼핑몰을 예로 들어보자. 흔히 볼 수 있는 좋지 않은 이름 설계는 상품을 그대로 '상품 클래스'라고 이름을 붙이는 것이다. 대부분의 로직이 상품을 중심으로 이루어지는 온라인 쇼핑몰 특성상 '상품 클래스'라고 단순하게 이름을 붙이는 순간, 해당 클래스는 수많은 클래스와 관련 있는 로직을 갖게 되고 점점 거대하고 복잡해진다. 1.1 관심사 분리 상품은 예약, 주문, 발송 등 다양한 관심사와 연관이 있다. 즉, 상품 클래스는 다양한 관심사와 결합되어, 온갖 것과 관련된 로직을 품게 되는..

이번 장에서는 지금까지 소개한 것 이외의 나쁜 코드 및 대처 방안을 공부한다. 1. 데드 코드 절대 실행되지 않는 조건 내부에 있는 코드를 데드 코드(dead code) 또는 도달 불가능한 코드(unreachable code)라고 부른다. 이러한 코드는 여러 문제를 일으킨다. 코드의 가독성을 떨어뜨린다. 코드를 읽는 사람이 데드 코드 주변을 읽을 때마다, 해당 코드가 어떤 조건에서 실행되는지 생각하게 만든다.(실제로는 실행되는 경우가 없는데도 말이다. 이는 숨겨둔 의도가 있는 것은 아닌지 생각하느라 에너지를 소비하게 한다.) 언젠가 버그가 될 가능성이 있다. 지금까지는 실행되지 않았지만, 사양 변경에 의해 도달 가능한 코드로 바뀔 수 있다. 이렇게 되살아난 코드가 변경된 사양과 다르다면 버그가 된다. 데..

결합도란 '모듈 사이의 의존도를 나타내는 지표'라고 할 수 있다. 어떤 클래스가 다른 클래스에 많이 의존하고 있는 구조를 강한결합(tightlycoupling)이라고 부른다. 강한 결합 코드는 이해하기 힘들고, 변경하기도 굉장히 힘들다. 이 장에서는 강한 결합을 결합도가 낮은 구조인 느슨한 결합(loose coupling)으로 개선하여 코드 변경과 이해가 쉬운 구조를 만드는 방법을 알아본다. 1. 결합도와 책무 소프트웨어가 출력, 금액 계산, 데이터베이스 등의 다양한 관심사를 가질 때, 만약 출력에 버그가 있는데 데이터베이스 로직을 수정하는 것은 말이 안 된다. 출력을 제대로 하는 것은 출력하는 로직의 책임이라고 할 수 있다. 즉 소프트웨어의 책임이란 '자신의 관심사와 관련해서, 정상적으로 동작하도록 제..