class 생성자 class Player{ constructor( private firstName: string, private lastName : string, public nickName : string ){} } 'use strict' class...
[리팩터링] chapter 9 데이터 조직화
p.329 데이터 구조 리팩터링. 하나의 값이 여러 목적으로 사용된다면 혼란과 버그를 낳는다. 그러니 이런 코드를 발견하면 변수 쪼개기를 적용해 용도별로 분리하자. 한편, 파생변수를 질의함수로 바꾸기를 활용하여 변수 자체를 완전히 없애는 게 가장 좋은 해법일 때도 있다. p.330 변수 쪼개기 for loop문에 있는 변수 i는 반복...
[리팩터링] chapter 8 기능 옮기기
p.290 필드 옮기기 함수에 어떤 레코드를 넘길 때마다 또 다른 레코드의 필드도 함께 넘기고 있다면 데이터 위치를 옮겨야 한다. 함수에 항상 함께 건네지는 데이터 조각들은 상호 관계가 명확하게 드러나도록 한 레코드에 담는게 가장 좋다. 변경 역시 주요한 요인이다. 한 레코드를 변경하려 할 때 다른 레코드의 필드까지 변경해야 한다면 필드의 위치...
[TS] Typescript의 함수
call signatures 객체 구현시 Type Alias로 코드를 줄였던 것 처럼 call signatures로 함수 의 파라미터와 리턴값에 타입을 설정한다. call signatures를 활용하면 구현 코드와 타입 설정 코드를 분리할 수 있다. type Add = ( a : number , ...
[TS] Typescript의 타입
TS is JS with syntax for types. TS 는 개발자의 실수를 줄여준다. JS 는 실수를 피하기위해 만들어져 있지 않다. JS는함수를 실행할 때 올바른 argument를 사용하도록 강제하지도 않고 객체안에 존재하지 않는 함수를 불러와도 코드를 실행해야만 에러메세지를 볼 수 있다. TS...
[리팩터링] chapter 7 캡슐화
p.236 레코드 캡슐화하기 p.246 컬렉션 캡슐화하기 컬렉션 병수로의 접근을 캡슐화하면서 게터가 컬렉션 자체를 반환하도록 한다면, 그 컬렉션을 감싼 클래스가 눈치채지 못하는 상태에서 컬렉션의 원소들이 바뀌어버릴 수 있다. 이런 문제를 방지하기 위해 컬렉션을 감싼 클래스에 add(), remove()라는 이름의 컬렉션 변경자 메서...
[리팩터링] chapter 6 기본적인 리팩터링
p.159 코드는 목적과 구현을 분리하여 함수로 구현한다. 코드를 보고 무슨 일을 하는지 파악하는데 한참이 걸린다면 그 부분을 함수로 추출한 뒤 ‘무슨 일’에 걸맞는 이름을 짓는다. 이렇게 해두면 나중에 코드를 다시 읽을 때 함수의 목적이 눈에 확 들어오고 본문코드에 대해서는 더이상 신경 쓸 일이 거의 없다. 짧은 함수의 이점은 이름을 잘 지어야...
[리팩터링] chapter 4 테스트 구축하기
p.135 테스트를 작성하기 가장 좋은 시점은 프로그래미을 시작하기 전이다. 테스트를 작성하다보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다. 간혹 테스트가 갖춰지지않은 코드를 리팩터링할 때도 있다. 그럴 때는 곧바로 리팩터링하지 않고 먼저 자가테스트 코드부터 작성한다. ...
[Next JS] 강의 정리
라이브러리와 프레임워크의 차이 라이브러리(React js) 와 프레임워크(Next js) 라이브러리는 개발자가 원하는 대로, 사용하고싶을 때 불러온다. React는 항상 App component를 만들고 개발자는 component들을 원하는 대로 채운다.개발자가 언제 React를 부를지 어떤 구조로 작성할지 결정하...
[리팩터링] chapter 3 코드에서 나는 악취
p.114 이름 바꾸기는 단순히 이름을 다르게 표현하는 연습이 아니다. 마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다. p.115 가장 간단한 코드 중복의 예로, 한 클래스에 딸린 두 메서드가 똑같은 표현식을 사용하는 경우가 있다. 이럴 때는 함수 추출하기를 써서 양쪽 모두 추출된 메서드를 호출하게 ...