1월 원티드 챌린지에서 프론트 엔드에서도 테스트 코드가 필요하다는 것을 알게 되었다.프론트 엔드에서 테스트 코드를 활용한 경험을 담은 기술블로그의 글을 읽다 보면 공통적으로 말하는 장점이 있다.1. 오류를 빠르게 발견하고 수정할 수 있다.2. 다른 라이브러리/프레임워크로 쉽게 리펙터링이 가능하다.3. 로직의 흐름을 파악하기 쉬우므로 문서화 역할을 하며 새로운 팀원이 해석하기 쉽다. 여기에 추가적으로 TDD 방법론을 적용하였을 때 개발 시간이 줄어든다는 실제 사례를 에서 본 기억이 있다.복잡한 비즈니스 로직이 포함된 코드가 아닌 간단한 사칙연산 수준의 코드를 구현함에 있어서도 위처럼 유의미하게 차이가 발생했다. 챌린지에서 배웠던 내용을 한마디로 요약하자면 "UI 테스트는 하지 않고, 요구사항의 사용자 시나..

[Week 2-1] 백엔드 코드를 수정할 수 없을 때 프론트엔드가 할 수 있는 최적화 방법 3-1) 성능 측정 툴 소개 및 사용법 웹 애플리케이션의 성능을 측정하고 분석하는 데 사용할 수 있는 툴에 대해 알아보았다. 애플리케이션의 로딩 속도, 실행 시간, UX 등 다양한 측면에서 성능을 평가하고, 이를 통해 성능 저하의 원인을 찾아 개선할 수 있도록 도와준다. Lighthouse Lighthouse - 웹 성능을 분석하는 오픈 소스 - 주요 기능 1) 성능 분석 2) 접근성 검사 3) SEO 평가 4) PWA 기준 평가 https://chromewebstore.google.com/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=ko Lighthouse Li..

[Week 1-2] 테스트코드를 활용한 효율적인 리팩토링 2-1) 무엇을 테스트할 것인가? 오늘 챌린지에선 리펙터링시 테스트 코드를 활용할 것을 소개하고 있다. 개념으로만 테스트 주도 개발(TDD)이 중요하다고만 알고 있었는데 특히 프론트 엔드에서 무엇을 고려하여 진행해야 하는지 알 수 있었다. UI 테스트는 진행하지 않는다. 테스트를 계획할 때 무엇을 테스트 할 것인지 명확하게 파악을 해야 하는데 UI 테스트는 중요하지 않다. 컴포넌트 렌더링 순서를 확인하거나, 태그와 요소들의 간격 등은 굳이 테스트할 필요가 없다. 요구사항의 "사용자 시나리오"에 집중해야 한다. UI, Style 부분보다 "기능"에 더 중점을 두고 테스트를 해야한다. 회원가입 form에서 input이 제대로 되는지, 혹은 필수 항목들..

[Week 1-1] 전역변수를 설정하는 기준과 방법 -챌린지 강병진 멘토님- https://github.com/jasonkang14 jasonkang14 - Overview I believe software engineers can change the world. jasonkang14 has 47 repositories available. Follow their code on GitHub. github.com 1-1) 지역변수와 전역변수 비교 - 지역 변수 (Local Variable) 함수 내부에서 선언된 변수 지역 변수는 해당 함수 내부에서만 접근할 수 있으며, 함수가 종료되면 메모리에서 사라진다. 다른 함수에서는 같은 이름의 지역 변수를 사용해도 각각 독립된 메모리 공간을 가지므로, 서로 영향을 미..

5. 5부 아키텍처 좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다. - 클린 아키텍처(209p) 프레임워크 독립성 테스트 용이성 UI 독립성 데이터베이스 독립성 모든 외부 에이전시에 대한 독립성 - 클린 아키텍처(214p) 소프트웨어를 계층으로 분리하여 관심사의 분리를 목표로 한다. 이를 통해 외부 요소 없이 테스트가 가능하고 기존에 사용하던 DB를 바꾸어도 문제가 발생하지 않는다. https://medium.com/humanscape-tech/clean-architecture-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%99%80-%EB%8F%85%EB%A6%B..

클린 아키텍처 소프트웨어 아키텍처의 보편 원칙을 적용하면 소프트웨어 수명 전반에서 개발자 생산성을 획기적으로 끌어올릴 수 있다. 《클린 코드》와 《클린 코더》의 저자이자 전설적인 소프트웨어 장인 www.aladin.co.kr 소프트웨어 아키텍처의 보편 원칙을 적용하면 소프트웨어 수명 전반에서 개발자 생산성을 획기적으로 끌어올릴 수 있다. 《클린 코드》와 《클린 코더》의 저자이자 전설적인 소프트웨어 장인인 로버트 C. 마틴은 이 책 《클린 아키텍처》에서 이러한 보편 원칙들을 설명하고 여러분이 실무에 적용할 수 있도록 도와준다. 단순히 선택지들을 나열하는 책이 아니다. 상상할 수 있는 모든 분야의 소프트웨어 환경에서 반 세기를 살아온 저자의 경험에 기초하여, 성공하기 위해서는 어떤 선택을 해야 하고 무엇이 ..

선택 과제) 본인이 작성했던 코드 중에서 SOLID 원칙과 IoC를 적용할만한 부분을 찾아보고 개선한 뒤 느낀 점 블로그에 정리하기 지난 과제에서 비즈니스 로직을 분리하면서 어떠한 ‘답답함’을 느끼셨을 수 있다고 말씀드렸습니다. 이번 강의에서 학습한 SOLID와 IoC의 개념을 가지고 코드를 개선해 보세요. SOLID 원칙과 CCP 적용을 위해 전에 만들었던 작은 프로젝트를 리펙터링했다. 비교적 상하위 컴포넌트 구분이 쉬워 적절해 보였다. https://github.com/yeonhub/PP-doosan_bears GitHub - yeonhub/PP-doosan_bears: [개인 프로젝트] 두산 베어스 선수 정보 [개인 프로젝트] 두산 베어스 선수 정보. Contribute to yeonhub/PP-d..

[Week 2-2] Logic First, React Later 4-1) ‘React 다운 코드’ 다시 생각하기 이번 챌린지에서 배운 내용들을 생각해 보자. [1차] - 데이터 / 액션 / 계산 구분 및 분리 [2차] - 비즈니스 로직 / UI 로직 구분 및 분리 [3차] - SOLID 원칙과 React 컴포넌트 패턴 공통적으로 챌린지의 주제처럼 비즈니스 로직을 이해하고 추상화 원칙에 따라 좋은 컴포넌트 작성을 통해 개발 생산성을 높이려고 노력을 해왔다. React는 렌더러입니다. 화면을 그리는 역할에 집중하도록 하는 것이 좋습니다. 이제 다시 원점으로 돌아와 React에 대해 다시 한번 고민해 보면 무엇을 잘하고 어떤 일을 맡겼을 때 원하는 대로 결과물을 만들 수 있는지 알고 있어야 한다. 그래서 DE..

[Week 2-1] SOLID한 컴포넌트 만들기 3-1) 내 손에 익은 공구상자 일을 하거나 취미 활동을 할 때 직접 사용해 보면서 익숙하게 사용하는 것들이 있다. 유일한 도구라 사용하는 것 일수도 있고, 쓰다 보니 만족하여 계속 사용하는 것 일수도 있다. 여기서 중요한 점은 내 공구상자가 남들보다 크고 비싼 공구들이 잔뜩 들어있다고 무조건 좋은 것은 아니다. 달랑 볼펜 하나로 훌륭한 그림을 그릴 수 있듯이 그 도구를 얼마나 이해하고 잘 활용할 수 있는지에 달려있다. 개발자도 마찬가지이다 라이브러리/프레임워크 수십개를 안다는 것과 제대로 사용할 줄 안다는 것은 큰 차이이기 때문 이러한 이유로 오늘 챌린지에선 Context API와 Class를 예시로 들었다. https://ko.legacy.reactjs..