작심삼일 개발이야기

질의 함수와 변경 함수 분리하기 외부에서 관찰할 수 있는 겉보기 부수효과(사이드 이펙트)가 전혀 없이 값을 반환해주는 함수를 추구해야 한다. 함수가 사이드 이팩트가 있다는 것은 한 가지 일을 하기로 했는데 여러 가지 일을 하는 것이다. // before // 아래의 함수는 이름처럼 2가지 일을한다. (부수효과는 아니다) function totalOutstandingAndSendBill() { const result = customer.invoices.reduce( (total, each) => each.amount + total, 0); sendBill(); return result; } // after function totalOutstanding() { return customer.invoices.r..

조건부 로직은 프로그램을 복잡하게 만드는 주요 원흉이기도 하다. 조건문 분해하기 조건을 검사하고 그 결과에 따른 동작을 표현하는 코드는 무슨 일이 일어나는지는 이야기해주지만 왜 일어나는지는 말하지 않는다. 거대한 코드 블록을 부위별로 분해하고 의도를 살린 이름의 함수 호출로 바꾸자. 거대한 코드 블록이 주어지면 코드를 부위별로 분해한 다음 의도를 살린 이름의 함수 호출로 바꾸자. // before if (!date.isBefore(plan.summerStart) && !date.isAfter(plan.summerEnd)) { charge = quantity * plan.summerRate; } else { charge = quantity * plan.regularRate + plan.regularServ..

이번 장은 데이터 구조에 집중한 리팩토링이다. 변수 쪼개기 역할이 둘 이상인 변수는 쪼개야 한다. 역할 하나당 변수 하나다. function distanceTravelled(scenario, time) { let result; let acc = scenario.primaryForce / scenario.mass; // 가속도(a) = 힘(F) / 질량(m) let primaryTime = Math.main(time, scenario.delay); result = 0.5 * acc * primaryTime * primaryTime; // 전파된 거리 let secondaryTime = time - scenario.delay; if (secondaryTime > 0) { // 두 번째 힘을 반영해 다시 계산..

기본형을 객체로 바꾸기 처음에는 단순한 문자열로 시작해서 나중에는 포맷팅, 특별한 동작이 추가되는 등 중복 코드가 늘어나고 사용할 때마다 드는 노력도 늘어난다. 출력 이상의 기능이 필요해지는 순간 클래스를 정의하면 좋다. 클래스로 집중시켜 놓으면 관련된 로직을 한 곳에서 관리할 수 있으면 중복된 코드를 처리할 수 있다. // before class Order { constructor(data){ this.priority = data.priority; } } highPriorityCount = orders.filter (o => "high" === o.priority || "rush" === o.priority).length; // after class Order { constructor(data){ th..

함수 추출하기 코드 조각을 찾아 무슨 일을 하는지 파악한 다음, 독립된 함수로 추출하고 목적에 맞는 이름을 붙인다. 코드를 언제 독립된 함수로 묶어야 할지에 관한 의견은 많다. 길이, 반복되는 횟수 등등 많지만 ‘목적과 구현을 분리’하는 방식이 가장 합리적으로 보인다. 코드를 보고 무슨 일을 하는지 파악하는 데 한참이 걸리면 함수로 추출한 뒤 걸맞은 이름을 짓는다. 함수를 새로 만들고 목적을 잘 드러내는 이름을 붙인다(’어떻게’가 아닌 ‘무엇을’ 하는지) 추출할 코드를 원본 함수에서 복사하여 새 함수에 붙여넣는다. 추출한 코드 중 원본 함수의 지역 변수를 참조하거나 추출한 함수의 유효 범위를 벗어나는 변수는 없는지 검사한다. 있다면 매개변수로 전달한다. 변수를 다 처리했다면 컴파일한다. 원본 함수에서 추..

리팩토링을 언제 멈춰야 하는지를 판단하는 정확한 기준은 제시하지 않을 것이다. 왜냐하면 숙련된 사람의 직관만큼 정확한 기준은 없기 때문이다. 아래의 소제목들은 피해야 하는 것들이다. 기이한 이름 이름만 보고도 무슨 일을 하고 어떻게 사용해야 하는지 명확히 할 수 있도록 짓는다. 이름만 보고도 동작을 유추할 수 있다면 코드 파악하는 시간을 많이 줄일 수 있다. 그리고 코드를 읽는 사람이 코드에 더 신뢰성을 가질 수도 있다. 중복 코드 똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하자. 중복 코드는 그 순간 편하겠지만 수정으로 들어가는 순간 지옥길 시작이다.. 긴 함수 긴 함수보다 짧은 함수가 코드를 이해하는데 더욱 도움이 된다. 짧은 함수로 구성된 코드를 이해하기 쉽게 만드는 가장 확실한 방법은 ..

리팩토링 정의 리팩토링 → 겉보기 동작은 유지한 채, 이해하기 쉽게 내부 구조를 변경하는 기법 리팩토링 과정에서 발견된 버그는 리팩토링 후에도 남아 있어야 한다. 리팩토링은 코드를 이해하고 수정하기 쉽게 만드는 것이다. 리팩토링을 진행하며 버그를 고치지 말라고 하는데... 눈앞에 버그를 놔두고 지나가야 하는 건가 라는 의문이 든다. 리팩토링 하는 이유 코드만 봐서는 설계를 파악하기 어렵다. 코드량이 줄면 수정하는데 드는 노력은 크게 달라진다. 모든 코드가 언제나 고유한 일을 수행함을 보장한다. 내 의도를 더 명확하게 전달하기 위해 다른 사람을 배려하기 위해서가 아니라 바로 나 자신을 위해 버그를 찾기 쉽다. 기억할 필요가 있는 것들은 최대한 코드에 담아내자 (외부에 담으려 X) 일단 리팩토링을 하는 이유..

앞에 작성하지 않는 단원들은 JAVA 친화적으로 너무 보기 싫어서 안 봤다 ㅋㅋ 몰라 마지막 단원으로 17장 읽고 클린 코드는 여기서 마무리! 솔직히 17장만 읽어도 이 책이 어떤 말을 하려는지 알 수 있는 것 같다. 주석 극단적인것 까지는 아니지만 주석은 99% 필요 없다고 생각을 가지고 있다. 물론 이 책을 읽으며 생각이 점점 확고해지지만 확실히 코드를 보다 보면 관리되는 주석을 본 적이 없다. 그럴 바엔 차라리 안 쓰는 게 좋다는 생각이 점점 커지는 중... 부적절한 정보 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다. 예를 들어, 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템, 기타 기록 관리 시스템에 저장할 정보는 주석으로 적절하지 못하다. 이러한 것들은 git을 이용해..

스터디 끝나고 일주일이 지났다. 오늘은 14장을 진행하는 날인데 아무도 준비하지 않았다 ㅋㅋㅋㅋ 그래서 저번에 올리지 못한 13장을 올릴꺼다. 이번 내용은 같은 팀원의 요약을 가져왔찌만 이해는 못했따. 동시성과 깔끔한 코드는 양립하기 어렵다. 동시성이 필요한 이유 구조와 효율을 개선하기 위해 응답 시간과 작업 처리량을 개선하기 위해 무엇과 언제를 분리하게 되면 시스템 구조가 크게 달라진다. 하지만 동시성이 성능을 항상 개선하는 것도 아니고, 부하를 유발하고 복잡하고 버그도 재현하기 어렵다. 동시성 코드로 인해 발생할 수 있는 문제로부터 시스템 방어하는 방법 단일 책임 원칙 동시성 코드는 다른 코드와 분리하라. 임계영역의 수를 줄인다 보호할 임계영역은 synchronized 키워드로 보호하라고 권장하는데,..

17일 스터디를 진행하고 벌써 일주일째 다되어가서 늦은 업로드 휴가를 쓰면 공부도 하기 싫고 일상으로 돌아오기가 더 힘든 것 같다 창발적 설계로 깔끔한 코드를 구현하자 여기서 창발적이란 집단 지성? 같은 의미인 것 같다. 개별적으로 보면 크지 않지만 모이면 시너지가 생기는 그런 느낌 켄트 벡이 제시한 단순한 설계 규칙 네 가지 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 의도한 대로 돌아가는 시스템을 내놓아야 한다. 테스트 케이스를 많이 작성할수록 결합도를 낮춰야 한다. 테스트 케이스를 작성하면 설계 품질이 높아진다. 단순한 설계 규칙 2~4: 리팩터링 테스트 케이스를 모두 작성했다면 점진적으로 ..