글또 10기를 시작하면서 매번 바쁘다는 핑계로 지난 기수에서는 글또 활동을 충분히 하지 못했다. 이번 기수는 마지막이라는 생각에, 그동안 아쉬웠던 부분을 채우고, 적극적으로 참여하고자 한다. 특히 이번 글또를 통해 글쓰는 즐거움을 찾고 싶다. 글을 자연스럽게 표현하는 것이 개발뿐만 아니라 삶에도 큰 도움이 될 것이라고 믿기 때문이다. 글또 10기가 끝났을 때 나의 모습 1. 글쓰기 매력을 느낀다. 개인적으로 좋아하는 개발자 분들이 글쓰기의 중요성을 강조하는 것을 보고, 나 역시 공감했다. 단순한 의무감이 아니라 글쓰기의 매력을 발견하고, 이를 통해 개발뿐만 아니라 삶 전반에도 긍정적인 변화를 줄 수 있다고 생각한다. 그리고 언젠가는 많은 사람들에게 좋은 영향을 주는 글을 써보고 싶다. 2. 개발관련 글쓰기를 2주안에 최소 1번 작성한다. 솔직히 말하면, 개발과 관련된 글을 쓰는 것이 어렵게 느껴진다. ‘혹시라도 내가 쓴 글에 잘못된 내용이 있으면 어떡하지?‘라는 두려움때문에 더욱 …

✅ File Input 다루는 법 리액트 앱에서 다루기 어려운 것 중 하나가 바로 form. form 안의 input 값의 상태를 일일히 관리해주어야 하고, 각각 validation까지 해준다면 더욱 복잡해짐 React Hook Form을 통해서 한번에 form 안의 모든 input 값들을 관리할 수 있음. 그러나 file 타입의 input 값을 가져오는 일은 쉽지 않음. | 파일 타입의 인풋은 애플리케이션 계층에서 관리가 되어야 합니다. 파일 선택을 취소할 수도 있고 FileList 객체도 있기 때문입니다. (출처: react-hook-form 공식 문서) 위와 같은 이유로 react-hook-form을 사용한 다른 input들과 같은 방식으로 file input을 작성할 수 없었음 그리고 아래 이유로 value와 onChange 등을 이용하여 file input에 들어온 값을 바로 가져오기도 힘듦 | React에서 은 프로그래밍적으로 값을 설정 할 수 없고 사용자만이 값을 설…

✅ HTTP/1.1 지속 연결(Persistent Connections): 하나의 TCP 연결을 통해 여러 HTTP 요청과 응답을 처리할 수 있습니다. 청크 전송(Chunked Transfer): 데이터를 청크 단위로 전송하여 동적 콘텐츠 전송을 용이하게 합니다. 캐시 제어(Cache Control): 세밀한 캐싱 옵션을 제공하여 웹 성능을 개선합니다. 에러 처리 개선: 다양한 HTTP 상태 코드를 통해 더 명확한 에러 응답을 제공합니다. HTTP/1.1의 지속 연결과 네트워크 효율성 HTTP/1.1에서의 지속 연결 기능은 웹 성능과 효율성을 크게 향상시키는 역할을 합니다. 연결 오버헤드 감소: 각 요청마다 새로운 연결을 수립하는 대신, 하나의 연결을 재사용하여 시간과 자원을 절약합니다. 네트워크 자원의 효율적 사용: 하나의 연결을 통해 여러 요청과 응답을 처리함으로써 네트워크 자원을 효율적으로 활용합니다. TCP 연결의 성능 향상: 지속적인 연결을 통해 TCP 연결이 시간이 지남…

✅ Webpack 여러 개의 entry point로 의존성 그래프를 빌드하여, 각 모듈을 하나 이상의 모듈로 합침. JS 이외 파일(CSS, 애셋 파일 등) 처리 시 loader 필요 parcel, rollup보다 code splitting 안전성 높음 webpack-dev-server 지원 (live-reload 지원) 가장 역사가 깊으며, 레퍼런스가 많고 안정적이다 tree-shaking을 ES6 모듈에서만 지원하기 때문에 SideEffects 항목 별도 기재 필요 { sideEffects: false } 를 표시하여 사용하지 않는 export는 제거해도 괜찮음을 webpack에게 알려줌 즉 side effect가 발생해도, 해당 구문을 사용하지 않는다면 제거함 많은 서드파티를 필요로 하는 복잡한 애플리케이션 임 ✅ Parcel zero-configuration 빠른 빌드 속도 parcel의 JS 컴파일러, CSS transformer, sourcemap은 성능을 위해 Rust…

✅ Static Pages vs Dynamic Pages Static Pages Web Server는 파일 경로 이름을 받아 경로와 일치하는 파일 컨텐츠를 반환함. 이때 항상 동일한 페이지를 반환하게 됨. ex) image, html, css, javascript 파일과 같이 컴퓨터에 저장되어 있는 파일들 Dynamic Pages Web Server에 의해서 실행되는 프로그램을 통해서 만들어진 결과물로, 인자의 내용에 맞게 동적인 컨텐츠를 반환함 ✅ Web Server vs WAS 웹 서버는 소프트웨어와 하드웨어로 구분됨 웹 서버는 HTTP 프로토콜을 기반으로 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스하는 기능을 담당함. 요청에 따라 아래의 두 가지 기능 중 적절하게 선택하여 수행함 정적인 컨텐츠 제공: WAS를 거치지 않고 바로 자원을 제공함 동적인 컨텐츠 제공을 위한 요청 전달: 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언…

✅ webpack dev prod config 분리 development와 production의 빌드 목표는 서로 다름. development에서는 강력한 소스 매핑, localhost 서버에서는 라이브 리로딩이나 HMR(Hot Module Replacement) 기능을 원함. production의 목표는 로드 시간을 줄이기 위해 번들 최소화, 가벼운 소스맵 및 에셋 최적화에 초점을 맞춰야 함. 공식 문서에서는 webpack 설정을 분리하여 작성하는 것을 권장하고 있음 dev와 prod에서 공통으로 사용하는 설정들은 에 작성하고, webpack-merge를 사용하여 common의 설정 내용을 dev와 prod에서 확장하여 사용할 수 있음 ✅ babel/preset-env의 target browserslist 설정 앱을 만들 때 지원할 브라우저를 명시할 수 있음. ES6와 같은 최신 자바스크립트 문법을 사용할 때 browserslist를 명시해 주면, 트랜스파일러나 모듈 번들러가 현…

Babel이란 babel은 source-to-source compiler로, ES6 버전 이상의 JavaScript 코드를 ES5 코드로 변환하는 구문 변환(syntax transform)을 수행. JavaScript 언어를 컴퓨터 수준의 기계어로 바꾸는 것이 아니라 같은 레벨의 언어를 형태만 변환하는 것이므로 babel을 트랜스파일러(transpiler)라고 부르기도 하지만, 넓은 의미에서 컴파일러(compiler)라고 알려져 있음. babel 덕분에 개발자들은 최신 문법의 JavaScript로 편하게 개발을 할 수 있게 되었음 Babel 트랜스파일링 과정 babel 컴파일 과정 파싱(parsing) 단계: babel이 소스코드를 파싱하여 AST를 생성(이때 생성되는 트리는 JSON 형태와 비슷). AST에서 각각의 노드들은 관계를 형성 변환(transform) 단계: AST를 브라우저가 지원하는 코드로 변환. 이때 개발자가 설정한 plugin과 preset들에 의해서 컴파일됨 …

추상화 기법 도메인에 존재하는 개념들을 구조화하고 단순화하기 위해 다양한 추상화 기법을 사용할 수 있음 주요 추상화 기법의 종류들: 분류와 인스턴스화, 일반화와 특수화, 집합과 분해 객체지향의 가장 큰 장점은 동일한 추상화 기법을 프로그램의 분석, 설계, 구현 단계에 걸쳐 일관성 있게 적용할 수 있다는 점 분류와 인스턴스화 개념과 범주 도로 위를 달리는 작은 승용차와 버스, 트럭들을 가리켜 ‘자동차’라고 하며, 길거리에 자라고 있는 다양한 종류의 가로수들을 일컬어 ‘나무’라고 할 수 있음 개별 자동차와 나무는 완전히 동일하지 않지만 유사한 특성을 바탕으로 각각 ‘자동차’와 ‘나무’로 분류할 수 있음. 이처럼 객체를 분류하고 범주로 묶는 것은 객체들의 특정 집합에 공통의 개념을 적용하는 것을 의미함 자동차: 바퀴를 이용해 사람들을 한 장소에서 다른 장소로 운반하는 운송수단 (이라는 특징) 나무: 푸른 잎과 갈색의 줄기를 가진 다년생 식물 (이라는 특징) 세상에 존재하는 객체에 개념을…

들어가기 앞서 유일하게 변하지 않는 것은 모든 것이 변한다는 사실 뿐 여행 중 길을 찾는 방법은 크게 두 가지로 나눌 수 있음 기능적이고 해결책 지향적인 접근법 다른 사람에게 길을 물어봄 올바른 길을 알려줬다면 원하는 곳으로 이동할 수 있겠지만, 이 방법은 일반적이지도, 재사용 가능하지도 않음 또 중요한 랜드마크가 없다면 설명만으로 경로를 찾기 쉽지 않음 구조적이고 문제 지향적인 접근법 지도를 이용 길을 찾는 데 필요한 풍부한 컨텍스트 정보가 함축돼 있으며, 길을 묻는 방법보다 쉽고 간단 주변 지형을 추상적으로 표현하기 때문에 실세계의 환경과 우리의 지식을 밀접하게 연관 지을 수 있게 해줌 지도는 다양한 목적을 위해 재사용될 수 있으며, 범용적. ‘기능’에 대한 요구사항이 계속 변해도 지도에 표시된 ‘구조’는 안정적이기 때문 지도 은유의 핵심은, 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이라는 것. 객체지향 개발 방법은 안정…

들어가기 앞서 7장: 함께 모으기 마틴 파울러는 객체지향 설계 안에 존재하는 3 상호 연관된 관점에 대해 설명하ㅁ 개념 관점(Conceptual Perspective) 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현 도메인이란 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말하며 소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발됨 명세 관점(Specification Perspective) 도메인이 아닌 실제로 소프트웨어 안에서 살아 숨쉬는 객체들의 책임 즉 객체의 인터페이스를 바라봄 프로그래머는 객체가 협력을 위해 ‘무엇’을 할 수 있는가에 초점을 맞춤 구현 관점(Implementation Perspective) 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성하는 것 객체의 책임을 ‘어떻게’ 수행할 것인가에 초점을 맞춤 클래스는 세 가지 관점을 통해 설계와 관련된 다양한 측면을 드러냄 클래스는 세 가지 관점을 모두 수용할 수 있도록 개념, 인터페이…

들어가기 앞서 책임과 메시지 존 달리와 밥 라타네는 실험을 통해 ‘책임감 분산’이라는 현상을 발견했음. 사건에 대한 목격자가 많으면 많을수록 개인이 느끼는 책임감은 적어짐. 집단적 위기 상황에서 명확한 책임을 가진 권위자가 없을 때, 대부분의 사람들은 자신에게 명확한 책임이 없는 경우에는 발작 환자를 도와주는 일을 타인의 책임으로 간주해버림. 그에 반해 이를 보고할 책임이 명확하게 주어진 경우에는 신속하게 위기 상황을 해결하려고 노력함 이 이야기에서 훌륭한 객체지향의 세계는 명확하게 정의된 역할과 책임을 지닌 객체들이 상호 협력하는 세계라는 사실을 이끌어낼 수 있음 자율적인 책임 설계의 품질을 좌우하는 책임 객체지향 공동체를 구성하는 기본 단위는 ‘자율적’인 객체 자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체, 그 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체를 의미 적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하…

글또 9기 시작 저번 글또 8기를 하면서 느낀점은, 너무나도 많은 개발자 분들께서 진심으로 글을 매주 작성하시는 모습을 통해 많은 동기부여와 좋은 컨텐츠를 볼 수 있었고 또한, 수많은 고민들을 통해 나 혼자만 힘들게 아니다라는 사실을 알게 되었고 무엇보다 글을 쓰는 습관을 조금은 드릴 수 있어서 너무나 좋았다. 단 한가지 아쉬운점을 말하라고 한다면, 적극적으로 외부 활동 참여와 다양한 사람들과 커피챗을 해보지 못한 것이였다. 다양한 사람들이 있는 만큼 다양한 경험을 들을 수 있는 기회들이 분명있었는데, 단순히 일 때문에 바쁘다는 핑계로 스스로 합리화를 해버렸던 것 같다. 그래서 이번 기수에는 적극적으로 다양한 직군의 개발자 분들과 커피챗 신청과 외부 행사에 참여해볼 생각이다. 마지막으로 다른 분들이 어떤식으로 글을 전개해 나아가는지 흐름을 파악해서 나의 글쓰기 실력을 한층 더 높일 수 있는 시간을 가지고 싶다. 참고 글또 소개 참고

들어가기 앞서 ‘우리 모두를 합친 것보다 더 현명한 사람은 없다.’ ‘최후통첩 게임’에서 응답자와 제안자는 일반적으로 생각하는 합리적인 결정을 내리지 않았음. 인간이 가지고 있는 본연의 특성이라는 관점에서 인간은 이기적이고 합리적인 존재. 그러나 타인과 관계를 맺는 과정 속에서 인간은 본연의 특성을 배제하고 자신의 이익을 최소화하는 불합리한 선택을 하게 됨 인간이 어떤 본질적인 특성을 지니고 있느냐가 아니라, 어떤 상황에 처해 있느냐가 인간의 행동을 결정함. 즉, 각 개인이 처해 있는 정황 또는 문맥(context)이 인간의 행동 방식을 결정한다는 것 인간의 행동을 결정하는 문맥은 타인과의 협력임. 객체의 세계에서도 협력이라는 문맥이 객체의 행동 방식을 결정함. 중요한 것은 개별 객체가 아니라, 객체들 사이에 이뤄지는 협력임 어떤 협력에 참여하는지가 객체에 필요한 행동을 결정하고, 필요한 행동이 객체의 상태를 결정함 협력 요청하고 응답하며 협력하는 사람들 협력은 한 사람이 다른 사…

타입과 추상화 일단 컴퓨터를 조작하는 것이 추상화를 구축하고, 조작하고, 추론하는 것에 관한 모든 것이라는 것을 깨닫고 나면 (훌륭한) 컴퓨터 프로그램을 작성하기 위한 중요한 전제 조건은 추상화를 정확하게 다루는 능력이라는 것이 명확해짐 초기 지하철 노선도는 실제와 유사한 물리적인 지형 위에 구불구불한 운행 노선과 불규칙적인 역 간의 거리를 사실적으로 묘사하고 있었지만, 이렇게 사실적인 정보는 오히려 지하철을 이용하는 승객들로 하여금 노선도를 이해하기 어렵게 만듦 지하철 노선도 디자인에서 가장 중요한 것은 얼마나 사실적으로 지형을 묘사했느냐가 아니라 역과 역 사이의 연결성을 얼마나 직관적으로 표현했느냐임 추상화를 통한 복잡성 극복 현실은 복잡하며 예측 불가능한 혼돈의 덩어리임. 사람들은 본능적으로 이해하기 쉽고 예측 가능한 수준으로 현실을 분해하고 단순화하는 전략을 따름 헨리 백의 지하철 노선도는 불필요한 지형 정보를 제거함으로써 단순함을 달성한 추상화의 훌륭한 예. 진정한 의미에…

이상한 나라의 객체 가림막 막대 실험 사람은 아기 때부터 뚜렷한 경계를 가지고 함께 행동하는 물체를 하나의 개념으로 인지 물체가 여러 부분으로 구성돼 있더라도 함께 움직일 경우 그 물체를 하나의 유기적인 단위로 인식 객체지향과 인지 능력 인간은 본능적으로 세상을 독립적이고 식별 가능한 객체의 집합으로 바라봄 객체지향은 세상을 자율적이고 독립적인 객체들로 분해할 수 있는 인간의 기본적인 인지 능력에 기반을 두고 있음 인간의 인지 능력은 물리적인 한계를 넘어 개념적으로 경계 지을 수 있는 추상적인 사물까지도 객체로 인식할 수 있게 함 객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것 객체지향 패러다임은 소프트웨어의 세계 역시 다양한 소프트웨어 객체들이 모여 이뤄져 있다는 믿음에서 출발. 객체지향 패러다임의 목적은 현실 세계를 기반으로 새로운 세계를 창조하는 것 객체, 그리고 이상한 나라 이상한 나라의 앨리스 동화 속 앨리스는 작은 문을 통과하…

협력하는 객체들의 공동체 객체지향의 목표는 실세계를 모방하는 것이 아니라, 새로운 세계를 창조하는 것. 단순히 실세계를 소프트웨어 안으로 옮겨 담는 것이 아니라, 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것 협력하는 사람들 커피 공화국의 아침 카페테리어에서 커피를 주문하고 받는 과정에는 손님, 캐시어, 바리스타 사이의 암묵적인 협력 관계가 존재 커피 주문이라는 협력에 참여하는 모든 사람들은 각자 맡은 바 역할과 책임을 다하고 있음 요청과 응답으로 구성된 협력 사람들은 문제 해결에 필요한 지식을 알고 있거나 서비스를 제공해줄 수 있는 사람에게 도움을 요청 요청은 연쇄적으로 발생 요청을 받은 사람은 주어진 책임을 다하면서 필요한 지식이나 서비스를 제공, 즉 요청에 응답 우리는 요청과 응답을 통해 다른 사람과 협력하여 문제를 해결 역할과 책임 역할은 협력 안에서 차지하는 책임이나 임무를 의미 특정한 역할은 특정한 책임을 암시 사람들은 협력을 위해 특정한 역할을 맡고 역할에 적…

12.1 메서드 올리기 메서드 올리기를 적용하기 가장 쉬운 상황은 메서드들의 본문 코드가 똑같을 때. 그러나 메서드 올리기 리팩터링을 적용하려면 선행 단계를 거쳐야 할 때가 많음 메서드 올리기를 적용하기에 가장 이상하고 복잡한 상황은 해당 메서드의 본문에서 참조하는 필드들이 서브클래스에만 있는 경우. 두 메서드의 전체 흐름은 비슷하지만 세부 내용이 다르다면 템플릿 메서드 만들기를 고려 절차 똑같이 동작하는 메서드인지 면밀히 살핌 메서드 안에서 호출하는 다른 메서드와 참조하는 필드들을 슈퍼클래스에서도 호출하고 참조할 수 있는지 확인 메서드 시그니처가 다르다면 함수 선언 바꾸기로 슈퍼클래스에서 사용하고 싶은 형태로 통일 슈퍼클래스에 새로운 메서드를 생성하고, 대상 메서드의 코드를 복사해넣음 정적 검사를 수행 서브클래스 중 하나의 메서드를 제거 모든 서브클래스의 메서드가 없어질 때까지 다른 서브클래스의 메서드를 하나씩 제거 예시 12.2 필드 올리기 서브클래스의 필드들이 비슷한 방식으로…

11.7 세터 제거하기 세터 메서드가 있다는 것은 필드가 수정될 수 있다는 뜻. 객체 생성 후에는 수정되지 않길 원하는 필드라면 세터를 제공하지 않았을 것 세터 제거하기 리팩터링이 필요한 상황은 주로 두 가지임 첫째, 사람들이 무조건 접근자 메서드를 통해서만 필드를 다루려 할 때 두 번째는 클라이언트에서 생성 스크립트를 사용해 객체를 생성할 때 절차 설정해야 할 값을 생성자에서 받지 않는다면 그 값을 받을 매개변수를 생성자에 추가함. 그런 다음 생성자 안에서 적절한 세터를 호출 생성자 밖에서 세터를 호출하는 곳을 찾아 제거하고, 대신 새로운 생성자를 사용하도록 함 세터 메서드를 인라인. 가능하다면 해당 필드를 불변으로 만듦 예시 11.8 생성자를 팩터리 함수로 바꾸기 생성자에는 이상한 제약이 따라붙기도 함. 자바 생성자는 반드시 생성자를 정의한 클래스의 인스턴스를 반환해야 함. 생성자의 이름도 고정되며, 생성자를 호출하려면 특별한 연산자(new)를 사용해야 함 -> 팩터리 함수에는…

11.1 질의 함수와 변경 함수 분리하기 겉보기 부수효과가 있는 함수와 없는 함수는 명확히 구분하는 것이 좋음. 질의 함수(읽기 함수)는 모두 부수효과가 없어야 함. 이를 ‘명령-질의 분리’라고도 함 절차 대상 함수를 복제하고 질의 목적에 충실한 이름을 지음 새 질의 함수에서 부수효과를 모두 제거 정적 검사를 수행 원래 함수(변경 함수)를 호출하는 곳을 모두 찾아냄. 호출하는 곳에서 반환 값을 사용한다면 질의 함수를 호출하도록 바꾸고, 원래 함수를 호출하는 코드를 바로 아래 줄에 새로 추가함.하나 수정할 때마다 테스트 진행 원래 함수에서 질의 관련 코드를 제거함 테스트 예시 11.2 함수 매개변수화하기 두 함수의 로직이 아주 비슷하고 단지 리터럴 값만 다르다면, 그 다른 값만 매개변수로 받아 처리하는 함수 하나로 합쳐서 중복을 없앨 수 있음. 절차 비슷한 함수 중 하나를 선택함 함수 선언 바꾸기로 리터럴들을 매개변수로 추가함 이 함수를 호출하는 곳 모두에 적절한 리터럴 값을 추가함…

10.5 특이 케이스 추가하기 코드베이스에서 특정 값에 대해 똑같이 반응하는 코드가 여러 곳이라면 그 반응들을 한 데로 모으는 게 효율적임 이때 특수한 경우의 공통 동작을 요소 하나에 모아서 사용하는 특이 케이스 패턴을 사용함 절차 리팩터링의 대상이 될 속성을 담은 데이터 구조(혹은 클래스)를 컨테이너라고 함 컨테이너에 특이 케이스인지를 검사하는 속성을 추가하고, 를 반환하게 함 특이 케이스 객체를 만듦. 이 객체는 특이 케이스인지를 검사하는 속성만 포함하며, 이 속성은 를 반환하게 함 클라이언트에서 특이 케이스인지를 검사하는 코드를 함수로 추출함. 모든 클라이언트가 값을 직접 비교하는 대신 방금 추출한 함수를 사용하도록 고침 코드에 새로운 특이 케이스 대상을 추가함. 함수의 반환 값으로 받거나 변환 함수를 적용 특이 케이스를 검사하는 함수 본문을 수정하여 특이 케이스 객체의 속성을 사용 테스트 여러 함수를 클래스로 묶기나 여러 함수를 변환 함수로 묶기를 적용하여 특이 케이스를 처…

10.1 조건문 분해하기 복잡한 조건부 로직은 프로그램을 복잡하게 만듦 코드를 부위별로 분해한 다음 해체된 코드 덩어리들을 각 덩어리의 의도를 살린 이름의 함수 호출로 바꿔주면 전체적인 의도가 더 확실히 드러남 절차 조건식과 그 조건식에 딸린 조건절 각각을 함수로 추출함 예시 10.2 조건식 통합하기 비교하는 조건은 다르지만 그 결과로 수행하는 동작은 똑같은 코드들이 있다면 조건 검사도 하나로 통합하는 것이 좋음 연산자와 연산자를 사용하면 여러 개의 비교 로직을 하나로 합칠 수 있음 조건부 코드를 통합하는 것이 중요한 이유는 2가지 여러 조각으로 나뉜 조건들을 하나로 통합함으로써 내가 하려는 일이 더 명확해짐 복잡한 조건식을 함수로 추출하면 코드의 의도가 훨씬 분명하게 드러남 절차 해당 조건식들 모두에 부수효과가 없는지 확인함 조건문 두 개를 선택하여 두 조건문의 조건식들을 논리 연산자로 결합함 테스트함 조건이 하나만 남을 때까지 2~3 과정을 반복함 하나로 합쳐진 조건식을 함…

9.1 변수 쪼개기 역할이 둘 이상인 변수가 있다면 쪼개야 함. 역할 하나당 변수 하나임 절차 변수를 선언한 곳과 값을 처음 대입하는 곳에서 변수 이름을 바꿈 가능하면 이때 불변으로 선언함 이 변수에 두 번째로 값을 대입하는 곳 앞까지의 모든 참조(이 변수가 쓰인 곳)를 새로운 변수 이름으로 바꿈 두 번째 대입 시 변수를 원래 이름으로 다시 선언함 테스트함 반복함 매 반복에서 변수를 새로운 이름으로 선언하고 다음번 대입 때까지의 모든 참조를 새 변수명으로 바꿈. 이 과정을 마지막 대입까지 반복함. 예시 9.2 필드 이름 바꾸기 데이터 구조는 프로그램을 이해하는 데 큰 역할을 함 클래스에서 게터와 세터 메서드의 이름은 레코드 구조체의 필드 이름만큼 중요함 절차 레코드의 유효 범위가 제한적이라면 필드에 접근하는 모든 코드를 수정한 후 테스트함. 이후 단계는 필요 없음 레코드가 캡슐화되지 않았다면 우선 레코드를 캡슐화함 캡슐화된 객체 안의 필드명을 변경하고, 그에 맞게 내부 메서드들을…

8.5 인라인 코드를 함수 호출로 바꾸기 함수는 동작의 목적을 말해주기 때문에 코드를 이해하기 쉽게 해주고, 중복을 없애줌 이미 존재하는 함수와 똑같은 일을 하는 인라인 코드를 발견하면 해당 코드를 함수 호출로 대체할 수 있음. 특히 라이브러리가 제공하는 함수로 대체할 수 있다면 훨씬 좋음 절차 인라인 코드를 함수 호출로 대체 테스트 예시 8.6 문장 슬라이드하기 하나의 데이터 구조를 이용하는 문장들은 한데 모여 있어야 좋음 문장 슬라이드하기 리팩터링으로 이런 코드들을 한데 모아둘 수 있음 관련 있는 코드들은 명확히 구분되는 함수로 추출하는 것이 좋음 절차 코드 조각(문장들)을 이동할 목표 위치를 찾음 코드 조각의 원래 위치와 목표 위치 사이의 코드들을 훑어보면서, 조각을 모으고 나면 동작이 달라지는 코드가 있는지 살핌 코드 조각을 원래 위치에서 잘라내어 목표 위치에 붙여 넣음 테스트함 예시 코드 조각을 슬라이드할 때는 1) 무엇을 슬라이드할지와 2) 슬라이드할 수 있는지 여부를 …

8.1 함수 옮기기 모듈성이란 프로그램의 어딘가를 수정하려 할 때 해당 기능과 깊이 관련된 작은 일부만 이해해도 가능하게 해주는 능력 모듈성을 높이려면 서로 연관된 요소들을 함게 묶고, 요소 사이의 연결 관계를 쉽게 찾고 이해할 수 있도록 해야 함 모든 함수는 어떤 컨텍스트 안에 존재하며, 대부분은 특정 모듈에 속함. 캡슐화를 위해 함수를 함수가 참조하는 곳이 많은 모듈로 옮겨주는 것이 좋음 또한 호출자들의 현재 위치나 다음 업데이트 때 바뀌리라 예상되는 위치에 따라서도 함수를 옮겨야 할 수 있음 함수를 옮기기 전, 대상 함수의 현재 컨텍스트와 후보 컨텍스트를 둘러보고 대상 함수를 호출하는 함수, 대상 함수가 호출하는 함수, 대상 함수가 사용하는 데이터를 살펴봐야 함 절차 선택한 함수가 현재 컨텍스트에서 사용 중인 모든 프로그램 요소를 살펴보고 이 요소들 중에도 함께 옮겨야 할 게 있는지 고민 해봄 선택한 함수가 다형 메서드인지 확인 선택한 함수를 타겟 컨텍스트로 복사 후, 타겟 …

7.1 레코드 캡슐화하기 캡슐화 모듈을 분리할 때는 각 모듈이 자신을 제외한 다른 부분에 드러내지 않아야 할 비밀을 잘 숨겨야 함 이때 레코드 캡슐화, 컬렉션 캡슐화, 기본형을 객체로 바꿔 캡슐화하는 방법 등이 많이 쓰임 클래스를 이용하면 내부 정보를 숨길 수 있을 뿐 아니라 위임 숨기기를 통해 클래스 사이의 연결 관계를 숨길 수도 있음 알고리즘을 함수로 추출하여 구현을 캡슐화하는 방법도 있음 레코드 캡슐화 가변 데이터를 저장할 때는 레코드보다 객체를 선호 객체를 사용하면 어떻게 저장했는지를 숨긴 채 각각의 값을 서로 다른 메서드로 제공할 수 있음 레코드 구조는 필드 이름을 노출하는 형태와 필드를 외부로부터 숨겨서 원하는 이름을 쓸 수 있는 형태 두 가지로 구분할 수 있음 후자는 주로 라이브러리에서 해시(hash), 맵(map), 해시맵(hashmap), 딕셔너리(dictionary), 연관 배열(associative array) 등의 이름으로 제공 절차 레코드를 담은 변수를 캡슐…

6.1 함수 추출하기 코드 조각을 찾아 무슨 일을 하는지 파악한 다음, 독립된 함수로 추출하고 목적에 맞는 이름 붙임 코드를 독립된 함수로 묶는 기준은 ‘목적과 구현을 분리’하는 것 코드를 보고 무슨 일을 하는지 파악하는 데 한참이 걸린다면 그 부분을 함수로 추출한 뒤 ‘무슨 일’에 걸맞는 이름을 지음 함수는 짧게 작성(함수가 짧으면 캐싱하기도 쉽기 때문에 컴파일러가 최적화하는 데 유리할 때가 많음) 짧은 함수는 이름 짓기에 특별히 신경 써야 함(별도의 문서 없이 코드 자체만으로 내용을 충분히 설명되게 만들어야 함) 절차 함수를 새로 만들고 목적을 잘 드러내는 이름을 붙임 (’어떻게’가 아닌 ‘무엇을’ 하는지가 드러나야 함) 추출할 코드를 원본 함수에서 복사하여 새 함수에 붙여넣음 추출한 코드 중 원본 함수의 지역 변수를 참조하거나 추출한 함수의 유효범위를 벗어나는 변수는 없는지 검사(있다면 매개변수로 전달함) 변수를 다 처리했다면 컴파일 원본 함수에서 추출한 코드 부분을 새로 만…

4.1 자가 테스트 코드의 가치 리팩터링을 제대로 하기 위해서는 실수를 잡아주는 견고한 테스트가 뒷받침돼야 한다. 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자 컴파일할 때마다 테스트도 함께 하면 생산성을 높일 수 있음 자가 테스트 코드 자체뿐 아니라 테스트를 자주 수행하는 습관도 버그를 찾는 강력한 도구가 됨 테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는 데 걸리는 시간을 대폭 줄여줌 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전 기능을 추가해야 할 때 테스트부터 작성 함 이로부터 켄트 벡의 ‘테스트 주도 개발(TDD)’ 기법이 탄생 TDD에서는 테스트를 작성하고, 이 테스트를 통과하게끔 코드를 작성하고, 결과 코드를 최대한 깔끔하게 리팩터링하는 과정을 짧은 주기로 반복 4.2 테스트할 샘플 코드 비즈니스 로직 코드를 UI와 분리하여 코드를 파악하고 테스트하기 편하게 만들어줄 수 있음 4.3 첫 번째 테스트 테스트를 두 단계로 진행 실…

3.1 기이한 이름 코드는 단순하고 명료하게 작성해야 함 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각의 역할을 알 수 있도록 이름 지어야 함 이름 짓기는 프로그래밍에서 가장 어렵기로 손꼽히는 일 중 하나임 3.2 중복 코드 똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합할 수 있음 한 클래스에 딸린 두 메서드가 똑같은 표현식을 사용하는 경우 → 함수 추출하기 코드가 비슷하긴 한데 완전히 똑같지는 않다면 → 문장 슬라이드하기 같은 부모로부터 파생된 서브 클래스들에 코드가 중복되어 있다면 → 메서드 올리기 3.3 긴 함수 짧은 함수들은 간접 호출의 효과를 낼 수 있다. 코드를 이해하고, 공유하고, 선택하기 쉬워진다는 장점이 있음 짧은 함수로 구성된 코드를 이해하기 쉽게 만들기 위해서는 함수 이름을 잘 지어두어야 함 적극적으로 함수를 쪼개고, 함수 이름은 동작 방식이 아닌 ‘의도’가 드러나게 지어야 함 함수 추출하기 임시 변수를 질의 함수로 바꾸기 매개변수 객체 만들…

글또 8기 회고 결론 부터 말씀드리면 글또를 시작 이후, 매주 마다 개인적으로 주간회고 글을 작성하는 습관을 갖게 되었습니다. 물론 주간 회고 글내용이 많이 빈약하다고 느끼지만, 글을 작성하면서 느끼는 감정들 그리고 조금이라도 배운 내용을 적는 노력을 하면서 내심 뿌듯함도 느끼는 시간을 의식적으로 갖게 되었습니다. 또한 글또를 시작하면서 다양한 개발자 분들의 좋은 글들을 읽을 수 있었습니다. 수준 높은 퀄리티 글을 통해 저의 식격을 더욱 넓히게 된 시간이 었던 것 같습니다. 개인적으로 많이 아쉬운 것은 오프라인으로 글또에 참여하시는 개발자 분들을 만나서 대화를 하지 못했다는 것 입니다. 다음에 기회가 된다고 꼭 참여해 이런저런 이야기를 해보고 싶습니다. 마지막으로 글을 작성할 때, 조금 더 깊이 생각하고 저를 위한 글이 아닌 타인을 위한 글을 작성하기 위해 노력하고 싶습니다. 개인적으로 배운 내용들을 잘 정리하는 것을 타인에게 도움이 될 정도의 수준으로 글을 잘 작성하고 싶은 욕심…

2.1 리팩터링 정의 리팩터링의 사전적 정의 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 리팩터링 이란 동작을 보존하는 작은 단계들을 거쳐 코드를 수정하고, 이러한 단계들을 순차적으로 연결하여 큰 변화를 만들어내는 일 “재구성” 의 특수한 한 형태 단계를 작게 나눔으로써 구성을 체계화할 수 있고, 디버깅 시간을 단축할 수 있음 사용자 관점에서는 달라지는 점이 없음 리팩터링 과정에서 발견된 버그는 리팩터링 후에도 그대로 남아 있어야 함 성능 최적화와 비슷 코드를 이해하고 수정하기 쉽게 만드는 것 2.2 두 개의 모자 켄트 백은 소프트웨어 개발의 목적을 또는 으로 나누고, 이를 두 개의 모자라고 명명한다. 시에는 기존 코드는 절대 건드리지 않고 새 기능을 추가하기만 한다. 반면 시에는 기능 추가는 절대 하지 말아야 한다. (테스트도 새로 만들지 않는다) 2.3 리팩터링하는 이유 리팩터링하면 소프트웨어 설계가 좋아짐 리…

1.6 계산 단계와 포맷팅 단계 분리하기 앞서 작성한 코드를 두 단계로 나눔 에 필요한 데이터를 처리 앞서 처리한 결과를 텍스트나 HTML로 표현 그 다음 함수를 추출 이때 계산 관련 코드는 전부 함수로 모으고 는 `data 매개변수로 전달된 데이터만 처리하게 만듦 연극 제목도 중간 데이터 구조에서 가져옴 이제 함수와 함수를 로 옮겨줌 안에서 와 를 호출하던 부분을 중간 데이터를 사용하도록 바꿔주고, 같은 방식으로 다른 중첩 함수들도 옮겨주었음 다음으로는 반복문을 파이프라인으로 바꿈 이제 에 필요한 데이터 처리에 해당하는 코드를 모두 별도 함수로 빼냄 마지막으로, 단계별로 분리한 코드를 별도 파일에 저장한 후 HTML 버전을 작성 함 1.7 중간 점검: 두 파일(과 두 단계)로 분리됨 statement.js createStatementData.js 함수를 추출하면서 코드량은 많이 늘었지만, 모듈화를 통해 전체 로직을 구성하는 요소 각각이 더 뚜렷해지고 계산하는 부분과 출력 …

1.2 예시 프로그램 프로그램이 새로운 기능을 추가하기에 편한 구조가 아니라면, 먼저 기능을 추가하기 쉬운 형태로 리팩터링하고 나서 원하는 기능을 추가 함 1.3 리팩터링의 첫 단계 리팩터링할 코드 영역을 꼼꼼하게 검사해줄 테스트 코드 마련하기 리팩터링하기 전에 제대로 된 테스트부터 마련 1.4 statement() 함수 쪼개기 테스트 간단한 수정도 리팩터링 후에는 항상 테스트하는 습관 조금씩 변경하고 매번 테스트하는 것은 리팩터링 절차의 핵심 함수 추출하기 자바스크립트에서는 중첩 함수를 사용하면 바깥 함수의 변수를 새로 추출한 함수에 매개변수로 전달할 필요가 없음. 추출된 함수 코드에서 보다 명확하게 표현할 수 있는 것들을 찾아야 함 (ex. 변수 이름) 추출된 함수의 반환 값은 result 등의 네이밍으로 통일해줄 수 있음 임시 변수 제거 적립 포인트 계산 코드 추출 format 변수 제거 함수 선언 바꾸기(함수의 핵심 기능을 살려주는 네이밍으로 바꿈) volumeCredits…

아이템 58: 모던 자바스크립트로 작성하기 타입스크립트의 컴파일러를 자바스크립트의 ‘트랜스파일러’로 사용 타입스크립트는 자바스크립트의 상위집합이므로 타입스크립트를 자바스크립트로 컴파일할 수 있음 ECMAScript 모듈 사용 ES2015에 등장한 import와 export 를 사용하는 모듈이 표준이 되었음 프로토타입 대신 클래스 사용 대신 사용 스코프 문제 피하기 함수 선언문 대신 함수 표현식을 사용하여 호이스팅 문제 피하기 대신 또는 배열 메서드 사용 루프는 코드가 짧고 인덱스 변수를 사용하지 않아 실수를 줄일 수 있음 인덱스 변수가 필요한 경우엔 메서드 사용 권장 함수 표현식보다 화살표 함수 사용 상위 스코프의 this를 유지할 수 있음 코드를 더 직관적이고 간결하게 작성할 수 있음 단축 객체 표현과 구조 분해 할당 사용 변수와 객체 속성의 이름이 같은 경우 객체 속성 중 함수를 축약해서 표현하는 방법 객체 구조 분해 함수 매개변수 기본값 사용 기본값을 기반으로 타입…

아이템 53: TS 기능보다는 ECMAScript 기능을 사용하기 JS에 새로 추가된 기능은 TS의 초기 기능과 호환성 문제를 발생 JS의 신규 기능을 그대로 채택하고 TS 초기 버전과 호환성을 포기 그러나 이미 사용되고 있던 몇 가지 기능(호환성 문제로 지양하는 방식) 있음 열거형(enum) 몇몇 값의 모음을 나타내는 방식 문제점 숫자 열거형에 0, 1, 2 외의 다른 숫자가 할당되면 매우 위험 상수 열거형(const enum)은 런타임에 완전히 제거되어, 문자열 열거형에서 문제를 일으킴 preserveConstEnums 플래그를 설정한 상수 열거형은 런타임 코드에 정보를 유지함 문자열 열거형은 구조적 타이핑이 아닌 명목적 타이핑을 사용함 문자열 열거형의 명목적 타이핑은 JS와 동작이 다르다는 문제가 있음 매개변수 속성 생성자의 매개변수를 사용하여 클래스 초기화 시 TS는 간결한 문법을 제공 문제점 실제로는 코드가 늘어남 매개변수 속성은 런타임에는 실제로 사용되지만, TS에서는 …

아이템 45: devDependencies에 TS와 @types 추가하기 npm의 의존성 구분 dependencies: 현재 프로젝트 실행 시 필수적인 라이브러리 devDependencies: 런타임에는 필요없는 라이브러리 peerDependencies: 런타임에 필요하긴 하지만, 의존성을 직접 관리하지 않는 라이브러리 TS는 개발 도구일 뿐이고 타입 정보는 런타임에 존재하지 않기 때문에, TS와 관련된 라이브러리는 일반적으로 devDependencies에 속함 TS 프로젝트에서 고려해야 할 의존성 TS 시스템 레벨로 설치하기보다는 devDependencies에 넣는 것을 권장 → npm install 시 팀원들 모두 항상 정확한 버전의 TS 설치 가능 대부분의 TS IDE와 빌드 도구는 devDependencies를 통해 설치된 타입스크립트의 버전을 인식할 수 있음 DefinitelyTyped에서 라이브러리에 대한 타입 정보를 얻을 수 있음 @types 라이브러리는 타입 정보만 …

아이템 38: any 타입은 가능한 한 좁은 범위에서만 사용하기 any 작성 방식 any 타입이 processBar 함수의 매개변수에만 사용된 표현식이므로 다른 코드에는 영향을 미치지 않기 때문 TS가 함수의 반환 타입을 추론할 수 있는 경우에도 함수의 반환 타입을 명시하는 것이 좋음 강제로 타입 오류 제거 시 any 대신 @ts-ignore 사용 객체와 관련한 any의 사용법 아이템 39: any를 구체적으로 변형해서 사용하기 일반적인 상황에서는 any보다 더 구체적으로 표현할 수 있는 타입이 존재할 가능성이 높음 함수 매개변수로 객체 사용 시 타입 구체화 함수 타입 구체화 아이템 40: 함수 안으로 타입 단언문 감추기 함수 내부에는 타입 단언 사용하고, 함수 외부로 드러나는 타입은 정의를 정확히 명시하는 것이 좋음 어떤 함수든 캐싱할 수 있는 래퍼 함수 단언문을 추가해서 오류를 제거 객체를 매개변수로 하는 shallowObjectEqual 아이템 41: Any 타입의 변환 예…

✏️ 아이템 28: 유효한 상태만 표현하는 타입을 지향하기 애플리케이션의 상태 표현하기 모든 상황 고려하기 어떤 값들을 포함하고 어떤 값들을 제외할지 신중하기 생각하기 ✏️ 아이템 29: 사용할 때는 너그럽게, 생성할 때는 엄격하게 TCP 구현체의 견고성 원칙 또는 포스텔의 법칙(함수의 시그니처에도 적용가능) 함수의 매개변수는 타입의 범위가 넓어도 되지만, 결과를 반환할 때는 일반적으로 타입의 범위가 더 구체적이어야 함 예시 👎 Bad Case 👍 Good Case → 매개변수와 반환 타입의 재사용을 위해서 기본 형태(반환 타입)와 느슨한 형태(매개변수 타입)를 지향 ✏️ 아이템 30: 문서에 타입 정보를 쓰지 않기 타입 구문은 TS 타입 체커가 타입 정보를 동기화하도록 강제 함수의 입력과 출력의 타입을 코드로 표현하는 것이 주석보다 더 나음 값을 변경하지 않는다고 설명하는 주석 대신, readonly 사용 변수명에 타입 정보 넣지 않기 (단위가 있는 숫자들은 제외) ✏️ 아이템 31:…

✏️ 아이템 19: 추론 가능한 타입을 사용해 장황한 코드 방지하기 코드의 모든 변수에 타입을 선언하는 것은 비 생산적 객체는 비구조화 할당문 사용 지향 모든 지역 변수의 타입이 추론되도록 해야 함 타입 구문을 생략하는 경우 함수 내에서 생성된 지역 변수 함수 파라미터에 기본 값이 있는 경우 타입을 명시하면 좋은 경우 객체 리터럴을 정의할 때, 잉여 속성 체크가 동작 함 함수의 반환 타입 함수의 입출력 타입에 대해 더욱 명확하게 알 수 있음 명명된 타입을 사용할 수 있음 cf) eslint 규칙 중 사용 가능 작성된 모든 타입 구문이 정말로 필요한지 확인 ✏️ 아이템 20: 다른 타입에는 다른 변수 사용하기 변수의 값은 바뀔 수 있지만, 그 타입은 바뀌지 않음 타입 확장하기 - 유니온 타입 ✏️ 아이템 21: 타입 넓히기 TS가 작성된 코드를 체크하는 정적 분석 시점에, 변수는 값들의 집합인 타입을 가짐 TS의 지정된 단일 값을 가지고 할당 가능한 값들의 집합을 유추하는 것 넓히기…

✏️ 아이템 13: 타입과 인터페이스의 차이점 알기 인터페이스와 타입 모두 사용 가능한 경우 인덱스 시그니처 함수 타입 제너릭 인터페이스는 다른 타입을 포함할 수 있어 타입을 확장 할 수 있고 타입이 인터페이스를 포함 시킬 경우 인터페이스를 확장 할 수 있음 인터페이스가 타입을 확장하는 경우 타입이 인터페이스를 확장하는 경우 인터페이스와 타입의 차이점 인터페이스는 객체의 구조를 정의하기 위한 것으로 사용 타입은 객체, 변수, 함수 등의 값을 설명하기 위해 사용 유니온 타입은 있지만 유니온 인터페이스는 없음 유니온 타입 확장이 필요한 경우 유니온 타입에 추가 속성을 붙인 타입 만들기(인터페이스로 표현 불가) 튜플과 배열 타입 타입에는 없는 인터페이스의 보강 기능(선언 병합) TS는 여러 버전의 JS 표준 라이브러리에서 타입을 모아 병합 함 타입은 기존 타입에 추가적인 보강이 없는 경우에만 사용해야 함 복잡한 타입이라면 타입 별칭을, 간단한 객체 타입이라면 인터페이스를 사용(협업시 일…

✏️ 아이템 6: 편집기를 사용하여 타입 시스템 탐색하기 TS에서 실행할 수 있는 프로그램 TS 컴파일러(tsc) 단독 실행 가능한 TS 서버(tsserver) TS 서버에서 제공하는 언어 서비스를 사용 권장 많은 편집기에서 TS가 그 타입을 어떻게 판단하는지 확인 가능 편집기 타입 오류를 살펴보는 것도 타입 시스템을 파악하는 데 좋은 방법 라이브러리와 라이브러리의 타입 선언 Go to Definition 옵션으로 에서 타입 정의 확인 가능 ✏️ 아이템 7: 타입이 값들의 집합이라고 생각하기 런타임시 모든 변수는 JS로 정해진 고유한 값 존재 코드가 실행되기 전 TS가 오류를 체크하는 순간에는 타입을 가지고 있으며, 이는 할당 가능한 값들의 집합 집합의 종류 : 아무것도 포함하지 않는 공집합(아무 값도 할당 불가) cf) 는 undefined 반환 리터럴(유닛)타입 : 한 가지 값만 포함하는 타입 유니온 타입 : 두 개 혹은 세 개 값 포함하는 집합들의 합집합 ‘할당 가능’하다는 뜻…

✏️ 아이템 1: 타입스크립트와 자바스크립트의 관계 “타입스크립트는 자바스크립트의 상위집합(superset)이다” 그렇기 때문에 JS 코드는 이미 TS다. 기존 JS 코드를 타입스크립트로 마이그레이션하는데 큰 이점 타입 구문을 사용하는 순간부터 JS는 TS 영역으로 들어가게 됨 타입 시스템에서는 런타임에 오류를 발생시킬 코드를 미리 찾아낸다. 타입을 명시적으로 선언하여 의도를 분명하게 하면 오류를 구체적으로 알 수 있다. ✏ 아이템 2: 타입스크립트 설정 으로 타입스크립트 설정 작성 : 변수들이 미리 정의된 타입을 가져야 하는지 여부를 제어(any 타입을 사용하면 에러 설정) strictNullChecks 과 가 모든 타입에서 허용되는지 설정 ✏ 아이템 3: 코드 생성과 타입은 관계가 없음 TS 컴파일러는 2가지 역할을 수행 최신 TS,JS를 브라우저에서 동작할 수 있도록 구버전 JS로 트랜스파일 함 코드의 타입 오류를 체크 함 타입 오류가 있는 코드도 컴파일 가능 컴파일은 타입 …

글 작성 회고 오늘은 제가 글또에 제출한 글들에 대한 회고하는 시간을 가져보고자 합니다. 문득 반성(회고)하지 않은 사람은 발전이 없다는 이야기가 생각이 났습니다. 저도 사실 최근에 회고하기보다는 매일 매일 새로운 것을 알아가는 것에 집중했던 것 같습니다. 이번 글을 작성하면서 지금까지 글을 작성하면서 스스로 질문하고 답변하는 시간을 가져보았습니다. 처음 글이 마음에 들었나요?? 글또 스터디를 시작하고 자연스럽게 글 소재에 대해 고민을 하게 되었습니다. 개인적으로 좋은 해외 개발 아티클을 번역하고 싶어 시도했지만, 정말 어려웠습니다. 마음처럼 빠르게 글도 안 써지고 내가 알고 있는 단어의 뜻이 문장에서 어색함이 너무나 많았습니다. 또한 이 글을 읽었을 때 과연 잘 이해가 될까? 라는 의심도 많았습니다. 그래서 솔직히 100% 마음에 들지는 않아, 다음 번역을 할 때는 문장이 적은 것을 선택해야겠습니다. 글을 작성할 때 나의 감정은 어땠나요? 아주 답답했습니다. 위에도 작성했지만, …

💪 배운 내용 란 엉킨 코드를 푸는 것 엉킨 코드를 푸는 단계 액션 - 계산 - 데이터로 먼저 분리 계산 : 명시적 입,출력 & 계층적 구조, 추상화의 벽 다시 알맞게 조립(파이프라인) 일급함수 이용 반복문 이용(map, filter, reduce 등) 파이프라인 구조 이터레이터 시간 -> 타임라인 ValueCell(책 P.515) & 만들어진 RxJS 데이터의 단방향 변경 전파 반응형 아키텍처(Reactive Architectures) Redux 아키텍처 각 단계 별로 가는 것이 좋다. Data -> 비즈니스로 점프하지 않도록 주의하자 👍🏻 실습 를 구현 에러를 어떻게 핸들링할 것인가를 고민 엣지 케이스를 찾아서 고쳐보기 잘 구현된 라이브러리를 보면서 고민 RxJS를 보면서 어떻게 핸들링 하는지 찾아보기 참고 함수형 프로그래밍 스터디 RxJS Visualizer RxJS 한번 배워보실래요? 엉킨 코드를 푸는 단계 데이터의 단방향 변경 전파 참고

💪 배운 내용 함수형 관점에서 시간(비동기) 바라보기 시간(액션) → 데이터로 생각해보기 → 중간에 분기 역할을 하는 것이 존재 하고 이러한 것을 모나드라고 한다. Promise의 구현된 코드를 파악해보자 함수형 관점에서 callback의 문제점은? 위의 코드는 명시적 출력이 없기 때문에 액션임 로 만들게 되면 명시적 출력을 통해 값을 만들 수 있음 액션(동작)을 값(데이터)로 만들 수 있음 즉, 액션을 계산으로 그리고 계산으로 생각하는 것이 모나드 개념 액션 → 계산 → 액션 → 계산 → 액션 → 데이터와 같은 과정에성 중간에 시간과 같은 액션이 들어올 때 처리 하는 방법 중 하나가 이다.() ⭐️ 실습 구현하기 성공 Case와 실패 Case를 구분 🌈 정리 우리는 액션을 계산으로 분리시키는 작업을 진행 계산을 명시적 입력과 출력으로 바꾸는 리팩토링 과정을 진행 계산들을 모아서 하나의 계산으로 만들고 나중에 인자를 넣는 Pipe 함수를 실습함 제너레이터를 만들어서 순차적인 계산…

✅ 복습 1부 액션, 계산, 데이터로 나누는 것이 중요 함수형 프로그래밍의 기본은 데이터를 변하는 것과 변하지 않는 것을 나뉘어서 구분하는 것 명시적 입력과 출력을 만들자(불변성) Ex) 를 통해서, 카피온라이트를 사용할 수 있다. 계층적 구조 : 계산(스키마, 비즈니스로직, 유틸) 의 개념을 이해하는 것이 중요 의 구조를 아는 것이 중요 2부 함수형 기법 1급 함수 : 함수로 인자를 받고 반환하는 것 계산을 다시 비지니스 로직과 유틸로 구분하는 법을 배우면서 동시에 “함수형 언어가 가지고 있는 1급이라는 개념과 함수형 유틸성” 을 이해하기 위한 “기초”를 배우는 것 Iterator와 Generator는 실무 자바스크립트에서는 잘 쓰이지 않음 와 는 함수형 프로그래밍에서 중요 함수형 프로그래밍은 “유틸리티 함수들의 모음집” 같은 것이 아님 “함수형 프로그래밍이란 단방향 데이터 처리의 파이프라인” 이라는 감각이 이해가 된다면, Array의 map, filter, reduce를…

💻 함수형 프로그래밍 복습 프로그래밍 데이터 = State 데이터 → 데이터 → …(반복) 데이터(State)를 관리하는 것 함수형 프로그래밍 상태의 변화를 바라보는 즉 변화시키는 함수를 분리 상태를 변화시키는 것 = 액션 상태를 변화시키지 않은 것 = 계산(계층을 나눔 - ) 비즈니스, 스키마는 해당 도메인과 연관됨 즉, 좋은 유틸을 많이 만들어서 수정을 최소화 시켜서 개발을 진행해야 합니다. 스키마 : 데이터 구조 ex) 비즈니스 : 요구사항 ex) 가격 15,000원 이하 상품을 찾아주세요. ex) 좋은 유틸 - 등 JS가 함수형프로그래밍을 지원하는 것 중 하나는 (인자로 함수를 넣을 수 있고, 리턴을 함수로 할 수 있는 것) DRY → 함수형프로그래밍에서 반복적인 코드를 어떻게 제거하는지 기법을 알아보자 일급 함수(JS가 지원) 입력값과, 반환값이 모두 들어올 수 있다는 것이 입니다.(즉, 함수도 포함) 불변성(JS는 지원해주지 않음) 결국 문을 쓰지 않고, 계산 함수…

글또 시작 다양한 사람들과 글쓰기 습관을 만드는 과정을 경험할 수 있다는 커뮤니티가 있어 지원하게 되었다. 평소에 글을 쓰지만, 내가 과연 잘 읽히는 글을 쓰고 있는지 또는 다른 사람들은 어떤 생각을 가지고 글을 쓰는지 궁금했다. 더 나아가 개발자라는 직군 속에서 어떤 일을 하며 하루하루 살아가는 지도 궁금했다. 다양한 사람들과 다양한 이야기를 하는게, 기대가 되고 내가 가지고 있는 고민들에 대해 다들 어떻게 이야기 해줄지도 궁금하다. 목표 불필요한 시간을 줄이고, 글쓰는 습관을 가지기 글을 쓰면서 스스로 생각하는 힘을 키우기 내가 누구인지, 내가 무엇을 원하는지를 파악해 나만의 브랜딩 만들기 글또가 끝난 6개월 후에 어떤 모습이길 바라나요? 글쓰는데 어려움이 없었으면 좋겠어요 글을 쓰면서 사고하는 힘이 증가됬으면 좋겠어요 나만의 브랜딩을 만들고 싶어요 그 모습을 달성하기 위해 무엇을 해야 할까요? 일단 글을 쓰는 연습을 해야 할 것 같아요 규칙적으로 시간을 정해서 그 시간에는 무…

⭐️ 복습 액션 사이드 이펙트를 발생시킴 를 변경시키는 것 전역변수라고 라고 할 수 없음. 그래서 상황에 따라 확인해야 함 ex) 객체가 외부 데이터라고 생각할 수 있을까??? 계산(순수함수) 명시적인 입, 출력이 존재 테스트 용이하며, 예측이 가능한 코드 개발 피로를 낮춤 데이터 상수 입력과 출력이 될 수 있는 것 액션으로 확장가능 ✏️ 배운 내용 1.일급 개념 JS에서 가장 중요한 개념 JS는 OOP가 가능하지만, JS는 OOP가 아님 추상화 어디서든 사용활 수 있도록 하는 과정 OOP 역사 이분법적인 철학적 사고 ex) 외국인들은 라는 단어를 그냥 사용하지 않고 chaire에 무언가를 붙여서 사용(a chair, chairs) 즉, 하나의 추상화를 가지고 사용 용도에 따라 무언가를 추가해 사용 다시 말하면, 하나의 추상화 개념에서 (분류) 할 수 있는 개념들이 탄생 JS 정적 vs 동적 JS의 큰 장점 중 하나는 이라는 것 왜 JS는 ??? 먼저 결론부터 말하자면, 페이지/…

👀 내용 함수형 프로그래밍에서 가져갈 수 있는 것 을 제공 → 클린한 코드를 작성할 수 있습니다. 함수형 프로그래밍의 대체제 = OOP → 관련된 데이터를 엮는 것 함수형 프로그래밍에서는 데이터를 재가공해서 보겠다는 의미 액션 → 계산(명시적 입출력) → 액션(외부 상황에 영향을 주는 것) 액션을 최소화 하고, 계산을 많이 만듭니다. 사용자가 할 수 있는 행동 = 요구사항 유사한 계층을 정리 정돈 = PIPE → 이름을 명시 다양한 요구사항에 유연적으로 대응할 수 있는지 확인 결국 사용사의 요구 사항에 맞게 데이터를 계산해서 계산된 데이터를 화면에 업데이트 하는 과정 ✏️ 실습 하나의 프로젝에서 액션 - 계산 - 데이터를 나누는 실습을 진행 계산을 로 나누는 실습을 진행 또한 이러한 계산을 하나의 Hook안에 작성한다고 생각할 수 있음 참고 함수형 프로그래밍 스터디 참고

👋 복습 함수형 사고에서 말하는 의 3가지 영역으로 나눠서 만들어진 함수들간의 계층을 시각화 함 더 나은 구조에 대해서 생각하고, 요구사항의 추가나 변화가 발생했을 때, 꼭 필요한 만큼의 가 발생하는지 혹은 더 복잡한 사항이 발생하는지 팀끼리 실습을 함 🙋‍ FE의 요구 사항이란? 사용자가 특정 을 하면 관련된 를 찾아서, 특정 기존 하고, 그 결과를 다시 화면에 보여주는 큰 틀을 가짐 👀 계층과 흐름에 관한 보충 설명 계층 보단, 을 먼저 생각해보자. 위 요구 사항을 보면, 를 잡고, 함수 전 후 데이터들의 Input & Output을 생각해보자. 은 명시적 입출력이 있는 함수라면, 은 암묵적 입출력이 있는 함수. 이렇게 여러개의 큰 흐름을 그리다 보면, 같은 계층의 함수 그룹을 발견 할 수 있음. 계층에 대한 개념이 확립되고 나면 새로운 요구사항들을 구현할 때, 요구사항에 맞게 계층에 맞는 함수들을 조립하는 형식으로 발전 가능 참고 함수형 프로그래밍 스터디 참고

👋 복습 액션 → 계산 → 데이터 이벤트 핸들러 : 액션 계산을 꺼내기 리턴 값 정하기 리턴 값과 관련된 코드조각 모으기 사용되는 모든 값을 함수인자로 만들기 —> 명시적 출력 + 명시적 입력 외부 세계에 영향을 주거나, 실행할 때마다 달라지는 값이 있다면 제거(Array, Object) 유틸리티, 비즈니스 로직, 스키마, 구분해보기 유틸리티와 비즈니스 로직 차이는?????? 유틸리티 Lodash 유틸리티가 아닌 로직들 = 비즈니스 로직 ✅ 2주차 배운 내용 정리 액션으로 부터 을 빼낼 수 있는지에 대해서 배우고 실습 진행 액션에서 계산을 빼내는 작업은 암묵적 입력과 출력을 -> 명시적 입력과 출력으로 바꾸는 것 암묵적 입력 : 함수인자가 아닌 형태로 사용되는 데이터 및 함수 안에서 선언한 데이터 등을 의미 암묵적 출력 : 함수의 반환값이 아닌 출력 ex) DOM, console.log, 전역변수 수정 등을 의미 암묵적 입력과 출력을 명시적 입력과 출력으로 바꾸는 방법 함수에 반…

✅ 1주차 배운 내용 테스터 입장에서 가 왜 문제인지, 어떻게 하면 이 코드를 더 좋은 코드로 만들 수 있을지 고민하는 시간 갖음. 관점으로 사고하는 방법 함수형 프로그래밍 기술보다는 에 초점을 맞추는 관점 의 데이터를 만드는 사고 방식 계산 입력값과 반환값이 존재 언제나 같은 입력에 대해서는 같은 결과를 반환 테스트 용이하다는 특징을 갖음 액션 호출 시점에 따라서 행동이 달라짐.(시점과 횟수가 중요) 시점과 횟수마다 액션이 달라지기 때문에, 테스트 코드를 짜기 힘듬. 액션 안에서 계산으로 뽑을 있는 코드를 분리하고 액션 -> 계산 -> 계산 -> 계산 -> 액션 -> 데이터 같은 계층 구조를 만들어 내는 것이 함수형 프로그래밍이고 즉, 함수형 사고 우리가 직접 계산을 통해, 데이터를 조작하는지 혹은 간접으로 계산을 통해 데이터를 조작하는지에 따라 관점이 다름. 함수의 목표가 무엇인지, 함수 안에서 어떠한 역할이 필요한지 파악한 뒤에 코드 작성하는 의식적 노력 필요. 참고 함…

✅ Facts(사실, 객관) 강의 영상이 길어 과제를 진행하지 못했다.(금요일에 강의를 다 보았다.) 🙋‍♂️ Feelings(느낌, 주관) 강의를 다 듣고 과제를 진행하는 게 아니라, 강의를 본 내용까지라도 과제를 진행했어야 했는데 그렇게 하지 못해 아쉽다. 😋 Findings(발견, 배운점) 앞으로는 학습을 하면 바로 실행(과제 진행 등)하도록 해야겠다. 👨‍💻 Affirmation(자기 선언) 효율적인 학습방법을 찾아보고 실천해 보자. 시간, 체력관리를 잘 하자. 📕 참고 ✅ Facts(사실, 객관) 🙋‍♂️ Feelings(느낌, 주관) 😋 Findings(발견, 배운점) 👨‍💻 Affirmation(자기 선언) 📕 참고

✅ Facts(사실, 객관) 라우팅 기능 구현과 더불어 라우팅 관련 테스트 코드를 처음 접하게 되었다. 🙋‍♂️ Feelings(느낌, 주관) 라우팅 관련 에러와 과제를 하면서 발생한 에러를 해결할 때마다 스스로 학습하고 있다는 느낌을 강하게 받고 있다. 😋 Findings(발견, 배운점) 최근에 함수를 통해 React Component 내의 오브젝트의 값들을 랜더링 하는 과정에서 에러를 접했는데, React는 Component를 랜더링할 때, 화면에 표시할 데이터 타입과 실제로 주입하는 데이터 타입이 같아야 한다는 사실을 알게 되었다. React Component 랜더링에 대해 알게된 계기였던 것 같다. ✅ Facts(사실, 객관) 테스트 내부에서 사용하는 함수를 외부로 빼지 않고, 해당 테스트 내부에서 선언하고 사용하면 어디서 사용하는지에 대한 의도를 알 수 있다는 피드백을 받았습니다. 🙋‍♂️ Feelings(느낌, 주관) 코드의 의도를 생각하면서 코딩을 하지 않았다는 사실을 알게 되었…

✅ Facts(사실, 객관) 저번 주와 이번 주 코드숨 과제를 완료하지 못 했다. 🙋‍♂️ Feelings(느낌, 주관) 개인적으로 이번 달에 몸이 많이 피곤한 것 같다. 회복할려고 해도 잘 되지 않는다. 그래서 해야 할 것들에 대해 집중을 잘 하지 못 하는 것 같다. 😋 Findings(발견, 배운점) 이번 달은 먹는 음식, 수면시간, 운동시간 등을 통해 컨디션 조절을 잘 해서 과제를 완료할 수 있도록 노력해야 겠다. 👨‍💻 Affirmation(자기 선언) 몸 관리를 잘하자 시간 관리를 잘하자 📕 참고 ✅ Facts(사실, 객관) 🙋‍♂️ Feelings(느낌, 주관) 😋 Findings(발견, 배운점) 👨‍💻 Affirmation(자기 선언) 📕 참고

✅ Facts(사실, 객관) 1. Redux Flux Architecture의 개념 Redux 상태관리하는 이유와 장점 Recat 프로젝트에서 Redux 사용 방법 2. 추가 공부 JS 기본기가 많이 부족한 것 같아, 엘리님의 JS 기본 개념 강의를 수강하기 시작했다. 🙋‍♂️ Feelings(느낌, 주관) 이번 주는 개인적으로 몸 컨디션이 좋지 않았다. 또한 업무적으로 새로운 기능 배포 때문에 야근도 많았다. 그럼에도 코드숨 과제를 할려고 노력은 했으나, 조급한 마음때문에 과제의 의도를 잘 파악하지 못하고 답을 내기 급급했다. 또한 TDD에대한 학습 시간이 부족해 다른 수강생들이 작성한 코드를 많이 참고했지만, 과제를 진행하는데 많은 어려움이 있었다. 그래도 매일 퇴근 후, 짬을 내서 과제를 진행했다. 남들보다 많이 부족하지만 이번 과제 풀이 영상을 보면서 조금은 라는 감각이 생긴 것 같아 뿌듯하다. TDD를 하는 과정에서 사고력이 늘어나는 느낌이 든다. 😋 Findings(배운점) …

✅ Facts(사실, 객관) 1. Jest Jest 개념 및 사용 방법 학습 2. TDD TDD 개념과 TDD를 해야 하는 이유 학습 과제를 통해 React로 TDD 하는 방법 숙지 3. 추가 공부 JS 기본기가 많이 부족한 것 같아, 엘리님의 JS 기본 개념 강의를 수강하기 시작했다. TDD 익숙하지 않아, 엘리님의 React TDD 강의를 수강하기 시작하였다. 🙋‍♂️ Feelings(느낌, 주관) 테스트 코드가 익숙하지 않아, 코드숨 참여하는 사람들의 코드와 리뷰어님이 피드백 주신 내용과 관련 자료들을 찾아보았다. 커밋을 할 때, 의미있는 커밋 내용과 작은 단위의 코드 진행 사항을 작성하지 못 했다. 😋 Findings(배운점) , , 을 통해 테스트 코드의 범주화를 할 수 있다. 을 통해, 테스트 맥락을 구분할 수 있다. 다음 테스트 구문에는 3인칭 복수인 를 붙여야 한다. 컴포넌트 테스트를 명시할 때, 굳이 component를 붙일 필요가 없다. 엘리먼트 랜더링 테스트 구…

✅ Facts(사실, 객관) 1. React React 개념 학습 React DOM 개념 학습 2. Components & Props Components & Props 개념 학습 3. React Hook React Hook 개념 학습 useState 개념 학습 4. 선언형 프로그래밍 선언형 프로그래밍 개념 5. 관심사의 분리 관심사의 분리 개념 학습 🙋‍♂️ Feelings(느낌, 주관) 이번 주는 야근 때문에 몸도 마음도 지쳐있는 상태였다. 그래도 과제를 조금이라도 해서 PR 피드백을 받고자 노력을 했다. 그러나 많이 지쳐있던 탓이었을까, 빨리 과제를 마무리 하고 싶은 마음에 PR 대해 깊게 생각하지 않고, 과제의 정답에 집중을 했다. 다행히 코드 리뷰 해주시는 분께서 정확한 피드백을 해주셔서, 정답이 아닌 에 초점을 둬야 한다는 사실을 깨닫고 차분히 에 깊게 생각하는 시간을 가지게 되었다. 돌이켜보니 사실 일을 할 때에도, 보다는 에 집중을 하며 일하고 있었다. 앞으로 아무리 몸과…

✅ Facts(사실, 객관) 1. 개발 환경 구축 Node.js 개념 학습 및 설치 NPM 개념 학습 및 프로젝트 만들기 Webpack Dev Server 개념학습 및 설치, 실행 방법 학습 ESLint 개념학습 및 설치, 설정 방법 학습 2. 웹 개발 DOM 개념 및 조작 방법 학습 JS 문법 학습(forEach, map, filter, Rest parameters, Spread syntax) 3. JSX Babel 개념 및 설치, 설정 방법 학습 Webpack config 설정 방법 학습 JSX 개념 학습 JS 문법 학습(구조분해 할당, Object관련 함수, 연산자 활용법) 🙋‍♂️ Feelings(느낌, 주관) 개념 학습하면서 당연하게 알고 있던 것이 아님을 알게 되는 시간이었다. 특히 과제를 진행하면서 얼마나 부족한지 강하게 깨닫게 되었다. 사실 코드숨을 신청한 계기도 생각에서 신청을 했는데, 정말 잘 신청한 것 같다.👍 특히,코드리뷰를 받으면서 내가 놓치고 있는 부분을 알게…

😁 오랜만에 느끼는 즐거움 오늘은 코드숨 OT에 참여하게 되었다. 사실 이때 몸 컨디션이 너무 좋지 않았다. 그래도 다양한 사람들과 만나 새로운 경험을 하고 싶어 몸을 일으켜 컴퓨터 앞에 앉았다. 처음에는 많이 어색하고 낯설었지만, 점점 사람들과 이야기하며 다양한 주제로 각자의 의견을 듣고 말하는 시간을 갖게 되니 컨디션이 좋아졌다. OT 하면서 되게 인상 깊었던 점은, 내가 가지고 있었던 생각을 누군가가 이미 해결하기 위해 일하고 있다는 사실이었다.(홀로 스탠딩) 너무 신기했고 정말 대단한 개발자들이 이렇게나 많구나라고 다시 한번 느끼게 되었다. 마지막으로 OT를 주관해 주신 분께서 말씀해 주셨다. 정말 12주 동안 설레기도 하고 걱정되기도 하지만, 최선을 다해 즐겁게 학습하고 싶다. 😄 참고 참고