Book

역할, 책임, 협력 객체지향의 사실과 오해를 다 읽었다. OOP를 하는 개발자들에게 필수 도서라 하여, 다른 공부할 것들을 제쳐두고 이것만 먼저 읽었다. 사실 이 책은 펼쳐놓고 코드를 타이핑하고 응용하는 책은 아니다. 이 책에서 실제 코드는 단 한 파트에서만 나온다. 대부분은 줄글과 이해를 돕기 위한 삽화로 구성되어 있다. 페이지 수는 260p 밖에 안되는 책이었다. 하지만 이 책을 완독하는데 순수 시간으로 약 20시간 정도가 든 것 같다. 단순히 글을 줄줄 읽기만 했다면 빠르면 1시간에도 충분했을 건데, 이 책이 설명하는 단어와 문장과 은유를 이해하려고 몇번이고 곱씹어보고, OKKY에 질문도 하느라 많은 시간이 들었다. 완독한 다음날인 오늘, 간략하게나마 회고를 해 본다. 일단, 어려웠다. 이 책은 은..

의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 많이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 이름은 대상의 존재 이유, 수행 기능, 사용 방법을 드러내야 한다. 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 단순히 이름만 고쳐도 함수가 하는 일을 이해하기 쉽다. 그릇된 정보를 피하라 그릇된 단서를 남기지 않는다. 널리 쓰이는 의미가 있는 단어를 사용하지 않는다. 예시 1 ) 직각삼각형의 빗변(hypotenuse)을 구현할 때 변수명 hp는 적당하지 않다. 유닉스 플랫폼을 가리키는 이름이기 때문이다. 그룹으로 묶은 의미를 사용할 때, 실제 List를 사용하지 않았다면 accountList와 같이 명명하지 않는다. 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는..

매달 비용을 지불해야 사용할 수 있는 유료 서비스가 있다. 이 서비스는 다음 규칙에 따라 서비스 만료일을 결정한다.서비스를 사용하려면 매달 1만원을 선불로 납부한다. 납부일 기준으로 한 달 뒤가 서비스 만료일이 된다.2개월 이상 요금을 납부할 수 있다.10만원을 납부하면 서비스를 1년 제공한다.납부한 금액 기준으로 서비스 만료일을 계산하는 기능을 TDD로 구현한다면 어떤 순서로 진행해야 할까? 먼저 테스트 클래스 이름을 정하자. 클래스 이름은 ExpiryDateCalculatorTest 로 정했다.public class ExpiryDateCalculatorTest {}쉬운 것부터 테스트이제 테스트 메서드를 추가한다. 테스트를 추가할 때에는 다음 두 가지를 고려해야 한다.구현하기 쉬운 것부터 먼저 테스트예..

예외 상황을 먼저 테스트해야 하는 이유다양한 예외 상황은 복잡한 if-else 블록을 동반한다.후에 예외 상황을 반영하려면 코드의 구조를 뒤집거나 조건문을 중복해서 추가하는 일이 발생한다.미리 예외 상황을 테스트 하면 예외 상황에 따른 if-else 구조가 미리 만들어지므로 코드 구조가 덜 바뀐다.예외 상황을 처리하지 않아 발생하는 버그를 줄여준다.완급 조절한번에 얼마만큼의 코드를 작성 할 것인가?TDD를 처음 접할 때는 다음 단계에 따라 익히는 것이 추천된다.정해진 값을 리턴값 비교를 이용해서 정해진 값을 리턴다영한 테스트를 추가하면서 구현을 일반화예를 들어 암호 강도 측정 기능에서 길이가 8글자 미만이지만 나머지 규칙은 충족하는 상황을 위 단계를 밟아 진행해보자. 먼저 다음 테스트 코드를 추가했다. ..

"테스트 주도 개발 시작하기" - 최범균 저위 책으로 공부하며 배운 것을 정리한 시리즈TDD를 공부하며 1장에서(1장은 포스팅하지 않았다.) 암호 강도 측정 기능을 만들었다. 기능을 구현할 때 규칙은 다음과 같았다.검사할 규칙 3가지길이가 8글자 이상이어야 한다.0부터 9 사이의 숫자를 하나 이상 포함해야 한다.대문자를 하나 이상 포함해야 한다.판별 기준세 규칙을 모두 충족하면 암호 강도는 "강함"이다.두개의 규칙을 충족하면 암호 강도는 "보통"이다.1개 이하의 규칙을 충족하면 암호는 "약함"이다.위 요구사항을 만족하는 테스트 코드를 작성한 순서는 다음과 같았다.모든 규칙을 충족하는 암호 강도는 "강함" 이다.길이만 8글자 미만이고 나머지 규칙은 충족하는 암호의 강도는 "보통" 이다.숫자를 포함하지 않고..

로버트 C. 마틴의 "클린 코드"를 읽고 정리하고 생각하는 시리즈 나쁜 코드 …우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다... 나중은 결코 오지 않는다. Clean Code, 4p 나쁜 코드의 악순환 나쁜 코드는 생산성을 떨어트린다. 코드를 고칠 때마다 매번 복잡한 코드를 다시 해독하고 수정해야 한다. 시간은 한정되어 있고 개발은 해야 하기에, 나쁜 코드 위에 나쁜 코드가 쌓이는 악순환이 생긴다. 생산성이 떨어지면 관리층은 나름대로 복구를 시작한다. 프로젝트에 인력을 추가로 투입하는 것이다. 하지만 새 인력은 시스템 설계에 대한 조예가 깊지 않아 나쁜 ..