더 심층적인 통찰을 위한 리팩터링

조각들을 하나로 모으기

깊은 통찰로의 리팩토링은 다면적인 과정입니다. 잠시 멈춰서 주요 포인트를 함께 모아 보는 것이 유익할 것입니다. 세 가지에 집중해야 합니다: 도메인에 살기, 다른 방식으로 계속 바라보기, 도메인 전문가와 끊임없는 대화를 유지하기. 이는 리팩토링 과정에 더 넓은 맥락을 제공합니다.

고전적인 리팩토링 설명은 개발자가 코드에서 개선할 수 있는 부분을 인식하고 바로 수정하는 모습입니다

시작

전통적인 리팩토링 관점과 달리, 코드가 깔끔해 보일 때도 동일한 인식이 올 수 있습니다. 모델의 언어가 도메인 전문가와 단절되어 보이거나 새로운 요구 사항이 자연스럽게 맞지 않는 경우가 그렇습니다. 이는 개발자가 이해가 깊어지면서 더 명확하거나 유용한 모델을 볼 수 있는 기회로 이어질 수 있습니다.

문제점을 인식하는 것은 종종 가장 어렵고 불확실한 부분입니다. 그 이후에는 개발자가 새로운 모델의 요소를 체계적으로 찾아낼 수 있습니다. 동료 및 도메인 전문가와 브레인스토밍할 수 있습니다. 분석 패턴이나 설계 패턴과 같은 체계화된 지식을 활용할 수 있습니다.

탐색 팀

불만의 원천이 무엇이든, 다음 단계는 명확하고 자연스럽게 소통할 수 있는 모델 개선을 찾는 것입니다. 이는 즉시 명백하고 몇 시간 내에 완료할 수 있는 소소한 변경일 수 있습니다.

변경의 주도자는 해당 문제를 해결할 수 있는 능력이 좋은 두세 명의 개발자를 선택합니다. 도메인의 해당 영역을 잘 알고 있거나 강력한 모델링 기술을 가진 사람들입니다.

이 과정을 생산적으로 유지하기 위한 몇 가지 핵심 요소가 있습니다.

• 자기 결정: 소규모 팀이 즉석에서 결성되어 설계 문제를 탐구할 수 있습니다. 팀은 며칠 동안 운영되고 해산될 수 있습니다. 장기적인 복잡한 조직 구조가 필요 없습니다.

• 범위와 휴식: 며칠에 걸쳐 두세 번의 짧은 회의로 시도해 볼 만한 설계를 도출할 수 있습니다. 너무 오래 끌면 도움이 되지 않습니다. 막히면 한 번에 너무 많은 것을 시도하고 있을 수 있습니다. 설계의 더 작은 측면을 선택하고 그것에 집중하십시오.

• 유비쿼터스 언어 사용: 다른 개발자와 특히 주제 전문가의 참여는 유비쿼터스 언어를 사용하고 정제하는 기회를 제공합니다. 노력의 최종 결과는 코드에서 공식화될 언어의 정제입니다.

앞의 장에서는 개발자와 도메인 전문가가 더 나은 모델을 찾기 위해 탐구하는 여러 대화를 보여주었습니다. 완전한 브레인스토밍 세션은 역동적이고 구조화되지 않았으며 매우 생산적입니다.

기존의 자료 활용

항상 새로운 것을 발명할 필요는 없습니다. 누락된 개념과 더 나은 모델을 위한 브레인스토밍 과정은 다양한 출처의 아이디어를 흡수하고, 로컬 지식과 결합하여 답을 찾는 데 큰 용량을 가지고 있습니다.

도메인 자체에 관한 책과 다른 자료에서 아이디어를 얻을 수 있습니다. 현장의 사람들이 소프트웨어를 실행하기에 적합한 모델을 만들지 않았더라도, 개념을 조직하고 유용한 추상화를 발견했을 가능성이 큽니다. 이러한 지식을 공급하면 더 풍부하고 빠른 결과를 얻을 수 있으며, 도메인 전문가에게 더 친숙하게 보일 가능성이 큽니다.

조각들을 맞추는 동안 모델 문제와 설계 문제를 병행하여 처리해야 합니다. 다시 말해, 모든 것을 처음부터 발명할 필요는 없습니다. 설계 패턴은 구현 요구와 모델 개념 모두에 적합할 때 도메인 계층에서 종종 사용될 수 있습니다.

마찬가지로, 산술이나 술어 논리와 같은 일반적인 형식이 도메인의 일부에 맞는 경우, 해당 부분을 분리하고 형식 시스템의 규칙을 적용할 수 있습니다. 이는 매우 긴밀하고 쉽게 이해할 수 있는 모델을 제공합니다.

개발자를 위한 설계

소프트웨어는 사용자만을 위한 것이 아닙니다. 개발자를 위한 것이기도 합니다. 개발자는 코드를 시스템의 다른 부분과 통합해야 합니다. 리팩토링 과정에서 개발자는 코드를 계속 변경합니다. 깊은 통찰로의 리팩토링은 유연한 설계를 이끌어 내고, 그로부터 이득을 얻습니다.

유연한 설계는 의도를 전달합니다. 코드를 실행했을 때의 효과를 예측하기 쉬우며, 따라서 변경의 결과를 예측하기 쉽습니다. 이는 주로 종속성과 부작용을 줄임으로써 정신적 과부하를 제한하는 데 도움이 됩니다. 이는 도메인의 깊은 모델을 기반으로 하며, 사용자에게 가장 중요한 부분에서만 세밀합니다. 이는 변화가 가장 흔한 부분에서의 유연성과 다른 곳의 단순성을 제공합니다.

시기

변경에 대한 완전한 정당성을 만들 때까지 기다리면 너무 늦습니다. 프로젝트는 이미 높은 비용을 초래하고 있으며, 변경이 더 복잡하고 다른 코드에 내장될 가능성이 높습니다.

지속적인 리팩토링은 "최고의 관행"으로 간주되었지만, 대부분의 프로젝트는 여전히 이에 대해 너무 신중합니다. 그들은 코드 변경의 위험과 변경 비용을 보고, 어색한 설계를 유지하는 위험과 그 설계를 우회하는 비용은 사전에 보기 어렵습니다. 리팩토링을 원하는 개발자는 종종 결정을 정당화해야 합니다.

이것이 합리적으로 보이지만, 이미 어려운 일을 불가능하게 만들고 리팩토링을 억제하는 경향이 있습니다(또는 비밀리에 진행됩니다). 소프트웨어 개발은 변경의 이점이나 변경하지 않는 비용을 정확하게 계산할 수 있는 예측 가능한 프로세스가 아닙니다.

깊은 통찰로의 리팩토링은 도메인의 주제를 지속적으로 탐구하고, 개발자를 교육하며, 개발자와 도메인 전문가의 의견을 일치시키는 과정의 일부가 될 수 있습니다. 따라서 다음과 같은 경우 리팩토링하십시오.

• 설계가 팀의 현재 도메인 이해를 표현하지 않을 때

• 중요한 개념이 설계에서 암묵적으로 존재할 때(이를 명시적으로 만들 수 있는 방법을 찾을 때)

• 설계의 중요한 부분을 더 유연하게 만들 수 있는 기회를 볼 때

위기를 기회로

고전적인 리팩토링 설명은 매우 꾸준한 것처럼 들립니다. 깊은 통찰로의 리팩토링은 보통 그렇지 않습니다. 모델의 꾸준한 개선 기간은 갑자기 모든 것을 뒤흔드는 통찰로 이어질 수 있습니다. 이러한 돌파구는 매일 일어나지는 않지만, 깊은 모델과 유연한 설계를 이끄는 변화 중 상당 부분은 이러한 돌파구에서 나옵니다.

이러한 상황은 종종 기회처럼 보이지 않으며, 위기처럼 보일 수 있습니다. 갑자기 모델에 명백한 부적절함이 있습니다. 표현할 수 있는 것이 크게 부족하거나, 어떤 중요한 영역이 불투명하거나, 모델이 단순히 잘못된 진술을 할 수 있습니다.

이는 팀이 새로운 이해 수준에 도달했음을 의미합니다. 이제 상승된 관점에서 옛 모델이 빈약해 보입니다. 그 관점에서 훨씬 더 나은 모델을 구상할 수 있습니다.

깊은 통찰로의 리팩토링은 지속적인 과정입니다. 암묵적인 개념이 인식되고 명시적으로 만들어집니다. 설계의 일부가 유연해지며, 선언적 스타일을 취할 수 있습니다. 개발은 갑자기 돌파구의 직전에 이르고, 깊은 모델로 돌파구를 넘어서며, 그런 다음 다시 꾸준한 개선이 시작됩니다.