리팩터링은 결국 프로그램의 요소를 조작하는 일이다. 함수는 데이터보다 다루기가 수월하다. 함수를 사용한다는 건 대체로 호출한다는 뜻이고, 함수의 이름을 바꾸거나 다른 모듈로 옮기기는 어렵지 않다. 여차하면 기존 함수를 그대로 둔 채 전달 함수로 활용할 수도 있기 때문이다. 이런 전달 함수를 오래남겨둘 일은 별로 없지만 리팩터링 작업을 간소화하는데 큰 역할을 한다. 반대로 데이터는 함수보다 다루기가 까다로운데, 그 이유는 이런식으로 처리할 수 없기 때문이다. 데이터는 참조하는 모든 부분을 한 번에 바꿔야 코드가 제대로 동작한다. 짧은 함수 안의 임시 변수처럼 유효범위가 아주 좁은 데이터는 어려울 게 없지만, 유효범위가 넓어질수록 다루기 어려워진다. 전역 데이터가 골칫거리인 이유도 바로 여기에 있다. 그래서..

.sort() 메서드는 inplace로 동작하기 때문에, 변환된 값이 원래 배열에 그대로 반영된다. 그러므로, 1번, 2번 구문은 true이다. 그런데 3번 구문은 좌항, 우항이 값은 같으나 서로 다른 메모리를 참조하고 있을 것이므로 false이다. set은 중복된 값을 제거시킨다. 근데 mySet구문에서 {a:1}와 {a:1}는 다른 주소값을 가지고 있다. 그러므로 set과정에서 원소가 사라지지 않는다. 그것을 다시 array로 spread해주었으므로 답은 1번이다. Object.freeze는 기본적으로 객체의 수정을 막는 역할을 한다. 하지만 depth가 깊은 프로퍼티에 대해서는 적용되지 않는다. user.age를 수정하려 한다면 에러가 나겠지만 user.pet.name은 depth가 2이상이므로 f..

https://www.youtube.com/watch?v=SOG-y8CKKNI 위 영상을 보고 기억나는대로 휘갈겨 쓴 글입니다. 완벽이라는 것은 되게 상대적인 개념이다. 누군가에게는 이게 완벽하지 않은 것일 수도 있지만 누군가에게는 완벽한 것일 수도 있기 때문이다. 그런데 완벽한 하루라는 것은 무엇인가? 완벽한 하루라는 것은 내가 이런 목표를 정해놓고, 그거를 내 기준에서 100% 온전히 달성하는 것이 완벽한 하루인 것이다. 근데 완벽한 하루를 이렇게 생각하는 사람도 잘없고, 심지어 인생의 목표가 없는 경우도 너무 많다. 인생의 목표가 없는데 1년 목표가 있는 경우는 드물고, 일년 목표가 없는데 한달이나 하루 목표가 있는 경우는 또 거의 없다. 그런데 정말로 언제 죽을지도 모르는데, 정말 하루라도 완벽하..

냄새나면 당장 갈아라 - 켄트 백 할머니의 육아 원칙 1. 기이한 이름 추리 소설이라면 무슨 일이 전개되는지 궁금증을 자아낼수록 좋지만, 코드는 아니다. 세계적인 기인이라는 느낌을 풍기고 싶더라도 꾹 참고 코드는 단순하고 명료하게 작성해야 한다. 코드를 명료하게 표현하는 데 가장 중요한 요소 중 하나는 바로 이름이다. 그래서 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다. 하지만 아쉽게도 이름짓기는 프로그래밍에서 가장 어렵기로 손꼽히는 두 가지중 하나이다. 그 때문에 우리가 가장 많이 사용하는 리팩터링도 함수 선언 바꾸기, 변수 이름 바꾸기, 필드 이름 바꾸기처럼 이름을 바꾸는 리팩터링들이다...

타입스크립트에서 interface를 정의할때 I-prefix를 붙이는 것은 권장되지 않는다. 인터넷을 뒤져보면서 다양한 헝가리안 표기법을 지양하는 이유에 대해서 모아보았다. 1. 헝가리안 표기법의 시대는 끝났다. 원래 I-prefix를 사용한 이유는 네이밍만 보고 그 구문의 역할을 바로 알아챌 수 있었다는 점이다. 예를 들어서, I는 interface C는 클래스 A는 추상 클래스 S는 문자열 c는 const 변수 i는 정수형 변수 에 해당하는 의미를 가지고 있다. 즉, 마우스를 hover안하고 이름만 보고도 타입의 정보를 알아챌 수 있는 것이다! 하지만 변수나 함수인자의 이름을 기억하기가 힘들어지고, 데이터 타입이 바뀌면 이름도 바꿔주어야 한다. 그 외에도 여기서 언급되지 않은 장/단점이 매우 많이 존..

함수는 프로그램을 작은 부분으로 나누는 주된 수단이다. 함수 선언은 각 부분이 서로 맞물리는 방식을 표현하며, 실질적으로 소프트웨어 시스템의 구성 요소를 조립하는 연결부 역할을 한다. 건축과 마찬가지로 소프트웨어도 이러한 연결부에 상당히 의존한다. 연결부를 잘 정의하면 시스템에 새로운 부분을 추가하기가 쉬워지는 반면, 잘못 정의하면 지속적인 방해 요인으로 작용하여 소프트웨어 동작을 파악하기 어려워지고 요구사항이 바뀔 때 적절히 수정하기 어렵게 한다. 다행히 소프트웨어는 소프트하기 때문에 연결부를 수정할 수 있다. 단 주의해서 해야 한다. 이러한 연결부에서 가장 중요한 요소는 함수의 이름이다. 이름이 좋으면 함수의 구현 코드를 살펴볼 필요 없이 호출 문만 보고도 무슨 일을 하는지 파악할 수 있다. 하지만 ..

변수는 함수 안에서 표현식을 가리키는 이름으로 쓰이며, 대체로 긍정적인 효과를 준다. 하지만 그 이름이 원래 표현식과 다를 바 없을 때도 있다. 또 변수가 주변 코드를 리팩터링하는 데 방해가 되기도 한다. 이럴 때는 그 변수를 인라인하는 것이 좋다. 절차는 다음과 같다. 1. 대입문의 표현식에서 부작용이 생기지는 않았는지 확인한다. 2. 변수가 불변으로 선언되지 않았다면 불변으로 만든 후 테스트한다. 3. 이 변수를 가장 처음 사용하는 코드를 찾아서 대입문 우변의 코드로 바꾼다. 4. 테스트 한다. 5. 변수를 사용하는 부분을 모두 교체할 때까지 이 과정을 반복한다. 6. 변수 선언문과 대입문을 지운다. 7. 테스트 한다. 이것을 리팩토링하면 간단하다.