개발자로 전향중

3.4 긴 매개변수 목록좋종 다른 매개변수에서 값을 얻어올 수 있는 매개 변수가 있을 수 있는데, 이런 매개변수는 매개변수를 질의 함수로 바꾸기로 제거할 수 있다.  사용 중인 데이터 구조에서 값을을 뽑아 각각을 별개의 매개변수로 전달하는 코드라면 객체 통째로 넘기기를 적용해서 원본 데이터 구조를 그대로 전달한다. 함수 동작의 방식을 정하는 플래그 역할의 매개변수는 플래그 인수 제거하기로 없애준다. 3.5 전역 데이터전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는게 문제다. 이를 방지하기 위해 우리가 사용하는 대표적인 리팩터링은 변수 캡슐화하기다3.6 가변 데이터함수형 프로그래밍에서는 데이터는 절대 변하지 않고, 데이터를 변경하려면 반드시 변경하려는 값에 ..

3.1 기이한 이름함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야한다. 마땅한 이름이 떠오르지 않는다면 설계에 근본적인 문제가 숨어 있을 가능성이 높다. 3.2 중복 코드한 클래스에 딸린 두 메서드가 똑같은 표현식을 사용하는 경우가 있다. 이럴 때는 함수 추출하기를 써서 양쪽 모두 추출된 메서드를 호출하게 바꾸면 된다. 코드가  비슷하긴 한데 완전히 똑같지는 않다면 문장 슬라이드하기로 비슷한 부분을 한곳에 모아 추출하기를 더 쉽게 적용할 수 있는지 살펴본다. 같은 부모로부터 파생된 서브 클래스들에 코드가 중복되어 있다면, 각자 따로 호출되지 않도록 메서드 올리기를 적용해 부모로 옮긴다. 문장 슬라이드..

리팩터링 시 고려할 문제 새 기능 개발 속도 저하리팩터링의 본집은 코드 베이스를 예쁘게 꾸미는데 있지 않다. 오로지 경제적인 이유로하는것이다.  코드 소유권코드의 소유권은 팀에 두는 것이다. 팀원이라면 누구나 팀이 소유한 코드를 수정할 수 있게 한다.브랜치지속적인 통합 (CI) 또는 트렁크 기반 개발 (TBD)를 따라 모든 팀원이 하루에 최소 한 번은 마스터와 통합한다.머지의 복잡도를 줄일 수 있을 뿐 아니라 리팩터링과의 궁합도 좋다. 기능별 브랜치가 가져오는 리팩터링 부담은 너무나 크다. CI를 적용하는 편이 소프트웨어를 배포하는 데 훨씬 효과적이라는 객관적 증거가 있다. 테스팅리팩터링은 단계별 변경 폭이 작아서 도중에 발생한 오류의 원인이 될만한 코드 범위가 넓지 않다. 원인을 못찾더라도 버전 관리 ..

리팩터링: 소프트웨어의 겉보기 동작은 그대로 유지한 채 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법예시 코드가 없는 텍스트이기 때문에 기억에 남는 글만 기록하겠다. 두개의모자목적이 기능추가 또는 리팩터링이냐를 명확히 구분해 작업을 한다. 리팩터링을 하면 버그를 쉽게 찾을 수 있다.뛰어난 프로그래머는 아니지만 좋은 습관을 가진 프로그래머가 되자! 언제 리팩터링을 해야할까 (3의 법칙)1. 처음에는 그냥 한다.2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.3. 비슷한 일을 세 번째 하게 되면 리팩터링 한다. 준비를 위한: 리팩터링리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다. 함수 매개변수화하기 를 적용해서 중복 ..

1-8 다형성을 활용해 계산 코드 재구성하기 다형성이란?*다형성(Polymorphism)**은 객체지향 프로그래밍(OOP)의 핵심 개념 중 하나로, 같은 인터페이스나 부모 클래스를 공유하는 객체들이 서로 다른 방식으로 동작할 수 있는 능력 쉽게 말해, 같은 기능을 하더라도 객체에 따라 다른 결과를 만들어낼 수 있는 것 예시 (현실 비유):"동물"이라는 공통된 행동: 모두 소리를 낼 수 있음.하지만, 각 동물마다 소리는 다름:개: "멍멍"고양이: "야옹"소: "음메"나는 React를 쓰기 때문에..React에서 다형성React에서는 클래스 기반이 아닌 함수형 컴포넌트를 사용하면서, 다형성을 컴포지션(Composition), 조건부 렌더링, 동적 매핑을 통해 구현합니다.React에서 다형성은 다음과 같이 사..

1탄을 작성하기 위해 2시간 가량 집중해서 정독했는데 느낀점은 지금까지 나는 어떻게 코드를 짰던걸까? 하는 의문점이 들었다..기능을 돌아가게 하는것도 중요하지만 리팩터링을 하며 수정이 용이하고 확장 가능한 설계를 하는것이 얼마나 중요한가를 깨닫게 되었다. 정확하게는 리팩터링은 어떻게 하는것인가의 기준이 생기기 시작했다. 2탄의 시작은 책 내용 기준 1.5 중간 점검: 난무하는 중첩 함수부터이다. 지금까지는 프로그림의 논리적인인 요소를 파악하기 쉽도록 코드의 구조를 보강하는데 주안점을 두고 리팩터링을 했다면 이제 HTML 버전을 만드는 작업을 살펴보자=> 해당 부분은 텍스트로만 봤을 때는 이해가 잘안되었다.  계산 코드가 분리됐다:데이터 처리나 비즈니스 로직 같은 복잡한 계산 작업은 별도의 파일이나 함수로..

어느덧 개발자로 커리어를 쌓아간지 2년이 지났다. 뭐 일단 아무것도 모르는 신입에서 주니어로에서 0.1% 나아진 기분이다. 진행하던 프로젝트가 커지고 코드 퀄리티를 고민하게 되면서 캡슐화, 추상화, 컴포넌트 분리, 렌더링, 사이드 이펙트 등등 기초적인 코드와 리액트가 어떻게 사용되어야 좋은 코드인지 검색 또는 인강으로만 찾아봤지 책을 읽어볼 생각은 못했다..(핑계) 그러다 어느 블로그를 보고 이 책을 알게 되었고 이제부턴 나의 코드 교과서처럼 사용하기 위해 정리를 시작한다. 난 기본적으로 하나의 뿌리를 제대로 심는걸 좋아한다. 책의 코드를 복사해서 넣고 이게 어떤 쓰임새인지 등등 정리를 해도 안볼걸 알기 때문에 개념을 위주로 기록을 할 예정이다. 그리고 개념을 바탕삼아 향후 코드를 짤때는 최대한 적용 할..

이전에 만들었던 서비스는 기능 테스트가 없었음서비스의 규모가 점점 커짐에 따라 테스트 기능의 필요성을 느꼈고 새로 시작된 프로젝트에서는 테스트의 필요성을 느꼈다. 그러나 유닛 테스트를 하나하나 하기에는 불필요하다 느꼈고 BDD 방법론을 따라 사용자 중심의 통합 테스트를 진행하기로 함. 우선 jest 및 react-testing-library 설치!https://nextjs.org/docs/app/building-your-application/testing/jest Testing: Jest | Next.jsLearn how to set up Jest with Next.js for Unit Testing and Snapshot Testing.nextjs.org공식문서에 잘 나와있으므로 설치하고 yarn te..