클린 소프트웨어 - 프로그래밍 에피소드

Presto

2020-01-18

Software Engineering

프로그래밍 에피소드

이 장에서는 두 명의 사람이 페어 프로그래밍 방식, 테스트 주도 개발 방식으로 볼링 게임의 점수를 계산하는 프로그램을 작성하는 에피소드를 소개한다.

볼링에서 사용되는 게임 / 프레임 / 투구의 개념을 클래스들의 의존 관계로 옮겨 다이어그램을 간단하게 작성한다.

페어 프로그래밍을 하면서 의견을 서로 나누고, 먼저 테스트를 작성한 후 실제 코드를 작성하면서 생각을 실현해 나간다. 이 과정에서 서로 의견이 충돌하는 경우 충분한 토론을 통해 더 나은 방법을 도출해내게 된다.

간단한 것부터 구현하여 좀 더 복잡한 것들을 구현한다. 예를 들어 각 투구마다 점수를 기록하여 계산하는 것부터, 스페어 및 스트라이크가 프레임이 포함되는 경우 프레임의 점수를 구하고 전체 점수를 계산하는 것과 같은 로직을 차근차근 구현해 나간다.

처음 생각했던 설계가 올바르지 않은 경우도 발생할 수 있다. 이 책의 예제는 처음에 볼링 게임 프로그램을 구현하기 위해 세 개의 클래스를 정의하려 했는데, 결과적으로 하나의 클래스만을 사용하고도 프로그램을 구현할 수 있었다.

모든 테스트를 통과한 프로그램이라 할지라도 아직 완성된 것이 아니다. 리팩토링 과정을 거쳐 좀 더 의도에 부합하고 읽기 쉬운 코드로 수정해야 한다.

이 과정에서 책은 다음의 것을 시도하였다.

단일 책임 원칙을 지키기 위해 객체의 특정 책임을 다른 객체로 분리한다.
클래스의 멤버 변수의 이름과 메소드의 지역 변수의 이름이 겹치는 경우 혼란을 방지하기 위해 이름을 다시 짓는다.
현실 세계의 생각 흐름과 비슷하게 코드를 다시 작성한다.
평가식을 함수로 분리하여 실제 코드에서의 의도를 더욱 명확히 한다. 가령 if score == 10을 if strike()처럼 작성할 수 있다면 의도를 더욱 분명하게 표현할 수 있을 것이다.
함수나 변수의 이름을 좀 더 명시적인 것으로 변경한다.
전체적으로 코드가 생각의 흐름대로 잘 읽히는지 평가하고 그렇지 않다면 의도를 명시적으로 드러내기 위한 코드로 수정한다.
매직 넘버가 의도와 맞지 않게 사용된 경우 관련 로직을 다시 살펴보고 수정한다.
리팩토링을 수행하는 중간 중간에 테스트를 실행하여 프로그램이 올바로 동작하고 있는지 확인한다.

객체 지향 원칙을 적극적으로 적용하는 것이 좋은 프로그램을 만드는 방법인가? 프로그래밍 이전에 UML이나 시퀀스 다이어그램과 같은 것을 잘 활용하는 것이 중요한가?

책은 이해하기 쉬운 프로그램이 유지보수하기 쉬운 것이라고 말하고 있다.

다이어그램을 만드는 것이 불필요할 때는, 다이어그램을 코드 없이 만들고 그것을 따르려고 할 때다. 다이어그램은 최적의 설계가 될 수 없기 때문이다.

먼저 테스트를 작성하고 차근차근 단계를 밟아가며 최적의 설계를 찾아가는 것이 좋다.