본문 바로가기
Homo Architect/Things Every SW Architect Should Know

반복 작업과 싸워라

by javauser 2009. 8. 19.

- Niclas Nisson

여러분의 개발자들이 사고를 거의 필요하지 않은 반복적인 작업을 수행하고 있습니까? 여러분은 코드에서 반복적인 패턴을 발견할 수 있습니까? 복사-붙여넣기-수정 형태로 작성된 코드를 분간할 수 있습니까? 만일 그렇다면, 여러분의 팀은 생각했던 것보다 더 느리게 움직이고 있으며, 이상하게 들릴지 모르겠지만, 당신이 그 원인일 수 있습니다.

왜 그런지 설명하기 전에, 소프트웨어 개발에 관한 두가지 사실에 대해 동의해야 합니다.
  • 복제는 악이다.
  • 반복적인 작업은 개발을 느리게 한다.


아키텍트로서 당신은 분위기를 조성합니다. 시스템에 대한 전반적인 가장 최고의 내용을 파악하고 팀에게 지금까지 여러 차례 복사해서 사용했던 예제로 제공할 시스템에 대해 최신 유행의 end-to-end 단면을 작성할 것입니다. 개발자가 몇줄의 코드, 혹은 XML이나 클래스와 같은 어떤 것을 복사할 때마다 특정 지점은 더 간단하게 만들어져야 하거나 아예 완전하게 추상화되어야 된다는 명백한 증거입니다. 너무나 자주 복사되는 것은 도메인 로직이 아니며, 실행하기 위해 그 지점에 있어야 되는 기반 구조 코드라고 합니다. 그러한 이유로 인해 여러분의 예제가 가지게 되는 효과를 상상해볼 수 있는 것이 중요합니다. 여러분의 예제의 코드나 설정은 시스템의 수십, 수백, 혹은 수천개의 단면에 대한 기초가 될 수 있으며, 이는 여러분의 코드가 깔끔하고, 의도가 분명해야 하며, 추상화될 수 없는 것을 제외한 아무것도 담고 있지 않아야 됨을 의미합니다. 즉, 도메인 문제 그 자체이어야 합니다. 아키텍트로서 어떠한 종류의 반복적인 패턴에 매우 민감할 필요가 있으며, 이는 여러분이 작성한 모든 것이 (얄궂게도) 반복될 것이기 때문입니다.

하지만 그러한 일들이 여러분의 시스템에서 발생되지 않는다고 생각하나요? 설정 파일을 한번 보십시오. 시스템의 또 다른 부분에 적용될 때 달라질 필요가 있는 것이 무엇이며, 동일하게 남아 있는 것이 무엇인가요? 전형적인 비즈니스 레이어 메소드를 살펴보십시오. 트랜잭션 처리, 로깅, 인증, 감사와 같은 것들을 포함해서 다른 메소드에서도 나타나는 패턴이 있습니까? 데이터 접근 레이어는 어떻습니까? 엔터티와 필드의 이름을 제외하고 동일하게 되어 있는 코드가 있습니까? 더 넓게 살펴보십시오. 자주 같이 사용하는 것 같은 2 ~ 3 줄의 코드를 발견할 수 있다거나, 서로 다른 객체에서 수행되더라도 유사한 것처럼 보입니까? 반복에 대한 모든 예제들은 많이 있습니다. 코드에서의 반복은 일단 개발자들이 흥미로운 변동성이 발견되는 지점을 해결할 때 결국 개발자들이 코드를 읽을 때에 제거하거나 무시하도록 습득하는 행위이지만, 개발자들이 이를 사용한다고 하더라도 개발 속도를 느리게 합니다. 그러한 코드는 개발자들이 읽을 수 있는 코드가 아니라, 분명히 컴퓨터가 실행하기 위해 작성된 것입니다.

여러분의 의무는 그러한 코드를 없애는 것입니다. 그렇게 하기 위해서 프레임워크를 잘 만들고, 더 나은 추상화를 개발하고, 혹은 Aspect  프레임워크를 설정하기 위한 도구를 살펴보거나 약간의 코드 생성기를 만드는 것이 필요할 수도 있겠지만, 누군가가 이에 대한 어떤 것을 하기 전까지 반복은 없어지지 않을 것입니다.

그 누군가는 바로 여러분입니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - Fight repetition

반응형