이 시리즈의 첫 기사인 "아키텍처와 설계 조사하기"에서 필자는 중대한 크기의 모든 프로젝트가 아무도 예상하지 못한 설계 요소를 포함하는 것을 주장했다. 문제의 세부사항으로 들어갈 때, 어렵다고 생각한 것이 예상보다 간편하거나 그 반대의 경우를 발견하는 것이 매우 일반적이다. 다음 기사는 숨겨져있지만 흥미로운 설계 요소를 밝히기 위한 기술을 시연했다. 이 기사에서 필자는 이러한 아이디어를 연결하고 방치된 코드 기반 중요 부분을 발견하기 위해 도구와 접근방식을 사용하여 확장된 케이스 스터디를 소개한다.

필자는 "Composed method and SLAP"에서 관용적 패턴의 개념을 소개했다. Gang of Four의 Design Patterns 저서로 대중화된 공식적인 Design Patterns(참고자료 참조)와는 반대로, 관용적 패턴은 모든 프로젝트에 걸쳐서 적용되지 않는다. 그러나 이는 만연하여 코드에서 일반 설계 관용구를 표현한다. 이는 순수하게 기술 패턴에서부터(예를 들어, 프로젝트가 거래를 처리하는 방법) 문제점 도메인 패턴에("순서를 처리하기 전에 고객의 신용을 항상 확인하는 것" 등) 이를 수 있다. 이러한 패턴을 발견하는 것은 창발적 설계의 핵심이다.

Big Design Up Front 설계 방법론의 지지자는 코딩을 시작하기 전에 많은 시간을 들여 애플리케이션에 필요한 모든 설계 요소를 판별하기 위해 노력한다. 문서화하는 내용의 대부분은 솔루션의 전체적인 설계에 중요하다. 하지만, 소프트웨어를 구현하는 것은 놀라운 사실을 드러낸다. 구현하는 모든 설계 요소는 다른 설계 요소에 결합되어, 종속 항목과 관계의 복잡한 망을 작성한다. 독자가 생각하는 코드의 측면은 시스템의 모든 다른 필수 부분을 구현하면 복잡성 면에서 사소한 것들을 확대할 것이다. 코드에서 이질적인 설계 요소의 복잡한 상호 작용을 이해할 수 없으면 솔루션을 완료하는 데 필요한 노력을 예측하는 면에서 엄청난 어려움이 나타난다. 예측은 엄밀하게 말하면 소프트웨어에서 여전히 마술에 가깝다. 왜냐하면 커플링과 상호작용의 복잡한 거미줄을 이해하고 분석하기가 어렵기 때문이다.

창발적 설계에 의존하는 애자일 방법론은 다른 접근방식을 시도한다. 애자일 아키텍처와 설계는 코딩 전에 설계를 피하지 않지만, 실행자들은 전체적인 것의 사소하지 않은 부분을 구현할 때까지 문제를 완전히 이해할 수 없음을 발견했다. 창발적 설계에서 기술을 개발하면 컨텍스트를 더 보유할 때까지 의사결정을 미룰 수 있다. 린 소프트웨어 이동(참고자료 참조)은 마지막 의사결정 순간(last responsible moment)이라는 훌륭한 개념이 있다. 즉, 이는 마지막 순간이 아니라 마지막 의사결정 순간이 될 때까지 의사 결정을 미룬다. 설계 의사결정을 오래 미루면 미룰수록 가진 정보가 더 많아져서, 더 미묘한 차이가 있는 컨텍스트화된 의사결정을 사용한다.

관용적 패턴 채취하기

창발적 설계는 기존 코드에서 설계 요소를 찾는 기능을 암시한다. 재사용 잠재성을 통한 효율적인 추상으로 이러한 요소에 대해 생각할 수 있다. 이러한 관용적 패턴을 채취하기 위한 기술 중 하나는 메트릭의 결합을 사용한다. 이 기술을 시연하기 위해 필자는 Apache Struts 코드 기반(참고자료 참조)을 사용할 것이다(필자가 이전 기사에서 보유한 것처럼). 필자는 Struts에 부족분(실제로는 그 반대임)이 있다고 생각하는 것 때문이 아니라 잘 알려져 있는 오픈 소스라는 것 때문에 Struts를 사용하는 것이다. 필자는 어느 프로젝트나 그렇게 하는 것처럼 모든 코드 기반이 관용적 패턴을 포함한다고 주장한다.

돌아온 메트릭 사용하기

"Emergent design through metrics"에서 필자는 설계를 개선하는 리팩토링을 위한 대상으로서 익숙하지 않은 코드 기반의 흥미로운 부분을 밝히기 위해 메트릭을 사용하는 것을 논의했다. 필자는 두 가지 메트릭인 순환적 복잡도 및 afferent 커플링을 사용했다. 순환적 복잡도는 순수하게 하나의 메소드 대 다른 메소드의 상대적 복잡도의 측정이다. 그러면 다른 순환적 복잡도 측정과 비교할 때에만 이치에 맞는다. 하지만, 낮은 순환적 복잡도를 갖춘 메소드가 일반적으로 덜 복잡하다고 주장하는 것은 당연하다. Afferent 커플링은 얼마나 많은 다른 클래스가 필드 또는 매개변수를 통해 현재 클래스를 참조하는지 표현한다. 필자는 CJKM 메트릭 도구(참고자료 참조)를 사용하여 Struts 코드 기반에서 이러한 수를 수집한다.

Struts 2 코드 기반에 대해 이러한 두 가지 메트릭을 실행하면 다음 그림 1의 테이블을 만들어, 문제가 되는 두 가지 메트릭만 보여준다.

다음 그림 2는 동일한 테이블을 보여주고, 이는 클래스 당 무게 메소드(WMC)로 정렬된다.

이 결과를 보기만 하면, DoubleListUIBean 클래스가 Struts 코드 기반에서 가장 복잡한 클래스임을 확인할 수 있다. 이는 복잡성의 일부를 제거하고 패턴을 반복하여 일부 추상 가능한 것을 찾을 수 있는지 확인하는 리팩토링을 위한 훌륭한 후보자임을 암시한다. 하지만, WMC 숫자는 더 나은 설계를 향해 이 클래스를 리팩토링하는 면에서 투자하는 것이 시간을 잘 활용하는 것인지 아닌지 여부를 알려주지는 않는다. 이 클래스에 대한 Ca(afferent 커플링) 메트릭에 3의 값이 있음을 확인하자. 이는 다른 세 가지 클래스만 이 클래스를 사용하는 것을 의미한다. 이 클래스의 설계를 개선하는 데 많은 시간을 투자할 가치가 없을 수도 있다.

다음 그림 3은 이번에 CA로 정렬된 동일한 CKJM 결과를 보여준다.

이 결합된 보기는 Struts에서 가장 많이 사용된 클래스가 Component임을 보여준다(Struts가 웹 프레임워크임을 감안하면 놀라운 일도 아니다). Component가 DoubleListUIBean처럼 복잡하지 않은 반면, 이는 177개의 다른 클래스로 사용되며 설계 개선을 위한 훌륭한 후보가 된다. Component의 설계를 더 우수하게 만드는 것은 많은 수의 다른 클래스에 반향 효과가 있다.

그림 3에서 표시된 보기를 통해 참조의 복잡성과 수를 나란히 확인할 수 있다. 설계 도전과제가 있는 클래스를 찾으려면 숫자의 높은 결합(많은 다른 클래스에서 사용된 복잡한 클래스 암시하기)을 찾는다. 조사를 위한 고급 후보는 UIBean 클래스이며, 53의 순환적 복잡도와 22의 afferent 커플링이 있다. 이는 많은 다른 클래스가 사용하는 복잡한 클래스이므로 필자는 이를 추가로 조사할 것이다.

순환적 복잡도 숫자 ckjm 보고서는 클래스에서 모든 메소드의 복잡도의 합계를 표현한다. 필자는 이 클래스를 매우 복잡하게 만드는 것을 식별하고자 하므로 메소드에 대한 개별 복잡도 숫자가 필요하다. 이 단일 클래스에서 오픈 소스 순환적 복잡도 도구인(참고자료 참조) JavaNCSS를 실행하면 다음 그림 4에 나타난 결과를 야기한다.

지금까지 가장 복잡한 메소드는 43의 복잡도로 evaluateParams()이다(그리고 또한 코드 행의 제일 좋은 몫임). 이 메소드는 분명히 Struts 제어기로 요청의 일부로 전달된 추가 매개변수의 일반 케이스를 처리하여, 실제 Struts 클래스와 컴포넌트로 매개변수 유형을 디스패치한다. 많은 구조적 중복은 다음 목록 1과 같이 이 코드에 존재한다.

if (label != null) {
    addParameter("label", findString(label));
}

if (labelPosition != null) {
    addParameter("labelposition", findString(labelPosition));
}

if (requiredposition != null) {
    addParameter("requiredposition", findString(requiredposition));
}

if (required != null) {
    addParameter("required", findValue(required, Boolean.class));
}

if (disabled != null) {
    addParameter("disabled", findValue(disabled, Boolean.class));
}

if (tabindex != null) {
    addParameter("tabindex", findString(tabindex));
}

if (onclick != null) {
    addParameter("onclick", findString(onclick));
}
// much more code elided for space considerations

이 코드는 개선을 위한 후보이다(다음 섹션의 코드 개선하기, 파트 1을 참조). 하지만 필자는 이 코드가 존재하는 원인과 왜 매우 높은 복잡도가 들어있는지 알아보려고 한다.

순환적 복잡도와 afferent 커플링의 다른 높은 결합을 살펴보면서, 필자는 각 33과 12의 값이 있는 WebTable을 찾는다. 여기에서 JavaNCSS를 실행하면 필자의 의심을 확인한다. 즉, 두 번째로 복잡한 메소드는 evaluateExtraParams()이다. 필자는 여기에서 패턴을 확인한다! 필자는 많은 다른 클래스에서 이러한 반복된 복잡한 요소를 확인하면 매개변수를 중심으로 많은 우발적 복잡도가 존재한다는 것을 의심하게 되어 이에 실험을 수행한다. 약간의 UNIX® 명령형 마술을 사용하여 필자는 Struts에서 얼마나 많은 클래스에 evaluateParams() 또는 evaluateExtraParams()라는 이름의 메소드가 있는지에 대해 확인할 것을 기대한다.

find . -name "*.java" | xargs grep -l "void evaluate.*Params" > pbcopy 

이 명령은 현재 디렉토리 아래로 모든 Java™ 소스 파일을 찾는다. 그리고 찾은 각 파일에 대해 evaluate로 시작하고 Params로 끝나는 어느 메소드 정의나 파일 내에서 찾는다. 재이동의 마지막 조각(>)은 클립보드에서(적어도 Mac의 경우에는) 결과 파일 목록을 붙여넣는다. 결과를 붙여넣으면 다음의 놀라운 결과를 얻게 된다.

AbstractRemoteCallUIBean.java
Anchor.java
Autocompleter.java
Checkbox.java
ComboBox.java
DateTimePicker.java
Div.java
DoubleListUIBean.java
DoubleSelect.java

File.java
Form.java
FormButton.java
Head.java
InputTransferSelect.java
Label.java
ListUIBean.java
OptionTransferSelect.java
Password.java
Reset.java
Select.java
Submit.java
TabbedPanel.java
table/WebTable.java
TextArea.java
TextField.java
Token.java
Tree.java
UIBean.java
UpDownSelect.java

이러한 모든 클래스는 여기에 이러한 하나의 메소드 또는 둘 다가 있다! 필자는 관용적 패턴을 찾았다. 분명히 Struts에서 많은 클래스들은 매개변수가 처리되는 방법의 작동을 오버라이드하고 사용자 정의해야 하고, 이러한 모든 클래스들은 사용자 정의 케이스를 스스로 처리한다. 이제 질문은 이를 어떻게 더 나아지게 하는가이다.

코드 개선하기, 파트 1

독자는 UIBean의 evaluateParams() 메소드에서 필자의 동료 중 한 사람이 "동일한 공백, 다른 값"이라고 부르는 다양한 구조적 중복을 많이 확인한다. 다시 말해서, 구조는 다른 클래스 또는 변수 이름에 대한 대체와 동일하다. 사소하게 변형된 애플리케이션 전반에 걸쳐 근본적으로 코드를 복사하여 붙여넣었기 때문에 이는 코드와 유사하게 나타난다.

구조적 중복을 수정하기 위한 일반적인 기술은 메타프로그래밍을 사용하여 하나의 공간에서 반복된 구조를 요약한다. 다른 필수 값을 공급하기 위해 리플렉션을 사용하는 다음 목록 2는 새 메소드와 evaluateParams() 메소드로 개선된 서두를 보여준다.

protected void handleDefaultParameters(final String paramName) {
  try {
      Field f = UIBean.class.getField(paramName);
      if (f.get(this) != null)
          addParameter(paramName, findString(f.get(this)));            
  } catch (Exception e) {
      throw new RuntimeException(e.getMessage());
  }
}

public void evaluateParams() {

  addParameter("templateDir", getTemplateDir());
  addParameter("theme", getTheme());

  String[] defaultParameters = new String[] {"label", "labelPosition", "requiredPosition",
      "tabindex", "onclick", "ondoubleclick", "onmousedown", "onmouseup", "onmouseover", 
      "onmousemove", "onmouseout", "onfocus", "onblur", "onkeypress", "onkeydown", 
      "onkeyup", "onselect", "onchange", "accesskey", "cssClass", "cssStyle", "title"};

  for (String s : defaultParameters)
      handleDefaultParameters(s);

목록 2에서 handleDefaultParameters() 메소드는 원본에서부터 하나의 if 명령문으로 반복된 구조를 요약한다. 이는 Struts 매개변수 이름을 지정하는 매개변수를 승인하고 리플렉션을 사용하여 적절한 필드를 프로그래밍 방식으로 취한다. 그 다음에 이는 원본 코드에서부터 null 검사를 수행하여, 마지막으로 Struts addParameter() 메소드를 호출한다.

필자가 handleDefaultParameters 메소드가 있으면, 원본의 코드 행의 수(및 순환적 복잡도)를 엄청나게 줄일 수 있다. 필자는 각 적용 가능한 Struts 매개변수에 대해 String 배열을 작성하고 해당 배열에 대해 반복하여, 각 배열에서 handleDefaultParameters() 메소드를 호출한다.

간결한 위치로 확인하는 모든 매개변수를 통합하여 필자는 메소드의 크기에서 줄이는 것보다 많은 작업을 했다. 원본 메소드는 43의 순환적 복잡도를 보유했다. 각 이전 if 블록은 코드 3행을 취했다(그리고 1 순환적 복잡도 지점을 기여했음). 필자는 단일 9행 메소드로 중복을 제거하고(4의 순환적 복잡도 사용) 66코드 행을 삭제했다(각각 22개 매개변수 x 3행). 이는 이러한 간단한 변경이 이 클래스에서부터 57행을 제거했고 새 메소드에 대해 18점으로 순환적 복잡도를 떨어뜨렸다(1 CC 점 x 22 매개변수 - 4 CC 점)는 점을 의미한다. 이러한 작은 변경에 대해 필자는 애플리케이션의 가독성, 메트릭, 크기 및 유지보수성을 크게 개선했다. 필자가 향후에 Struts addParameter() 메소드를 호출하는 방식을 변경해야 하면 한 곳에서 이를 수행할 수 있다.

이는 단기 수정사항이지만, 필자는 간단한 변경이 코드의 정화에 어떻게 심오한 영향을 줄 수 있는지 시연하도록 보여준다. 하지만, 이는 필자의 코드 기반인 경우 장기간 솔루션을 준비할 것이다.

코드 개선하기, 파트 2

이 작업이 필자의 프로젝트라면, 필자는 전체 매개변수 처리 메커니즘을 클래스의 자체 세트로 추상화할 것이며, 이는 근본적으로 Struts 내에서 서브프레임워크를 빌드한다. 매개변수를 처리하기 위한 코드의 복잡도뿐만 아니라 만연성과 양은 이는 Struts 내에서 최상급 시민들로 처리되어야 한다는 것을 암시한다. 이렇게 하면 하나의 기사의 범위를 벗어나지만, Struts의 복잡도의 엄청난 양(메트릭에 따라)은 이 문제를 중심으로 순환하는 것을 확인할 수 있다.

위로

창발적 설계 및 관용적 패턴

Struts의 최초 설계자가 매개변수를 처리하는 데 얼마나 많은 코드가 필요할 것이라고 상상이나 했을까? 소프트웨어는 이와 같다. 때로는 문제점 분야의 추측에 근거한 지식에 따라 복잡도를 예측할 수 있지만, 코드를 쓰는 것은 가상적으로 예측할 수 없는 새 제한조건과 기회를 낳는다. 실제로 선임 개발자들은 어려운 것을 예측하는 면에서 훨씬 더 나아지지 않는 반면, 수수께끼 같은 어려운 것이 실제로 나타날 것이라고 더 잘 추측하게 된다.

창발적 설계의 매력 중 일부는 어려워질 것을 믿을 만한 정도로 예측할 수 없지만 이에 대해 감시해야 한다는 것을 인식하는 것이다. 추상과 패턴을 찾을 예상을 하면서 코드 기반을 살펴보면, 더 쉽게 확인하게 된다.

필자가 간헐적으로 작업한 ThoughtWorks 프로젝트에 따라 케이스 연구를 마친다. 이러한 대규모 Ruby on Rails 프로젝트의 매우 초기 단계에서 기술 리드는 몇 가지 격리된 케이스에서 비동기 작동이 필요했음을 인식했다(예를 들어, 많은 수의 이미지를 업로드할 때, 사용자는 페이지를 떠나서 나중에 그 상태로 다시 돌아올 수 있도록 하려 했다). Big Design Up Front 사고방식이 있었다면, 즉시 메시지 큐에 대해 살펴 보았을 것이다. 하지만 프로젝트의 착수에서 비동기성이 필요한 모든 것을 알 수 없었을 때, 기본 위치는 향후 새 요구사항을 처리할 수 있도록 보장하기 위해 찾을 수 있는 가장 정교한 메시지 큐가 필요하게 될 것이다. 하지만 기술 리드는 지능적으로 이를 수행하지 않았다. 그는 이 상황에 우리가 가지고 있는 것이 충분하다고 결정했다.

2년 후로 빨리 넘어가자. 이 시점에 애플리케이션은 세 가지의 구별되는 비동기 작동이 있으며, 현재 솔루션은 병목현상이 되기 시작했다. 이제 메시지 큐를 얻을 시간이다. 하지만 기술 리드는 의사결정을 매우 오래 지연했기 때문에, 메시징에 관련하여 이 애플리케이션이 필요한 것을 정확히 인식하여, 작업을 수행한 가장 간단한 도구를 얻을 수 있었다. 마지막 의사결정 순간까지 기다려서 필요한 것보다 더 정교한 도구로 도입되는 우발적 복잡도를 중심으로 작업의 시간을 절약했다 — 더 깔끔한 코드, 새 기능에 대한 더 높은 속도 및 작업하기에 덜 복잡한 것을 야기한다.

이 코드를 통해 설계로 나아가도록 허용하는 것은 필요한 것에 대해 더 잘 이해한다는 의미이다. 설계 의사결정을 더 오래 미루면 미룰수록 장기간 함축 사항을 보유할 의사결정을 행할 시간이 되면 경로가 더 깔끔하게 된다.

위로

결론

이 기사 시리즈의 많은 내용은 컨텍스트를 염두에 두고 있으므로 실제 이점이 나타날 수 있다. 이번 기사는 가상으로 시리즈의 이전 기사들을 모두 함께 묶어서, 기술, 도구 및 표현된 태도를 활용한다. 창발적 설계는 관용적 패턴과 추상을 확인하고 수집하는 기능과 이러한 것들이 나타날 때 이를 활용하는 도구와 기술이 필요하다. 선행 설계는 중요한 부분을 개발하는 데 도움을 준다(그리고 애자일 프로젝트는 이러한 사항을 판별하기 위해 선행 설계를 충분히 수행한다). 하지만 코딩을 시작할 때 눈과 마음을 열고 있으면 놀랍게도 중요한 설계 요소로 안내할 것이다. 모든 코드 기반은 관용적 패턴이 있으며, 독자는 이를 확인하여 작동하도록 배워야 한다.

필자는 지난 몇 가지 기사에서 대부분 설계와 관련된 관심사를 다루었다. 다음에는 혁신적인 아키텍처로 다시 파고들어 애자일 개발 기술이 아키텍처적 개념과 결합할 때 나타나는 일반적인 관심사와 솔루션을 알려줄 것이다.

참고자료

교육

• The Productive Programmer(Neal Ford 저, O'Reilly Media, 2008년): 이 시리즈의 다양한 주제를 확장해 놓은 Neal Ford의 최신 저서이다.
  
  
• Design Patterns: Elements of Reusable Object-Oriented Software(Erich Gamma 외 공저, Addison-Wesley, 1994년): 설계 패턴에 대한 Gang of Four의 고전 작품이다.
  
  
• Lean software development: 이 위키피디아 기사는 린 제조업에서부터 기술을 차용한 린 소프트웨어 운동의 훌륭한 개요를 제시한다.
  
  
• Mary Poppendieck: Poppendieck은 린 소프트웨어 개발 운동의 유명한 선구자이다. 그녀의 웹 사이트는 이러한 접근방식을 강조하는 수많은 자원들이 들어있다.
  
  
• Apache Struts: 이 기사의 예제는 대중적인 Java용 오픈 소스 웹 프레임워크인 Struts용 코드 기반을 사용한다.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  
• developerWorks Java 기술 영역: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
  
  

제품 및 기술

• ckjm: ckjm은 Java 코드를 위한 Chidamber/Kemerer 객체 지향 메트릭 제품군 결과를 생성하기 위한 오픈 소스 도구이다.
  
  
• JavaNCSS: JavaNCSS는 순환적 복잡도를 위한 메소드 레벨 값을 제공하는 오픈 소스 메트릭 도구이다.
  
  

토론

• My developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Neal Ford는 글로벌 IT 컨설팅 업체인 ThoughtWorks의 소프트웨어 아키텍트이자 Meme Wrangler이다. 애플리케이션, 교육용 자료, 매거진 기사 및 비디오/DVD 프리젠테이션을 설계 및 개발하며 다양한 기술과 관련된 서적의 저자 또는 편집자이기도 하다. 최근에 출판된 책으로는 The Productive Programmer가 있다. 대규모 엔터프라이즈 애플리케이션의 설계 및 빌드에 많은 관심을 가지고 있는 그는 전세계의 개발자 컨퍼런스에서 국제적으로 인정 받고 있는 연사로도 활동하고 있다. 그의 웹 사이트를 살펴보자.

아티클 순위

의견

위로

목차

• 관용적 패턴 채취하기
• 창발적 설계 및 관용적 패턴
• 결론
• 참고자료
• 필자소개
• 의견