DEV/How to

⌨️ 개인의 편리를 위해 규약을 느슨하게 해선 안된다결론부터 말하자면 살짝 느슨해진 것 같다.일을 하다 보니 어느새 귀찮은 것들에 대해 피하고 싶어 졌고, 그것이 곧 옳지 못한 구현으로 이어지기도 했다.이 글은 그런 날을 돌이키며 기억해 두고 채찍질하기 위함이다.  🤔 쿼리스트링이 긴게 문제일까? 동료가 다른 일을 하는 동안 나는 작업하기 편하게 프론트를 조금 만져주는 걸로 일을 나누었다.프론트에서 `Get` 요청을 보낼 때 쿼리스트링으로 만들어 주길 요청했으나. 나는 쿼리스트링이 너무 길어져서 불편해서 그런데 `Post`로 RequestBody에 담아도 될까요?라고 했다. 이런저런 이야기가 오고 갔지만, 결과적으론 쿼리스트링이 길어서 불편하다는 내 의견은 그냥개인의 불편함을 호소하는 것뿐 합당한 이유..

⌨️ 언제 적 코딩 테스트? 이미 한국 패치가 잔뜩 들어간 코딩 테스트에 대해 회의적인 시각이 많아진 현재다.그러나 그런 시각과 별개로 여전히 코딩 테스트는 유효한 검증 수단이다. 애석하게도 수능에서 5등급을 맞은 학생이 1등급을 맞은 학생에게 수능이 중요한 게 아니야라고 말하는 것만큼 우스운 꼴이 없을 거다.그리고 잔혹하게도 현실은 1등급을 맞은 학생이 더욱 좋은 대학에 갈 확률이 높다.  이것은 어찌할 수 없는 현실이다. 자 그럼 여러분은 빠르게 현실을 받아들였다고 가정하자. a) 필요성을 느껴 열심히 준비해 좋은 결과를 낸다.b) 현재는 여력이 없다 반수나 편입을 노리자.c) 만족하자 보통 이 세 가지의 경우로 수렴할 것이다. 나의 경우 여러 상황을 고려하여 b를 택했고, 개발 직군으로의 전향 혹은..

항상 뭉쳐 다니는 데이터는 한 곳으로 모아두는 것이 좋다. 여러 클래스에 존재하는 비슷한 필드 목록 여러 함수에 전달하는 매개변수 목록 관련 리팩토링 기술 "클래스 추출하기"를 사용해 여러 필드를 하나의 객체나 클래스로 모을 수 있다. "매개변수 객체 만들기" 또는 "객체 통째로 넘기기"를 사용해 메소드 매개변수를 개선할 수 있다.

기능 편애 어떤 모듈에 있는 함수가 다른 모듈에 있는 데이터나 함수를 더 많이 참조하는 경우에 발생한다. (결합도 높음) 예) 다른 객체의 getter를 여러개 사용하는 메소드 관련 리팩토링 기술 "[[Divergent Change#2. 함수 옮기기 (Move Function)|함수 옮기기]]"를 사용해서 함수를 적절한 위치로 옮긴다. 함수 일부분만 다른 곳의 데이터와 함수를 많이 참조한다면 "[[Duplicated Code#1. 함수 추출하기|함수 추출하기]]"로 함수를 나눈 다음에 함수를 옮길 수 있다. 만약에 여러 모듈을 참조하고 있다면? 그 중에서 가장 많은 데이터를 참조하는 곳으로 옮기거나, 함수를 여러개로 쪼개서 각 모듈로 분산 데이터와 해당 데이터를 참조하는 행동을 같은 곳에 두도록 하자 예..

산탄총 수술 어떤 한 변경 사항이 생겼을 때 여러 모듈을(여러 함수 또는 여러 클래스를) 수정해야 하는 상황 "[[Divergent Change|뒤엉킨 변경]]"과 유사하지만 반대의 성향 예) 새로운 결제 방식을 도입할면 여러 클래스의 코드를 수정해야 한다. 변경 사항이 여러곳에 흩어진다면 찾아서 고치기도 어렵고 중요한 변경 사항을 놓칠 수 있는 가능성도 생긴다. 관련 리팩토링 기술 "[[Divergent Change#2. 함수 옮기기 (Move Function)|함수 옮기기]]" 또는 "[[#1. 필드 옮기기 (Move Field)|필드 옮기기]]"를 사용해서 필요한 변경 내역을 하나의 클래스로 모을 수 있다. 비슷한 데이터를 사용하는 여러 함수가 있다면 "[[Long Paramater List#3. ..

뒤엉킨 변경 소프트웨어는 변경에 유연하게 대처할 수 있어야 한다. 어떤 한 모듈이(함수 또는 클래스가) 여러가지 이유로 다양하게 변경되어야 하는 상황. 예) 새로운 결제 방식을 도입하거나, DB를 변경할 때 동일한 클래스에 여러 메소드를 수정해야 하는 경우. 서로 다른 문제는 서로 다른 모듈에서 해결해야 한다. 모듈의 책임이 분리되어 있을수록 해당 문맥을 더 잘 이해할 수 있으며 다른 문제는 신경쓰지 않아도 된다. 관련 리팩토링 기술 "[[#1. 단계 쪼개기 (Split Phase)|단계 쪼개기]]"를 사용해 서로 다은 문맥의 코드를 분리할 수 있다. "[[#2. 함수 옮기기 (Move Function)|함수 옮기기]]"를 사용해 적절한 모듈로 함수를 옮길 수 있다. 여러가지 일이 하나의 함수에 모여 있..

1. 전역 데이터 전역 데이터 (예, 자바의 public static 변수) 전역 데이터는 아무 곳에서나 변경될 수 있다는 문제가 있다. 어떤 코드로 인해 값이 바뀐 것인지 파악하기 어렵다. 클래스 변수(필드)도 비슷한 문제를 겪을 수 있다. "[[#1.1 변수 캡슐화하기 |변수 캡슐화하기]]"를 적용해서 접근을 제어하거나 어디서 사용하는지 파악하기 쉽게 만들 수 있다. 파라켈수스의 격언, "약과 독의 차이를 결정하는 것은 사용량일 뿐이다." 1.1 변수 캡슐화하기 변수를 변경하는 것보다 변수를 사용하는 메서드를 변경하는 것이 더욱 쉽다. 메서드는 점진적으로 새로운 메서드로 변경할 수 있으나, 데이터는 한 번에 모두 변경해야 한다. 데이터 구조를 변경하는 작업을 그보다는 조금 더 수월한 메소드 구조 변경..

긴 매개변수 목록 어떤 함수에 매개변수가 많을수록 함수의 역할을 이해하기 어려워진다. 과연 그 함수는 한가지 일을 하고 있는게 맞는가? 불필요한 매개변수는 없는가? 하나의 레코드로 뭉칠 수 있는 매개변수 목록은 없는가? 어떤 매개변수를 다른 매개변수를 통해 알아낼 수 있다면, "매개변수를 질의함수로 바꾸기"를 사용할 수 있다. 기존 자료구조에서 세부적인 데이터를 가져와서 여러 매개변수로 넘기는 대신 "객채 통째로 넘기기"를 사용할 수 있다. 일부 매개변수들이 대부분 같이 넘겨진다면, "매개변수 객체 만들기"를 사용할 수있다. 매개변수가 플래그로 사용돤다면, "플래그 인수 제거하기"를 사용할 수 있다. 여러 함수가 일부 매개변수를 공통적으로 사용한다면 "여러 함수를 클래스로 묶기"를 통해 매겨변수를 해당 ..

짧은 함수 vs 긴 함수 함수가 길 수록 더 이해하기 어렵다 vs 짧은 함수는 더 많은 문맥전환을 필요로 한다. "과거에는" 작은 함수를 사용하는 경우에 더 많은 서브루틴 호출로 인한 오버헤드가 있었다. 작은 함수에 "좋은 이름"을 사용했다면 해당 함수의 코드를 보지 않고도 이해할 수 있다. 어떤 코드에 "주석"을 남기고 싶다면, 주석 대신 함수를 만들고 함수의 이름으로 "의도"를 표현해보자. 사용할 수 있는 리팩토링 기술 대부분 함수 추출하기로 해결할 수 있다. 함수로 분리하면서 해당 함수로 전달해야 할 매개변수가 많아진다면 다음과 같은 리팩토링을 고려해볼 수 있다. 임시 변수를 질의 함수로 바꾸기 매개변수 객체 만들기 객체 통째로 넘기기 조건문 분해하기를 사용해 조건문을 분리할 수 있다. 같은 조건으..