본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 단위테스트 입력만 다르고 동작이 같은 반복 코드를 작성하면 가독성이 떨어짐 for문을 사용하여 반복을 제거하면 여러 문제가 발생할 수 있음 정확히 어떤 케이스에서 문제가 발생한 지 알기 어려움 하나의 테스트 케이스에서 문제가 발생하면 다음 테스트가 수행되지 않을 수 있음 결국 가독성은 높였지만, 정작 테스트의 신뢰성을 잃게 됨 paramiterized test를 사용하여 신뢰성을 보장하면서 반복되는 코드의 양을 줄일 수 있음 Junit, Jest 등의 테스트 라이브러리에서 이를 지원함 (실제로 이렇게 반복 작성한 테스트 코드가 있었는..
본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 코드를 왜 분해하는가? 시스템의 크기는 시간이 지남에 따라 점점 커짐 큰 문제는 작은 문제로 분할가능 작은 문제의 일부는 반복됨 코드 상에서, 또는 공개됐거나 벤더들이 제공하는 API 코드 가독성의 중요성 코드를 읽는 비용은 생각보다 큼 한 번 쓰여진 코드는 계속해서 읽히게 됨 따라서 코드 가독성은 생산성에 큰 영향을 미치게 됨 코드 재사용의 중요성 반복되는 문제의 풀이는 재사용 가능 가장 우선적인 고려대상은 코드를 수정하지 않고 그대로 쓰는 것 그 뒤엔 코드를 수정하거나 라이브러리를 사용하는 방법이 있다 결론적으로 이는 소프트웨어 ..
본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 수동 테스트 품질 담당자가 UI를 사용해 기능을 검증 최종 사용자의 사용 경험과 가장 비슷하게 검증 실행 비용이 높고 결과의 변동이 큼 추가한 기능을 테스트하는 비용 + 기존 기능이 원래대로 동작하는지 테스트하는 비용(소프트웨어 회귀) 수동 테스트만으로는 이 비용을 감당하기 힘듦 가장 온전한 코드 실행 인수 테스트 소프트웨어 회귀 특정 시점 이후로 소프트웨어의 기능이 동작하지 않는 버그 ex) 새로운 기능이 추가된 이후로 원래 기능이 동작하지 않음 테스트 자동화 기능을 검증하는 코드를 작성 테스트 코드 작성 비용이 소비되지만 실행 비..
본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 도메인 소프트웨어는 문제를 푸는 도구 도메인은 소프트웨어가 풀어야할 문제가 정의되는 공간 비즈니스 시스템의 도메인은 비즈니스 문제를 충분이 이해하지 못하면 문제를 푸는 도구를 만들 수 없음 프로그래머와 기능 명세 프로그래머가 도메인 지식을 컴퓨터에 전달할 때엔 모든 요소들이 명확히 결정되어야 함 누락되거나 불명확한 부분이 없을 때까지 도메인 지식을 확보하지 못한 프로그래머는 지식 흐름의 상류에 지식 보강을 요청해야 함(분석가, 비즈니스 전문가) 하지만 어떤 프로그래머는 스스로 결정을 내림 도메인 지식 투영에 오차 발생 가능 지식이 ..
본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 과학은 어떤 현상을 규명하고 파악하는 데 중점을 두는 반면, 엔지니어링은 현실의 문제를 해결하는 데 집중한다 현장은 무균실이 아니라 야전이다 프로그래밍은 협업이다 서로의 기준에 맞는 코드를 작성하는 것보다는 어떤 목표를 공유하고 있는지가 더 중요하다 목표를 달성하는 것, 즉 현실의 문제를 해결하는 것이 더 중요하다 시스템은 연결된다 도구 상자에 다양한 도구를 채우자 TDD도 하나의 도구다 엔지니어링은 거래(trade-off)다 더 심각한 문제와 덜 심각한 문제를 바꾸는 것이다
