리팩터링 2판 (javascript clean code)

악취의 종류 기이한 이름 (변수/모듈) 중복코드 긴 함수 긴 매개변수 목록 전역 데이터 가변 데이터 SRP(Single Responsibility Principle)에 어긋나는 경우 뒤엉킨 변경 산탄총 수술 > 코드에서 지양되어야할 점들을 "악취"라고 표현한 것

해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.테스트를 지속적으로 성공하는 경우 내 논리가 맞는지 일부러 틀린 케이스를 작성해서 테스트해보기공유객체 만들지 않기, 테스트 직전 객체를 초기화해서 정확한 테스트 결과를 만들기경계 조건 검사: 의도하지 하지

: 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 것restructuring > refactoring기능추가/테스트는 리팩터링과 동시에 진행하지 않을 것3의 법칙 1\. 일단 개발같은 일을 두번할때 -> 또 개발또

해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.

해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.

해당 내용은 리팩터링 2판을 읽고 개인적으로 정리한 내용입니다.이해하는데 시간이 걸린 부분을 중심으로 정리하고 있습니다.https://github.com/yeoj1n/JS-study/blob/master/refactoring/chapter08/%EA%B8%B0

9.1.변수 쪼개기

조건식과 조건에 딸린 조건절을 각각 함수로 추출하기조건식들의 부수효과가 없는지 확인하기조건문 두개를 선택하여 조건식들을 논리 연산자로 결합한다.테스트 조건이 하나가 남을 때까지 2~3 과정을 반복한다.합쳐진 조건식을 함수로 추출할지 고려해본다.보호구문: 조건문에서 조건

겉보기 부수효과가 있는 함수와 없는 함수는 명확히 구분하는 것이 좋다.두 로직이 아주 비슷하고 단지 리터럴 값만 다르다면 다른 값만 매개변수로 받아 처리하는 방법을 사용하면 중복을 해결할 수 있다.플래그 인수: 호출되는 함수가 실행할 로직을 호출하는 쪽에서 선택하기 위

가장 쉬운 경우: 본문 코드가 동일한 경우 -> 복사+붙여넣기어려운 경우: 본문에서 참조하는 필드들이 서브클래스에만 있는 경우 -> 필드를 먼저 슈퍼클래스로 올린 후 메서드를 올려야함하위 클래스에 있는 필드들 중 비슷하게 쓰이는 필드가 있다고 판단되면 (필드명이 다르더

프로그램이 새로운 기능을 추가하기 편한 구조가 아니라면, 먼저 기능을 추가하기 쉬운 형태로 리팩터링 후 원하는 기능을 추가하자.리팩터링 전 제대로 된 테스트부터 마련한다. 테스트는 반드시 자가진단하도록 만든다.