taetae98

1997년만 해도 TDD라는 개념을 몰랐다. 대다수가 단위 테스트란 프로그램이 '돌아간다'는 사실만 확인하는 일회성 코드에 불과했다. 직접 수동으로 테스트를 수행하고, 그로고 나서는 테스트 코드를 버렸다. 우리 분야는 지금까지 눈부신 성장을 이뤘지만 앞으로 갈 길은 여전히 멀다. 에자일과 TDD 덕택에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 늘어나는 추세다. 하지만 테스트를 추가하려고 급하게 서두르는 와중에 제대로된 테스트 케이스를 작성해야 한다는 사실을 놓쳐버렸다. TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 ..

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 패키지를 사고, 오픈 소스를 이용하고, 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 외부 코드 사용하기 패키지 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까. 반면, 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 긴장으로 인해 시스템 경계에서 문제가 생긴다. 대표적인 예로 java.util.Map을 살펴보자. Map은 다양한 인터페이스로 많은 기능을 제공한다. Map이 제공하는 기능과 유연성은 확실히 유용하지만 그만큼 위험도 크다. Map에는 clear, set, remove 함수를 제공하기 때문에 Map을 ..

뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 우리 프로그래머에게 있다. 깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 여기저기 흩어진 코드 때문에 실제 코드가 하는 일을 파악하기가 어려워지게 된다. 오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 이 장에서는 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 소개한다. 오류 코드보다 예외를 사용하라 예전에는 예외를 지원하지 않는 프로그래밍 언어가 많았다. 그렇기 때문에 오류 플래그를 설정하거나, 오류 코드를 반환하는 방법이 전부였다. 예외를 사용하는 대신 오류 코드를 사용하면 코드가 훨씬..

자료 추상화 public class Point { public double x; public double y; } 확실히 직교좌표계를 사용한다. 개별적으로 좌표값을 읽고 설정하게 강제한다. public interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double theta); } 직교좌표계를 사용하는지 극좌표계를 사용하는지 알 길이 없다. 좌표를 읽을 때 각 값을 개별적으로 읽어야 한다. 좌표를 설정할 때는 두 값을 한꺼번에 설정해야 한다. 그저 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 ..

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다. 형식을 맞추는 목적 코드 형식은 중요하다! 너무 중요해서 무시하기 어렵다. 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 원래 코드가 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. 의사소통할 때 물과 불을 바꿔서 말하면 혼란이 올 것이다. 코드 형식이 다르다면 코드..

주석 사실상 주석은 기껏해야 필요악이다. 우리에게 프로그래밍 언어를 치밀하게 사용해 의도를 표현할 능력이 있다면, 주석은 거의 필요하지 않으니라. 아니, 필요하지 않으리라. 그러므로 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 주석을 무시하는 이유? 주석은 너무 자주 거짓말을 하니까. 주석은 오래될수록 코드에서 멀어지고, 그릇될 가능성이 커진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까. 코드는 변화하고 진화한다. 일부가 옮겨지거나 조각이 나눠지고 합쳐진다. 불행하게도 주석은 언제나 코드를 따라가지 않는다. 주석이 코드에서 분리되어 점점 더 부정확한 고아로 변하는 사례가 너무도 흔하다. 프로그래머들이 주..

작게 만들어라! 함수를 만드는 첫째 규칙은 '작게'다. 함수를 만드는 둘째 규칙은 '더 작게'다. 이 규칙은 근거를 대기가 곤란하다. 함수가 작을수록 더 좋다는 증거나 자료를 제시하기도 어렵다. 하지만 나는 지난 40여년 동안 온갖 크기로 함수를 구현해봤다. 지금까지 경험을 바탕으로 그리고 오랜 시행착오를 바탕으로 나은 작은 함수가 좋다고 확신한다. 개인적인 생각 좋은 함수명과 작은 함수는 주석없이 코드를 읽게 만들어준다. 작은 함수는 재사용이 편리하고, 오류 추적이 쉽고, 테스트가 편하다. 그렇다면 얼마나 짧아야 좋을까? 80년대에는 함수가 한 화면을 넘어가면 안된다고 말했다. 당시 모니터 화면은 가로 80자 세로 24줄이었고 편집기에서 4줄을 관리용으로 사용했습니다. 가로 150자를 넘어서는 안 된다..

의미 있는 이름 소프트웨어에서 이름은 어디나 쓰입니다. 변수, 함수, 인수, 클래스 심지어 디렉터리, jar, war, ear 등 다양한 곳에 쓰입니다. 이렇듯 많이 사용하므로 이름을 잘 지으면 여러모로 편합니다. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많습니다. 그러므로 이름을 주의깊게 살펴 더 나은 이름이 떠오르면 개선해야합니다. int d; // 경과 시간 int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; 이름 d는 아무 의미도 없고 이를 설명하기 위한 주석이 필요합니다. 하지만 변수 명을 좀 더 자세하게 지으면 의미도 명확하고..