워밍업 클럽 그리고 그 이후 테스트코드와 클린코드 나의 생각

4주간의 스터디… 그리고 그 이후 나는 도대체 무엇을 하고 있을까? 지금 현재 내가 배운 내용 그리고 그 전과 그 이후과 얼마나 달라졌을까 비교하며, 회고를 하고 다시 한 번 마음을 다잡아보려한다.

클린코드의 적용

이 부분은 개인적으로 원래 잘하고 있던 부분이였다고 생각한다.

추상화의 고민, 관심사를 어떻게하면 공통으로 분리할까 나를 위한 읽기 쉬운 코드를 어떻게 만들까?

물론 이러한 영향을 준 것은 회사내 동료들의 아름다운 코드들과 아름답지 못한 코드들이고, 그 방법론은 클린코드, 리팩토링 등등 고전적인 책들과 다양한 읽기좋은 코드에 관련된 서적을 읽으면서 내 나름의 규칙을 만들기 시작했다.

한 달이 지난 지금 내가 잘했던 그 부분은 유지하되, 새로운 법칙이 생겼다.

나만의 용어 사전

사실 제일 못하는게 이름 짓는 부분이다.

아직도 못한다.

하지만, 이러한 이름을 더 효과적으로 짓기 위해서, 강사님이 말씀해주신 풀에서 꺼내서 쓰는 용어사전을 차츰차츰 나름 정리하기 시작했다.

이러한 용어들은 잘 정리된 오픈소스들에서 찾아보려고 노력을 많이 하였다.

과감한 오버로딩

오버로딩에 대해 사실 병적으로 싫어하던 시절이 있었다.

파라미터에 따라 그 메서드 이름이 참 보기 어려워서 장황한 메서드를 만든적도 있다.

public User createUserByNameAndYearAndAge(String name, int year, int age);
public User createUserByName(String name);

하지만, 문득 자바 Lists 인터페이스를 보게되었고 중요한것은 오버로딩하나로 가독성만 확보되면 된다는 부분이었다.

주석 사용

논쟁이 가장 많은 부분 중 하나로서, 주석을 사용하는가? 사용하지않는가? 라는 부분이다.

나는 후자에 가까운 개발자로서, 잘 설계된 코드는 주석보다 높은 가치를 한다고 믿었다…

그런데, 사실 잘 설계된 코드란 것은 그 때 내가 그렇게 믿는 것 뿐이지, 후대에 내가 다시보면 이해 못하는 코드가 많다.

결국 이러한 부분에 대한 이해를 돕는데는 주석을 적절히 활용하거나, 애초에 간결한 메서드 이름을 짓는 방법 밖에 없다.

테스트 코드

테스트 코드는 정말로 이 스터디의 전과 후과 눈에 띄게 달라졌다고 해도 과언이 아니다.

이전의 테스트 코드는 사실 동료와의 테스트 코드에 대한 고민, 그리고 클린코드를 읽고 테스트코드의 필요성과 리팩토링등 다양한 실무에 부딪히면서 나의 필요에 따라서 테스트 코드를 작성했다면, 강의 이후는 테스트코드를 하나의 테스트 도구로서 활용을 제대로 하고 테스트코드의 장점과 강점에 대해서 나름대로 정확하게 이해를 하게 되었다.

물론, 회사에서 내가 이렇게 테스트코드를 적극 도입하고 도입한 테스트코드에 대해 공유하며 나의 테스트코드에 대한 철학을 좀 더 고도화 시키는 부분들이 도움이 되었다.

TDD

대부분의 개발자들 (5년미만의 개발자들)은 TDD에 대해 환상을 가지고 있다.

TDD에 대한 환상을 가지고 있다면, 일단 한 번 도전해 보는 것을 추천한다.

물론 TDD를 위해 기존 잘 돌아가는 프로젝트를 아예 끄집어서 뒤엎는 것 보다.

사내에 도움이 될만한 프로덕트를 만들면서 TDD를 적용하는 것을 추천한다.

참고로 나는 TDD를 위해 백오피스를 했다 😃

내가 생각하는 TDD (테스트 코드)

TDD를 도입했는데, 내 생산속도가 느려졌어 라는 이야기를 종종 듣는다.

TDD가 아닌 테스트코드도 마찬가지다.

일단, 강사님이 말씀해주신 부분 중 하나 모든 영역을 테스트 커버하려고 하지않아도 된다. 라는 이야기를 세션 도중에 하셨다.

또한, 테스트 코드를 사용하면서 하나의 철학이 생겼다.

나의 테스트 코드는 ‘실용주의 테스트 코드’ 라는 철학으로 정의할 수 있다.

물론, 저 책에서 영감을 받은 것은 아니고… 그냥 단순한 나의 원칙이다.

실용주의 테스트 코드를 위한 나의 원칙

테스트 커버리지에 매몰되지 말자
주니어 개발자들은 이러한 커버리지에 매몰되는 경우가 상당히 많이 있다. ”테스트 코드 95% 커버리지” 물론 좋다고 생각한다. 근데, 95%의 커버리지를 채우는 시간보다. 차라리 로직에 대해서 완성도를 높이거나, 그 시간을 어느정도 분배하는게 맞다고 생각한다. 물론, 혼자서 하는 프로젝트에 대해서는 95%든 100%든 자기 만족이기에 상관없다고 생각들지만, 비즈니스 프로덕트에 커버리지에 매몰되는 것 보다. DDD에서 어떤 영역에 테스트 코드를 주로 작성했고, 왜 그 영역에 테스트 코드를 작성했는지에 대한 고민과 철학을 녹여내는게 중요하다.
테스트 코드는 유지보수가 필요하다
테스트 코드에 대해 관심을 가지게 해주는 동료와 고민했던 부분은 테스트 코드를 과연 유지보수를 적게 설계 하려면 어떻게 해야할까 라는 이야기를 많이 했었다. 사실 이러한 부분들 때문에, 테스트 코드를 작성할 때마다 ‘어짜피 이거 곧 깨질텐데…’ 라는 생각을 하게 되었다. 중요한 것은 깨지는게 맞는거 같다. 깨지면 고치면되고, 깨진다는 것은 그에 대한 사이드 이펙트들도 확인 할 수 있다는 점이다. 코드는 생물학과 마찬가지로 끝 없이 진화하고 테스트 코드는 그에 대한 가설이다. 가설은 어떠한 부분을 검증하기 위해 깨어질 수도 있고 새로 정의되어질 수도 있다. 컴퓨터는 공학적인 측면도 강하지만 과학적인 측면도 강하다.
테스트코드는 가설이다
테스트코드는 가설이기 때문에, 실제로 가설을 세우기 위해서는 이 가설이 맞는지에 대한 전반적인 이해가 필요하다. 예를 들어 내가 진화론이라는 가설을 새울 떼 유전진화학에 대한 학문에 대한 이해가 피상적으로 있는 상태에서는 가능할까? 사실, 불가능에 가깝다. 좋은 테스트 코드란 테스트 코드를 작성하기 위한 그 도메인에 대한 전반적인 이해도를 요구하고 수반한다. 실용주의적인 테스트 코드는 테스트 코드를 통해 도메인에 대한 지식도 높이는데 기여한다라는 생각에 기반한다.

성장

끝으로 이번 세션 이후로 나의 성장이 많이 되었다는 것도 느끼지만 회사에서 코드가 깔끔할 뿐만 아니라 테스트 코드까지 합리적인 이유와 검증가능한 코드다 라는 이야기를 들었다.

그리고, 최근 1000줄 가까이 되는 레거시의 가독성을 확보하고, 그에 대한 테스트 코드로 검증하는 과정을 걸치면서 코드의 현대화도 많이 이루어냈다.

레거시라는 것은 개인적으로 이렇게 정의하려고한다.

‘가장 중요하고 필요한 기능이지만, 그 누구도 고치려고 하지 않은 미지의 영역’

바꿔말하면 가장 중요하기에 나만 알아야하는게 아닌 모두가 알아야하고 모두가 아는 비용을 줄이기 위해서, 고민을 한다면 그리고 이게 합리적 이유라면 클린코드와 테스트코드 도입하지 않을 이유가 없지 않을까?