테스트는 [ 문서 ]다.테스트 코드를 단순히 프로덕션 코드를 검증하는 도구라고만 생각하면, 그 가치의 절반밖에 보지 못하는 것이다. 나는 테스트 코드가 곧 '살아있는 문서'라고 생각한다.테스트가 왜 문서가 될까?생각해보자. 우리는 항상 팀으로 일한다. 내가 짠 코드를 언젠가 다른 동료가 봐야 하고, 내가 과거에 했던 고민을 그 동료가 또 똑같이 할 필요는 없다.바로 이때 테스트 코드가 빛을 발한다.다양한 테스트 케이스는 프로덕션 코드의 기능과 정책을 설명하는 가장 정확한 설명서가 된다.과거에 누군가 했던 고민의 결과물을 팀의 자산으로 만들어준다.새로운 팀원이 들어왔을 때, 테스트 코드를 통해 시스템의 동작 방식을 빠르게 이해할 수 있다.결국 잘 짜인 테스트는 동료를 위한 가장 친절한 가이드가 된다.좋은 ..

TDD: 테스트가 개발을 이끈다?우리는 지금까지 테스트의 필요성과 단위 테스트 작성법에 대해 알아봤다. 이번에는 한 걸음 더 나아가, 아예 개발 프로세스 자체를 뒤집어보는 '테스트 주도 개발(TDD)'에 대해 이야기해보려 한다.TDD(Test Driven Development)란?TDD는 말 그대로 프로덕션 코드보다 테스트 코드를 먼저 작성해서, 테스트가 전체 구현 과정을 이끌어가는 개발 방법론이다."코드를 짜기도 전에 테스트를 어떻게 만들어?" 싶겠지만, TDD는 아주 구체적이고 체계적인 단계를 따른다.TDD의 심장: RED-GREEN-REFACTOR 사이클TDD는 아래 3단계를 끊임없이 반복하며 진행된다.실패하는 테스트부터 작성한다 (RED)우선 "이 기능은 이렇게 동작해야 해"라는 기대를 담아 테스..

단위 테스트 파헤치기지난 글에서는 테스트가 귀찮지만 왜 필요한지에 대해 알아봤다. 이번에는 '단위 테스트'에 대해 좀 더 깊게 들어가 보자.단위 테스트(Unit Test)란?말 그대로 작은 코드 단위를 독립적으로 검증하는 테스트다. 보통 클래스나 메서드 하나가 그 대상이 된다. 다른 테스트에 비해 검증 속도가 매우 빠르고 안정적이라는 장점이 있다.Java에서는 보통 JUnit5라는 테스트 프레임워크를 사용한다. 여기에 AssertJ라는 라이브러리를 곁들이면, 풍부한 API와 메서드 체이닝을 통해 테스트 코드를 훨씬 깔끔하고 읽기 쉽게 작성할 수 있다.// JUnit5의 @Test 어노테이션과 AssertJ의 assertThat을 사용한 예시class CafeKioskTest { @Test vo..

테스트는 귀찮다. 그럼에도 왜 해야 할까?솔직히 말해보자. 테스트는 귀찮다. 그럼에도 우리는 왜 테스트 코드를 작성해야만 할까?수동 테스트의 굴레Production Code가 있다고 해보자. 제품 출시를 위해 당연히 테스트가 필요하다.나, 또는 다른 개발자, 혹은 기획자나 QA 같은 동료가 직접 테스트를 시작한다. 웹사이트의 버튼을 하나하나 누르고, 앱에서 특정 기능을 실행해보고, 여러 값을 입력해본다. 예외적인 값도 넣어보며 꼼꼼히 검증한다.좋다. 이렇게 해서 첫 기능이 무사히 검증되었다. 곧이어 새로운 기능이 추가된다. 그럼 또 누군가가 처음부터 끝까지 테스트를 반복해야 한다.시간이 흘러 또 다른 기능이 추가되었는데, 이번엔 기존 프로덕션 코드의 일부가 변경되었다. 이제 문제는 더 복잡해진다. 새로 ..

클린 코드 #4 주석#클린코드잘 달린 주석은 정말 유용하지만, 잘못 달린 주석은 독이다.우리가 코드를 잘 짰다면 사실 주석은 거의 필요가 없다. 코드로 의도를 표현하지 못해서 주석을 사용하는 것이다.주석은 오래될 수록 코드에서 점점 멀어진다. 코드를 유지보수하면서 주석까지 유지 보수하기는 현실적으로 불가능하다. 점점 더 주석과 코드가 분리되버린다.주석을 엄격하게 관리해야 하지만, 코드를 깔끔하게 정리하는 대에 더 많은 신경을 쓰는게 좋다.코드만이 진실을 이야기한다.주석은 나쁜 코드를 보완하지 못한다.난장판을 주석으로 표현하지 말고, 난장판을 치우는데에 시간을 써라.코드로 의도를 표현하라.조금만 더 생각하면 코드로 대다수 의도를 표현할 수 있다. 주석으로 달려는 설명을 차라리 함수로 만들어서 표현해도 충분..

클린 코드 #3 함수#클린코드40줄이 넘는 FitNesse 함수 코드를 9줄로 리팩터링 했더니 이해하기 매우 쉬워졌다. 이해가 쉬운 이유가 무엇일까? 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 어떤 속성을 부여애햐 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까?작게 만들어라함수 코드 라인 20줄도 길다. 함수의 의도가 명백하게 드러나도록 최대한 작게 만들어라.블록과 들여쓰기if/else/while 문 등에 들어가는 블록은..

클린 코드 #2 의미 있는 이름#클린코드이름을 잘 붙이는 규칙에 대해 알아보자.의도를 분명히 밝히자좋은 이름을 지으는데 오래 걸리더라도, 좋은 이름으로 절약하는 시간이 훨씬 더 많다.이름을 지을 때는 다음과 같은 질문에 모두 답할 수 있어야 한다.변수/함수/클래스의 존재 이유는?수행 기능은?사용 방법은?만약 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.ex) 경과 시간, 경과 날짜int elapsedTimeInDays측정하려는 값과 단위를 표현하는 이름이 필요하다.코드 맥락이 들어나게끔 이름을 작성하자.함축적이고 명시적이지 않은 정보를 드러냄으로써 코드가 명확해질 수 있다.그릇된 정보를 피하자그릇된 단서를 코드에 남기면 안 된다.널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다...

클린 코드 #1 깨끗한 코드#클린코드나쁜 코드나쁜 코드가 쌓일 수록 팀의 생산성은 떨어진다. 결국 언젠간 재설계하게 된다.(생성형 AI가 던저준 코드를 그대로 복붙해서 프로젝트를 진행하면 이런 상황을 겪게 될 가능성이 높다)개발자는 나쁜 코드의 위험성을 인지하고 상사의 무지한 요구를 거절해야 한다.기한을 맞추기 위해 나쁜 코드를 양산한다고 변명하다면 이는 틀린 말이다. 나쁜 코드를 가지고 개발하면 기한을 맞출 수 없다. 가장 빠른 개발 방법은 코드를 최대한 깨끗하게 유지하는 것이다.깨끗한 코드깨끗한 코드를 작성하려면 깨끗한 코드가 뭔지 부터 알아야 한다.논리가 간단해야 한다.의존성은 최소화하고 각 의존성을 명확히 정의한다.오류를 명시적인 전략으로 철저히 처리한다.보기에도 즐거워야 한다.효율적이여야 한다...

Software Reuse를 왜 하나요?더 나은 SW를 빠르고 저렴하게 달성하기 위해서 하는 것.System부터 Application, component, Object and function 까지 모두 가능 Benefits of software reuse (외워야 하나..?)BenefitExplanationAccelerated development시스템을 가능한 한 빨리 시장에 출시하는 것이 전체 개발 비용보다 중요한 경우가 많습니다. 소프트웨어 재사용은 개발 및 검증 시간의 단축(both development and validation time may be reduced)으로 시스템 생산을 가속화할 수 있습니다.Effective use of specialists동일한 작업을 반복해서 수행하는 대신, 응..

지금까지 Dependability 중 Availability, Reliability를 다뤘으니 이제 Safety를 다룰 차례이다. Safety란?시스템이 비정상/정상이든 작동하면서 인간에게 상해나 사망을 초래하지 않고, 시스템 환경에 손상을 주지 않는 속성을 말한다availability와 Reliability를 만족한다고 해서 Safety 한게 아니다. 명세와 부합하는지는 관련이 없다. Unsafe 하다는 건 어떤건가요?시스템에서 오랫동안 감지되지 않다가 드물게 결함이 나탈수도 있고, 명세에 오류가 있을수도 있고, 하드웨어 고장일수도, Context-sensitive 명령일수도... 요런 것들이다 중요한 용어 암기하기safety-critical system : 시스템 작동이 항상 안전해야 하는 시스템Ac..