DEV

산탄총 수술 어떤 한 변경 사항이 생겼을 때 여러 모듈을(여러 함수 또는 여러 클래스를) 수정해야 하는 상황 "[[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 변수 캡슐화하기 변수를 변경하는 것보다 변수를 사용하는 메서드를 변경하는 것이 더욱 쉽다. 메서드는 점진적으로 새로운 메서드로 변경할 수 있으나, 데이터는 한 번에 모두 변경해야 한다. 데이터 구조를 변경하는 작업을 그보다는 조금 더 수월한 메소드 구조 변경..

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

⌨️ 테스트 코드 그리고 TDD 내가 여기서 말하고 싶은 건 TDD에 대한 찬양도 무조건적인 맹목도 아닌 테스트 코드 그리고, 충분한 테스팅에 대해 중요성에 대해 말하고 싶다. 1. TDD 테스트 주도 개발 (Test-Driven Development, TDD)은 소프트웨 개발 방법론 중의 하나로, 선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식의 프로그래밍 방법을 말한다. 다시 말해 먼저 자동화된 테스트 코드를 작성한 후 테스트를 통과하기 위한 코드를 개발하는 방식의 개발 방식을 말한다. 1.1. TDD를 이용한 개발방법 1. 테스트 케이스 작성 2. 테스트 케이스를 통과하는 코드 작성 3. 작성한 코드 리팩토링 형식으로 이루어진다. 여기서 우리 같은 신입들은 많이 힘들어하는데, 나는 그 이유..

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

중복코드 중복 코드의 단점 비슷한지, 완전히 동일한 코드인지 주의 깊게 봐야한다. 코드를 변경할 때, 동일한 모든 곳의 코드를 변경해야 한다. 사용할 수 있는 리팩토링 기술 동일한 코드를 여러 메소드에서 사용하는 경우, 함수 추출하기 코드가 비슷하게 생겼지만 완전히 같지는 않은 경우, 코드 분리하기 여러 하위 클래스에 동일한 코드가 있다면 메소드 올리기 1. 함수 추출하기 "의도"와 "구현" 분리(주관) 어떤 코드를 읽을 때 한 번에 술술 -> 의도 코드를 읽을 때 어떻게 작동하는 지 이해하려고 시간과 노력 -> 구현 무슨 일을 하는 코드인지 알아내려고 노력해야 하는 코드라면 해당 코드를 함수로 분리하고 함수 이름으로 무슨 일을 하는지 표현할 수 있다 한 줄짜리 메소드도 괜찮은가? 거대한 함수 안에 들어..

⌨️ DB 의존 설계? DB 모델 주도? 뭔가 말만 들어도 확 와닿지 않는다. 최근 본 영상인데 비슷한 관점이 많이들 있는 거 같아서 한 번 고민해 보게 되는 것 같다. 두 영상의 내용은 전체적으론 다르지만 그 안에서 DB의존 DB모델이라는 언급이 있다. 이 부분에 대해 짚고 가볼까 한다. 한쪽에서는 개념객체(*제미니의 개발실무) 한쪽에서는 유스케이스의 행위(*하찮은 오후)가 DB에 의존한 개발에서는 명확히 표현되지 않는다고 한다. --- 우선 개념객체라는 단어는 채널주께서 본인만의 언어로 사용하시는 건데, 나의 경우에서는 본능적으로 어떠한 개념이나 기능을 객체로 나타낸 것이라고 생각을 했다. --- 1. DB 모델 우선 그럼 DB 모델 혹은 DB 의존에 대한 합의부터 이루어져야 할 것 같다. 우리가 가..

⌨️ What About U? 앞으로 꾸준히 쓰게 될 포스팅 중 하나이다. 따로 어디 카테고리에 넣기가 애매해서 Dev에 넣고 꾸준히 쓰려고 한다. Spring에 대한 고민일 수도 있고, Java 혹은 DB에 대한 고민이 있을 수도 있다. 물론 당장은 신입이기에 신입의 시각에서 보는 관점이라 많이 틀릴 수도 있고 패러다임에 맞지 않을 수도 있지만, 사고하고 공유한다는 것에 의의를 두고 싶다. 1. Service Layer Layerd Pattern 하면 현재로선 Controller-Service-Repository가 꽤 눈에 익지 않을까 한다. 당연히 Controller가 하는 일 Service가 하는 일 이런 걸 쓰고자 했으면 안 썼을 포스팅이다. 내가 고민하고 예전과 생각이 달라진 점은 바로 Coup..