테스트 암 Test Cancer

이올린에 북마크하기(0) 이올린에 추천하기(0)

A RefactoringBoundary.

코드 일부에 대해 인터페이스 변경이 가해지면 리팩터링으로 볼 수 있나요?

대답은 간단하다. 인터페이스 변경은 인터페이스를 호출하는 모든 코드에 변경이 요구되는 유형의 리팩터링의 일종이다. 이러한 리팩터링으로 대표적인 사례는 메소드 이름 변경(Rename Method)이다. 이름 변경은 거의 모든 리팩터링 도구에서 지원한다.

이러한 유형의 리팩터링에서는 반드시 호출하는 부분 빠짐없이 변경되어야 한다. 인터페이스 선언만 변경되고 호출하는 부분에서는 인터페이스 이름을 변경되지 않으면 시스템은 깨지고 결과적으로 행위가 변하고 만다.(역자주: 리팩터링은 시스템의 행위는 보존해야 한다.)

인터페이스 변경 리팩터링은 호출하는 모든 코드에 적용되는 것은 전제로 한다. 이는 Published Interface에 대해서는 더 노력을 기울여야 하는 이유이기도 하다. 인터페이스가 외부에 공개된 상황이라면, 인터페이스 자체가 시스템 행위의 일부로 인식되기 때문이다.

동적인 언어에 대해 이러한 변경을 다루는 것은 더욱 어렵다. 정적 타입 정의를 활용하면 다양한 지점에서 호출되는 인터페이스에 대해 명확하게 규명할 수 있다. 리플렉션(Reflection)을 사용하여 메소드 호출을 하는 경우라면, 메소드 이름이 문자열에 포함되어 있거나, 실행시점에서 구성되기 때문에 리팩터링 도구가 있다고 해도 인터페이스 변경 리팩터링이 쉽지 않다. 그래서 이러한 영역은 필수적으로 테스트가 요구되는 영역이다.  

출처: IsChangingInterfacesRefactoring

이올린에 북마크하기(0) 이올린에 추천하기(0)

몇년전 나는 eBay에서 일하고 있는 친구들과 이야기를 나눈 일이 있다. 수많은 사용자가 이용하는 사이트에서 사용하는 기법을 듣는 것은 항상 흥미롭다. 그러나, 그중에서도 가장 흥미로왔던 것은 eBay는 거의 데이터베이스 트랜젝션(transactions)을 사용하지 않는다는 사실이다.

대부분은 사람들에게 트랜젝션이 없는 환경은 무척 놀라운 일이다. 데이터베이스를 사용한다면 트랜젝션을 쓰는 것은 너무나도 보편적인 일이다. 나를 포함한 많은 사람들은 트랜젝션을 데이터베이스가 주는 핵심적인 이점으로 여긴다.

eBay의 대규모 사용자 환경에서 성능 저하를 야기한다는 점이 트랜젝션을 쓰지 않는 이유다. eBay는 데이터를 다수의 데이터베이스에 물리적으로 나누어 놓았기 때문에 트랜젝션이 가져오는 성능 저하는 더 심각해진다. 결과적으로 트랜젝션을 사용한다는 것은 분산 트랜젝션을 의미하기 때문이다.  

고도의 파티셔닝(partitioning)과 성능 이슈에 있어서 데이터베이스가 차지하는 지배적인 비중으로 인해 eBay는 다른 많은 데이터베이스 기능들도 사용하지 않는다. 참조 무결성(Referential integrity) 보장이나 정렬은 애플리케이션 코드에서 수행한다. 트리거(triggers)나 저장 프로시저(stored procedures)를 쓰는 일은 거의 없다.

트랜젝션이 없는 환경에 대한 이야기를 처음 들었을 때, 나는 애플리케이션 개발자에게 미치는 결과 특히 트랜젝션이 없다는 것에 대해 전반적으로 어떻게 느끼는가를 물어보았다. 대답하기를 처음에는 어색했지만, 생각보다 별 문제 없이 마칠 수 있었다고 한다. 데이터베이스에 커밋(commit)하는 순서에 유의해야 하고, 중요한 것을 먼저 커밋해야 할 뿐이다. 각각의 커밋시점에서 성공 여부를 확인하고, 실패했을 때는 어떻게 할 것인지를 결정해야 한다.

이러한 프로그래밍 스타일은 내 호기심을 자극했지만 이에 대해 거론하는 것을 조심해왔다. Dan Pritchett가 이번주에 QCon에서 eBay의 아키텍처에 대해 흥미로운 발표에서 관련 내용이 언급되었기 때문에 이제는 공개적으로 논할 수 있게 되었다. 발표 내