담백한 웹 개발 이야기

TDD와 BDD의 정의 TDD(Test-Driven Development) TDD(Test-Driven Development)는 테스트 주도 개발이라고 하며, 함수나 기능에 대한 테스트 케이스를 최우선 먼저 작성하고, 그 테스트를 통과하기 위한 최소한의 코드를 작성하는 개발 방법론입니다. BDD(Behavior-Driven Development) BDD(Behavior-Driven Development)는 행동 주도 개발이라고 하며, 사용자 관점에서 애플리케이션의 행동에 초점을 맞춰 테스트 케이스를 작성하는 개발 방법론입니다. TDD와 BDD의 차이점 3가지 1 테스트 케이스 작성 TDD는 테스트 코드 작성자 관점에서 테스트 케이스를 작성하고, 기능에 초점을 맞춥니다. 반면에 BDD는 사용자 관점에서 테..

우선 테스트가 필요한 이유는 결함이 해결되지 않은 상태에서 서비스가 Production 단계로 배포된다면 장애가 발생하여 사용자들이 손실을 입고 나아가 회사 전체 비즈니스에 영향을 줄 수 있기 때문이다. 테스트가 필요한 부분 테스트의 경제성을 설명하는 격언 중 "테스트를 적게 하는 것은 죄지만 그렇다고 무조건 테스트를 많이 하는 것이 반드시 미덕은 아니다"라는 말이 있다. 테스트를 수행할 자원은 유한하므로 완벽한 테스트는 현실적으로 불가능하다. 그렇다면 위험이 높은 기능 및 비기능 요구사항을 집중적으로 테스트해야 한다. 테스트 케이스에 작성해야 하는 것 가장 중요한 것 실패 가능성이 있는 것 위험 요소가 있는 것 결함 발생 시 파급효과가 심각하고 이로 인한 막대한 손실이 발생하는 기능 위험 요소 장애 발..

테스트 종류 한장에 정리! 유닛 테스트 유닛 테스트는 코드의 특정 모듈이 의도된 대로 정확히 동작하는지 검증하는 방법입니다. 모든 함수와 메서드에 대한 테스트 케이스를 작성하게 됩니다. 이상적으로 각 테스트 케이스는 서로 분리되어야 하며, 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 빠른 시간 내에 문제를 파악하고 해결할 수 있도록 도와줍니다. 이를 위해서 Mock Object를 생성하는 것도 좋은 방법입니다. 유닛 테스트는 개발자뿐만 아니라 테스터에 의해서 수행되기도 하고, 테스터가 유닛 테스트를 작성하면 개발자가 맞춰서 개발하는 사례도 있습니다. 정적 테스트 정적 테스트는 소프트웨어 실행 없이 소프트웨어를 분석하는 것을 의미합니다. eslint, prettier, 오픈 소스 라이센스..

TDD와 BDD 비교 TDD (Test Driven Development) TDD는 개발 방법론 중 하나로 우선 실패하는 테스트 코드 작성 후 개발 코드 작성하고, 테스트를 실행해서 통과 후 리팩터링을 진행하는 과정을 반복한다. 이러한 작업들을 반복해 본질적으로 필요한 코드만 작성하고 코드의 신뢰성을 높이는 데 포커스된 개발 방법론이다. BDD (Behavior Driven Development) 우선 TDD의 단점은 코드 관점으로 테스트를 작성하여 코드 수정 시 불필요한 테스트 코드 수정사항이 발생하는 것이다. 이러한 상황을 해결하기 위해 BDD 방법론이 나왔는 데, BDD에서는 사용자 시나리오 관점으로 suite를 작성한다. 사용자 관점에서 기능 단위로 작성하며 개발 코드 변경시 테스트 코드가 변경되..

배열과 반복문 인덱스 반복문 for (let i = 0; i `Day ${i}`) const range = length => ..

조건문 동일한 값을 비교할 경우 if/else로 작성되면 에러코드에 따른 동작을 파악하기 위해 시선이 Z형태(errorCode -> 211 -> navigate)로 이동되어 한번에 읽기 어렵게 한다. if (errorCode === 211) { navigate('/signup') } else if (errorCode === 208) { navigate('/user/registration') } else if (errorCode === 202) { navigate('/home') } else if (errorCode === 212 || errorCode === 213) { navigate('/signup') } else { navigate('/login') } switch/case로 작성되면 에러코드와 동..

객체 객체 추출하여 다른 객체 만들기 객체에서 특정한 프로퍼티만 추출하여 다른 객체를 만들고 싶을 때가 있다. 새로운 객체를 만들어 객체의 값을 할당하는 형태이다. 이 코드는 이해하기 어렵지 않지만 chatBot 변수사용의 중복이 발생한다. const httpBody = { name: chatBot.name, fallbacks: chatBot.fallbacks, config: chatBot.config, tags: chatBot.tags, } 해체를 통해 프로퍼티을 추출하고 할당하는 방식을 사용하면 중복을 줄일 수 있다. const {name, fallbacks, config, tags} = chatBot const httpBody = {name, fallbacks, config, tags} 만약에 프로..

스타일과 문구 스타일과 문구는 정책적인 사항이라고 볼 수 있다. 스타일은 디자인 정책, 문구는 용어 정책이다. 스타일은 색상, 요소의 위치, 라운딩값 등 시각적인 요소를 의미한다. 스타일은 디자이너의 의견이 반영된 디자인 정책이다. 문구는 타이틀, 가이드 문구, 툴팁 문구, 일시적인 오류에 따른 문구 등 문구에 관련된 요소들을 의미한다. 문구는 기획자 또는 테크니컬 라이터의 의견이 반영된 용어 정책이다. 차트 라이브러리 옵션 차트 라이브러리에 사용되는 옵션값도 디자인 정책에 해당된다. 이러한 정책 사항들은 로직이 있는 코드와 같이 기술되면 불필요하게 해석하게 된다. const chartOption = { label: { xAxis: {x: 10, y: 10, color: '#000'}, yAxis: {x..

글의 목적 프로젝트 코드에 레거시 코드가 존재하는 데 모든 레거시 코드를 이해하기 쉬운 코드로 작성이 불가능한가의 생각으로 각 코드별로 방법에 대한 정리를 시작했다. 프로젝트 코드 하나하나 확인한 뒤 이해하기 힘든 부분을 찾아 이해하기 쉬운 코드로 바꾸는 방법을 작성해봤다. 다른 사람이 작성한 코드를 보고 개선하는 것만큼 현실세계에 발생할 만한 사항이다. 용어정의 테크니컬 라이터 소프트웨어의 전문적인 지식을 비전문가에게 이해하기 쉽게 전달하는 매체(음성, 영상, 글)을 생산하는 역할이다. 책임연쇄패턴 문제를 처리에 적합한 요소를 연쇄적으로 찾아 책임을 부여하는 패턴이다. 카테고리 스타일과 문구 객체 조건문 배열과 반복문 레거시 코드 리팩터링 시리즈(1/5) 글의 목적 프로젝트 코드에 레거시 코드가 존재하..

마틴 파울러의 리팩토링 책 일부를 정리한 포스트입니다. 리팩터링 리팩터링은 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업이다. 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만들어 겉으로 드러나는 기능에 거의 또는 아예 영향을 주지 않으면서 소프트웨어의 각종 기능을 추가할 수 있다. 리팩터링 수행 후에 겉으로 드러나는 기능에 영향을 주지 않기 때문에 사용자는 소프트웨어의 변화를 눈치채지 못한다. 리팩터링과 성능 최적화리팩터링은 성능 최적화와 상반되는 데, 같은 점은 수행 후에 기능이 변경되지 않는 것이다. 다른 점은 성능 최적화는 성능 향상을 위해 불가피하게 필요한 성능을 내기 위해 코드를 파악하기 더 어려워질 때가 많다. 리팩터링과 기능추가리팩터링..

글의 목적 한번쯤은 다른 누군가에게 전해받은 레거시 코드를 받아 프로젝트를 진행해야 되는 경험이 있었을 것이다. 나는 2018년 10월부터 i.kakao.com으로 서비스 되고 있는 카카오 i 오픈빌더를 이어 받았다. 프로젝트는 초기 빌딩 시 프런트 전문가들이 투입되지 않아 개선점이 많이 필요했다. 현재는 프런트 인력이 추가되어 리팩토링이 진행될 예정인데, 그 과정에 앞서 지금까지 진행했던 내용을 공유할 필요성이 있어 정리한 자료이다. 목차 2018.10~11 오픈빌더 투입 2018.12 코드 리팩토링 시작 2019.01 오픈빌더 기술적부채상환 전략 2019.02 설정 페이지 리팩토링 2019.05 응답형식 구조 리팩토링 2018.10~11 오픈빌더 투입 초기에 오픈빌더는 서버 개발자로 구성된 조직에서 ..

글의 목적 함수나 클래스 레벨의 코드를 수정하는 것은 굉장히 빈번하게 발생하고 익숙한 작업이다. 하지만 구조 레벨을 수정하는 것은 빈번하지 않고 큰 비용이 발생하는 작업이다. 구조 리펙토링은 상태와 로직을 수정하지 않고 컴포넌트, 파일, 폴더를 역할과 책임 그리고 이해하기 쉬운 형태로 재정렬하는 것이다. 이 포스트에서는 컴포넌트 구조 리펙토링을 다룬다. 이해하기 쉬운 코드와 소프트웨어 철학을 학습했는 데도 불구하고 시간적인 여유가 없어 구조적인 리펙토링을 진행못할 때가 많다. 개인적으로 싫어하는 탁상공론을 벗어나 구조레벨의 리펙토링을 진행하였고, 관련해서 기본적인 방법들을 정리하고자 작성한 포스트이다. 표기정의 ngFor Angular에서 사용하는 리스트 렌더링 문법이다. vue에서는 v-for를 사용한..