마디니블로그

안티-리팩터링(나쁜 코드를 딱 봐도 안 좋아 보이게 만들어서 품질의 수준을 명확히 표시하는 방법) 을 활용하여 식별 가능한 나쁜 코드를 만들 수 있다. 우리는 코드의 복잡성이나, 시간의 촉박함으로 인해 원하는 수준으로 리팩토링을 못할 때가 많다. 이럴때 '끔찍하지만 않게' 하는 어줍잖은 리팩토링보다는 차라리 엉망진창인 상황 그대로 두는 편이 낫다. 나쁜 코드를 남겨두었을 때 장점 1. 다시 찾기가 쉽다 2.통제가 지속 가능하지 않다는 신호를 줄 수 있다. => 나쁜 코드를 남겨두어도 괜찮다는 심리적 안정감을 제공하는 분위기어야 한다. 코드를 나쁘게 놔두는 활동은 코드를 깨끗한 코드와 레거시 코드로 분리하는 역할도 한다. 깨끗한 코드와 레거시 코드가 한눈에 알아보기 쉽다면 그 비율도 쉽게 측정이 가능하고,..

이번장에서 다룰 내용 - 일반성을 최소화해서 커플링 최소화 하기 - 불변속성 측면에서 최적화 바라보기 - 최적화를 통해 취약성 관리하기 (성능)최적화: 코드 처리량을 늘리거나 처리 시간을 줄이기 일반화: 코드가 더 일반적인 매개변수를 통해 더 많은 기능을 포함하도록 하는 것 요리사에게 칼을 건네야 한다면 군용칼이 좋을까 과일 칼이 좋을까? 일반화를 수용하는 설계는 일반화 하여 얻는 이점보다 부담스러울 수 있다. 일반화 해야하는 것은 컨텍스트 뿐이다. 단순성 추구 인간의 인지능력은 제한적이므로 단순함이 필수다. 결합된 컴포넌트와 기능을 이해하기 위해 추적해야 하는 일은 인지능력이 꽤 많이 요구된다. 주로 아래 두가지 습관 때문에 단순함에서 멀어진다. 1. 일반화된 기능 제공 일반화된 기능을 제공하면 그 기..

소프트웨어는 현실 세계를 반영한 모델이다. 현실세계가 성장하고 발전함에 따라 소프트웨어의 조정도 필수이다. 다양한 구조와 서로 다른 구조가 존재하는 이유 소프트웨어 개발에서는 여러 타입의 '구조'를 다룬다. 영향도(팀 내/팀 외)와 위치(코드 내/사람)에 따른 4가지 구조 형태 팀 간 팀 내 코드에 있는 경우 외부 API 데이터와 함수, 대부분의 리팩터링 사람에 있는 경우 조직도, 프로세스 행위 및 도메인 전문가 매크로 아키텍처 - 팀 간 구조에 관한 것 - 제품이 무엇이며 다른 코드가 그것과 어떻게 상호작용 하는가 - 외부 API가 어떻게 보여야 하는지, 각팀이 어떤 데이터를 소유하는지 보여주며 소프트웨어 플랫폼을 정의한다. 마이크로아키텍처 - 팀 내 구조에 관한 것 - 팀이 가치를 제공하기 위해 무엇..

코드 추가에 대한 두려움 증상들과 이를 어떻게 극복 할 수 있는지에 대해 살펴보자. 불확실성 받아들이기: 위험감수 소프트웨어 개발이란 도메인을 학습하고 그 지식을 프로그래밍 언어로 코드화 하는 것이다. 지식을 구축하는 효과적인 방법은 실험이지만 실험에는 용기가 필요하다. 팀 생산성의 가장 큰 예측변수는 심리적 안정, 즉 팀원들이 서로를 신뢰하고 위험을 감수하는 것이 안전하다고 느끼는지 여부다. 불확실한 영역을 두려워할 때가 많지만 그 영역이 바로 우리가 배워야 하는 부분이다. "고통스러울수록 더 시도하라" 두려움 극복을 위한 스파이크 사용 실패에 대한 두려움은 생산성을 가로막는데 이는 스파이크로 극복 할 수 있다. 스파이크란, 프로젝트 초기에 스토리를 진행하기 앞서 사용할 기술(라이브러리, 프레임워크)을..

"적은 것이 더 낫다" 코드를 유지 관리하기 위해서는 지속적인 노력이 필요하기 때문에 코드를 보유 하고 있다면 이는 곧 '비용'이다. 오랜 시간 공들여 만들었다고 그 코드가 더 가치가 높은 것은 아니다. 가치는 투자(코딩 시간, 코드 양)에서 나오는게 아니라 투자의 결과(유지보수에 대한 비용)에 대해 나오기 때문에 이를 이해하고 코드 작업을 하는 것이 중요하다. 시스템에는 오래 지속되는 코드가 있을 수 밖에 없고, 도메인의 복잡성에 따라 필요한 코드 양도 다르지만 '적은 것이 더 낫다' 코드 복잡성과 코드 삭제의 관계 프로그래밍 연대기 1994: 컴퓨터를 사용해서 추상화 없는 계산 수행 1952: 링커(linker)가 개발되어 컴퓨터가 순수한 계산대신 기호로 작업할 수 있게 되었다. 1957: 컴파일러 ..

컴파일러에 대해 알아보기 컴파일러의 목표는 소스 프로그램과 동일한 다른 언어로 된 프로그램을 생성하는 것 약점: 정지 문제는 컴파일 시 알 수 있는 것을 제한한다. 정지문제(halting problem)란 런타임 동안 어떤 일이 일어날지 정확히 말할 수 없는 이유를 말한다. 즉, 일반적으로 프로그램은 근본적으로 예측이 불가능하다. 컴파일러는 런타임 중 실패를 포함해서 예상대로 동작하지 않는 프로그램이라고 해도 허용한다. 프로그램이 안전하다고 보장할 수 없는 경우 컴파일러는 프로그램을 허용하지 않는다. (="보수적 분석") 보수적 분석은 프로그램에 특정한 실패 가능성이 없다는 것을 보증하기 때문에 우리는 보수적인 분석에만 의존할 수 있다. 장점: 도달성 검증은 메서드의 반환을 보장한다 보수적 분석 중 하나..

getter 없이 캡슐화 하기 [규칙] "getter 와 setter 를 사용하지 말 것" 정의 부울(boolean)이 아닌 필드에 setter나 getter를 사용하지 말 것 설명 부울이 아닌 필드를 직접 할당하거나 반환하는 메서드를 사용하지 말 것. getter: 캡슐화를 해제하고 불변속성을 전역적으로 반들게 된다. (객체를 얻은 어느곳에서나 public 메서드를 호출할 수 있으며 예상하지 못한 방식으로 수정할 수 있기 때문에) setter: setter를 통해 내부 데이터 구조를 변경하고 getter를 통해 이 변경된 데이터 구조를 반환시키므로 강한 결합을 만들게 된다.?? pull 기반(pull-based)의 아키텍처 기능을 수행하는 메서드 는 없고, 수동적인 데이터 클래스들과 여기저기서 데이터..

유사한 클래스로 통합하기 준비. 괄호로 묶인 두 개의 || 에 대해 각기 하나의 함수 도입 메서드가 상수를 반환할 때 상수 메소드라고 한다. 경우에 따라 다른 값을 반환하는 상수 메서드를 공유하기 때문에 이 두 클래스를 합칠 수 있다. 1. 두 개의 moveHorizontal을 동일하게 만들기 a. 각 moveHorizontal 본문의 기존 코드 주위에 if(true) {} 를 추가 b. true를 각기 isFallingStone() === true, isFallingStone() === false로 바꿉니다. c. 각 moveHorizontal 본문을 복사하여 else와 함께 다른 moveHorizontal 에 붙여넣기 2. 상수 메서드 isFallingStone만 다르므로 두번째 단계는 falling..

간단한 if 문 리팩터링 [규칙] "if 문에서 else를 사용하지 말 것" 정의 프로그램에서 타입(자료형) 검사를 할 때만 if else를 사용할 것 설명 if-else는 코드에서 결정이 내려지는 지점을 고정한다. 따라서 if-else이외의 위치에서 다른 변형작업을 할 수 없기 때문에 유연성이 떨어진다 if-else체인 문은 데이터의 입출력에 직접 연결되어야하고 애플리케이션이 나머지 부분과는 분리 되어야 한다. if문은 검사(check)로 간주하고, if-else문은 의사결정(decision)으로 간주한다. if 절은 조기 return 을 시키므로 이 규칙은 if-else 문을 대상으로 한다. 스멜 early binding : if-else 는 의사결정 동작이 컴파일 시 처리되어 애플리케이션에 고정된다..

긴 코드 조각내기 혼란스러운 코드 원인 여러가지 일을 수행하는 메서드 낮은 수준의 원시 연산(배열조작, 산술연산) 사람이 읽을 수 있는 텍스트 부족 규칙: 다섯줄 제한 "메서드는 공백, {, }를 제외하고 5줄 이상이 되서는 안된다" 메서드가 길면 한 번에 긴 메서드의 모든 논리를 머릿속에 담아야 해서 작업하기 어렵다 => 스멜 메서드는 한가지 작업만 담당해야 하며 상황에 따라 다르지만 보통 한 기능은 5줄 정도로 끝나는 경우가 많다. 메소드를 반으로 나눠 도우미 메소드를 호출하는 식으로 변경하여 줄여나가기 함수 분해를 위한 리팩터링 패턴 추출할 부분 찾기 동일한 작업을 하는 데 필요한 줄을 식별하려 그룹화 시킨다. 이때 그룹간 구분은 빈줄이나 주석을 활용한다 원하는 이름으로 새로운 비어있는 메소드 생성..