본문 바로가기

Web development131

Refactoring - Split Variable Martin Fowler - Refactoring을 읽고 정리한 글입니다.(240~243p) 예제 // Before let temp = 2 * (height + width); temp = height * width; // After const perimeter = 2 * (hieght + width); // perimeter : 주변, 외곽 const area = height * width; temp라는 변수를 let으로 선언하고 수정하고 있는데 밑에는 보면 두 개의 const로 선언해서 쓰고있다. 이렇게 변수를 나누는것. Motivation 변수는 다양하게 쓰인다. 그 결과 변수의 값이 여러번 할당되기도 한다. for문에서 쓰는 index[i]같은 변수는 실행될때마다 바뀐다. 변수는 값을 메서드가 진행.. 2019. 12. 31.
Refactoring - Move Statesments into Function Martin Fowler - Refactoring을 읽고 정리한 글입니다.(213~216p) Move Statesments to Callers의 반대 케이스. 예제 // Before result.push(`title: ${person.photo.title}`); // 이 라인을 result.concat(photoData(person.photo)); function photoData(aPhoto) { return [ `location : ${aPhoto.location}`, `date : ${aPhoto.date.toDateString()}`, ]; } // After result.concat(photoData(person.photo)); function photoData(aPhoto) { return [.. 2019. 12. 31.
Refactoring - Inline Class Martin Fowler - Refactoring을 읽고 정리한 글입니다.(186~188p) extract class의 반대케이스. 클래스를 더이상 줄일 수 없을때 할 수 있다. 리팩토링의 결과물이기도 하다. 기능이 서로 다른 클래스 두 개가 있을 때 하면 좋다. // Before class Person { get officeAreaCode() {return this._telephoneNumber.areaCode;} get officeNumber() {return this._telephoneNumber.number;} } class TelephoneNumber { get areaCode() {return this._areaCode;} get number() {return this._number;} } /.. 2019. 12. 31.
Refactoring - Encapsulate Collection Martin Fowler - Refactoring을 읽고 정리한 글입니다.(170~173p) 저자는 캡슐화를 좋아한다. 캡슐화하면 데이터가 언제 어떻게 수정되는지 파악하기 쉽고 구조 수정하기도 쉽기 때문이다. 객체지향 개발자들은 장려하지만 콜렉션 쓰는 개발자는 이렇게 게터가 콜렉션 다 넘겨주면 좋지 않다. 그래서 콜렉션을 수정하는 메서드를 만들어서 쓴다. 기존 모듈 밖에서 콜렉션 수정안하는 팀이라면 (게터세터)메서드만 제공해도 충분할지 모르지만, 아니라면 원본 컬랙션에 직접 접근 못하게 해야된다. 절대 콜랙션 값에 접근하지 못하게 해라. aCustomer.orders.size 대신 aCustomer.numberOfOrders 쓰게해라. 아니면 리드온리로 접근할 수 있게 제공해라. 아니면 사본을 제공해라... 2019. 12. 31.
Refactoring - Introduce Parameter Object Martin Fowler - Refactoring을 읽고 정리한 글입니다.(140~143p) 요약 자연스럽게 같이 다녀야 하는 파라미터들을 객체화한다. Motivation 함수에 함수를 거쳐 다니는 데이터아이템이 종종 있는데, 저자는 이 데이터덩어리를 하나의 데이터구조로 수정하는것을 좋아함. 데이터를 구조적으로 그룹핑하는건 데이터 항목 간의 관계를 위해 새로운 크기의 매개변수 목록을 사용하도록 명시하기 때문에 가치있다. 이렇게하면 새로운 구조를 사용하는 어떤 함수라도 파라미터 리스트의 크기가 줄어든다. 모든 함수에서 그 구조의 엘리먼트를 얻기 위해 같은 이름을 사용할 수 있어서, 일관성을 유지하게 해준다.. 그러나 이 리팩터링의 진정한 힘은 어떻게 그것이 코드를 더 깊게 변화시킬 수 있느냐 하는 것이다... 2019. 12. 31.
Refactoring - Rename Variable Martin Fowler - Refactoring을 읽고 정리한 글입니다.(137~139p) Motivation 네이밍을 잘하는 것은 clear programming의 핵심이다. 이름을 잘 지은 변수들은 아주 많은 것을 설명할 수 있다. 하지만 종종 변수이름을 잘못 짓는다. 충분히 생각하지 않았을 수 있다. 내가 더 배울수록 문제에 대한 이해가 깊어지기 때문에 잘 지을 수 있다. 유저의 니즈에 의해서 프로그램의 용도가 변경된 경우. 심지어 대부분의 프로그램 요소들보다도, 이름의 중요성은 그것이 얼마나 널리 사용되느냐에 달려있다. one-line lambda expression에 사용되는 변수는 대개 따라가기(이해하기) 쉽다. Users.map((u)=>u.id) 이렇게 용도가 확실한 경우에는 한글자짜리 .. 2019. 12. 31.
Refactoring - Building Test Martin Fowler - Refactoring을 읽고 정리한 글입니다.(90~96p) 요약 테스트가 완벽할 필요는 없다. 자주 실행하는 것이 더 중요하다. 테스트코드에서 중복 제거에 열 낼 필요 없다. standard하게 만드는건 괜찮지만. A Firts Test 코드 테스트를 위해서는, 테스팅 프레임워크의 정렬이 필요하다. Mocha를 사용할 것이다. 보편적이고 잘 만들어졌음. 프레임워크 어떻게 쓰는지는 다 설명하지 않고 예시만 좀 보여줄것임. 모카는 테스트를 블록으로 나누고, 테스트 수트를 그룹핑한다. 각 테스트는 it 블록으로 나타난다. describe 안의 description strings를 테스트가 뭘 테스트하는지, 비워두기, 그냥 원래 있던거 복사하기도 하지만, 저자는 테스트가 실패했을 .. 2019. 12. 31.
Refactoring - Bad Smells Martin Fowler - Refactoring을 읽고 정리한 글입니다.(76~79p) 요약 Divergent Change - 분기/갈라짐 하는 변화(확산적 변화) 냄새 : 여러 다른 수정이 필요할때마다, 어떤 하나의 모듈을 매번 수정해야 함. 해결책 : 한 모듈에 하나의 책임, 하나의 이유로 한 모듈의 수정 Shotgun Sergery - 샷건 수술 냄새 : 변경할 때마다, 많은 클래스들에 많은 작은 수정이 필요한 경우. 해결책 데이터 구조를 변경하거나 늘리는 펑션이 있으면 - 펑션을 합쳐서 클래스로 만들거나, 단계를 나눠라. 쪼개진 로직을 합치는 좋은 방법은 인라인 리팩토링이다. - 인라인 펑션, 인라인 클래스 개편을 위한 중간 단계로서 큰 것을 만드는걸 두려워해선 안됨 Feature Envy - .. 2019. 12. 31.
[Ruby] nil? empty? blank? 차이점 | nil? | empty? | blank? ------|-------|---------------|-------- [] | false | true | true {} | false | true | true ‘’ | false | true | true ‘ ‘ | false | false | true 0 | false | NoMethodError | false nil | true | NoMethodError | true false | false | NoMethodError | true nil?은 말그대로 nil인지 검사하는 것. nil이면 true, 아니면 false. empty?는 비어있는지만 검사한다. 공백문자도 false를 반환함. 0/nil/false에 대해선 에러 발생. blank?는 "비어있다"기.. 2019. 6. 18.

티스토리툴바