애자일 설계

애자일 설계

- 애자일 설계란 무엇인가? -

애자일 설계는 과정이지 ,결과가 아니다.

이것은 원칙, 패턴, 그리고 소프트웨어의 구조와 가독성을 향상하기 위한 방식의 연속적인 적용이다.

모든 시점에서 스세템의 설계를 가능한 한 간단하고, 명료하고, 표현적으로 유지하려는 노력이다.

- 잘못된 설계의 증상 -

1. 경직성(Rigidity) : 설계를 변경하기 어려움

한줄 요약 : 시스템을 변경하기 어렵다. 변경을 하려면 시스템의 다른 부분들까지 많이 변경해야 하기 때문이다.

경직성은 단순한 방법으로도 소프트웨어를 변경하기 어려운 경향을 말한다.

한 군데의 변경이 의존적인 모듈에서 단계적으로 계속 변경을 불러일으킬 때, 그 설계는 융통성이 없는 것이다.

변경해야 하는 모듈이 많아질수록, 설계는 더 융통성이 없어진다.

대부분의 개발자는 어떤 방식으로든 이런 상황에 맞닥뜨린다.

간단한 것처럼 보이는 변경을 요청받아 그 변경사항을 검토하고 필요한 작업량을 합리적으로 추정하지만,

실제로 그 변경작업을 하면서 자신이 예상하지 못했던 변경의 간접적 영향이 있다는 사실을 깨닫게 된다.

처음에 추정했던 것보다 훨씬 많은 모듈을 수정하면서, 자신이 엄청난 양의 코드에서 변경할 부분을 쫒아다니고 있음을 깨닫게 된다.

결국, 변경작업은 처음 추정했던 것보다 훨신 오래 걸리게 된다.

왜 작업량 추정이 그렇게 형편없었느냐는 질문을 받게 되면, 다음과 같은 전통적인 소프트웨어 개발자의 한탄을 반복한다.

생각했던 것보다 훨씬 복잡하군!

2. 취역성(Fragulity) : 설계가 망가지기 쉬움

한줄 요약 : 변경을 하면 시스템에서 그부분과 개념적으로 아무런 관련이 없는 부분이 망가진다.

취약성은 한군데를 변경했을 때 프로그램의 많은 부분이 잘못되는 경향을 말한다.

대부분의 경우 새로운 문제는 변경한 영역과 개념적으로 아무런 관계가 없는 영역에서 발생한다.

따라서 이 문제를 고치려다 보면 한층 더 많은 문제로 이어지고, 개발 팀은 개가 자기 꼬리를 쫒는 것과 같은 일을 시작헤게 된다.

어떤 모듈의 취약이 심해질수로그 어떤 부분의 변경이 예상하지 못한 문제를 불러일으킬 가능성은 점점 더 확실해 진다.

얼핏 보기에는 참으로 어이없는 일이나, 실제로는 이런 모듈이 흔하다.

이렇게 끊임없이 수리를 요구하는 모듈로는, 버그 목록에서 절대 내려가지 않는 것, 

개발자가 재설계의 필요성을 인식하고 있는 것, 고칠수록 점점 나빠지는 것이 있다.

그러나 아무도 그것을 재설계하는 무서운 일을 하고 싶어하지 않는다.(ㅋㅋㅋㅋㅋㅋ)

3. 부동성(Immobility) : 설계를 재사용하기 어려움

한줄 요약 : 시스템을 다른 시스템에서 재사용할 수 있는 컴포넌트로 구분하기가 어렵다.

다른 시스템에서 유용하게 쓸 수 있는 부분을 포함하고 있지만, 

그런 부분을 원래 시스템에서 분리하는 수고와 위험성이 지나치게 클 때 설계는 움직이게 할 수 없다.

유감스럽게도 상당히 흔하게 일어나는 일이다.

4. 점착성(Viscosity) : 제대로 동작하기 어려움

한줄 요약 : 옳은 동작을 하는 것이 잘못된 동작을 하는 것보다 더 어렵다.

점착성은 소프트웨어의 점착성과 환경의 점착성이라는 두 가지 형태로 나타난다.

변경사항을 마주했을 때, 개발자는 보통 그 변경을 수행하는 한 가지 이상의 방법을 찾는다.

그중 일부는 설계를 유지하는 방법이고, 나머지는 그렇지 않다(즉, 엉터리 방법이다).

설계유지 방법이 엉터리 방법보다 사용하기 어렵다면, 설계의 점착성은 높아진다.

이 경우 잘못된 동작을 하기는 쉽지만, 옳은 동작을 하기는 어렵다.

프로그래머는 설계를 유지할 수 있도록 변경이 쉬운 소프트웨어를 설계하고 싶어한다.

환경의 점착성은 개발 환경이 느리고 비효율적일 때 발생한다.

예를 들어, 컴파일 시간이 아주 길다면 개발자는 많은 양의 재컴파일을 필요로 하지 않는 방식으로 변경하고 싶은 유혹을 느낄 것이다.

이런 변경이 설계를 유지시키지 않더라도 말이다.

만약 소스 코드 관리 시스템이 몇몇 파일을 체크인하는 데도 많은 시간을 필요로 한다면

개발자는 가능한 한 적은 체크인만을 필요로 하는 방식으로 변경하고 싶은 유혹을 느낄 것이다.

설계가 유지되는지의 여부는 무시하고 말이다.

5. 불필요한 복잡성(Needless Complexity) : 과도한 설계

한줄 요약 : 직접적인 효용이 전혀 없는 기반구조가 설계에 포함되어 있다.

현재 시점에서는 유용하지 않은 요소가 설계에 포함되어 있다면, 이 설계는 불필요한 복잡성을 포함하는 것이다.

이런 일은 개발자가 요구사항에 대한 변경을 미리 예상하고, 

잠재적인 변경을 처리하기 위해 소프트웨어에 기능을 집어넣을 때 자주 발생한다.

처음에는 이런것이 바람직해 보일 수도 있다.

어쨋든 미래의 변경에 대비하면 코드가 유연해지고, 나중의 악몽과도 같은 변경 작업을 방지해 줄것이다.

그러나 유감스럽게도 효과가 정반대로 나타나는 경우가 종종있다.

앞으로 일어날지도 모르는 일을 과도하게 준비함으로써, 설계는 절대 사용되자 않는 구성 요소들로 어지러워진다.

이런 준비 중 일부는 성과를 거둘 수 있겠지만, 성과를 거두지 못하는 경우가 더 많다.

그동안 설계는 이런사용되지 않는 설계 요소들의 부담을 감당해야 하며, 그로 인해 소프트웨어는 복잡하고 이해하기 어려워진다.

6. 불필요한 반복(Needless Repetition) : 마우스 남용

한줄 요약 : 단일 추상 개념으로 통합할 수 있는 반복적인 구조가 설계에 포함되어 있다.

잘라내기와 붙이기는 쓸모있는 텍스트 편집 작업이 될 수도 있겠지만, 피해가 막심한 코드 편집 작업이 될 수도 있다.

너무나도 흔하게, 소프트웨어 시스템은 몇십, 몇백 개의 반복된 코드 요소로 구성된다.

이런일은 다음과 같이 일어난다.

웹서버에 요청을 하는 코드를 작성하려고 한다.

그는 웹서버에 요청이 일어났다고 생각되는 코드의 다른 부분을 살펴보고 적당한 코드 구간을 발견한다.

그 코드를 잘라내고 그의 모듈에 붙인뒤, 적당한 수정을 가한다.(몇 일 전 했던 실수...ㅠ)

또 다른 사람이 웹세버 요청이 필요해 작성되어 있는 코드를 복붙후 필요한 만큼 수정을 가한다.

같은 코드가 조금씩 다른 형태로 계속 반복되어 나타나면서, 개발자는 추상화된 개념을 일게된다.

반복된 부분을 찾아내고 적절한 추상화를 통해 이를 없애는 일은 개발자에게 있어 우선순이가 그리 높진 않겠지만,

이런일은 시스템을 이해하고 유지보수하기 쉽게 만드는데 큰 도움이 된다.

시스템에 반복되는 코드가 존재할 때, 시스템을 변경하는 일은 고될 수 있다.

이런 반복되는 단위에서 발견된 버그는 모든 반복 부분에서 고쳐져야 한다.

하지만 이런 반복 부분은 전부 조금씩 다르기 때문에, 고치는 작업도 항상 똑같지 않다.

7. 불투명성(Opacity) : 혼란스러운 표현

한줄 요약 : 읽고 이해하기 어렵다. 그 의도를 잘표현하지 못한다.

불투명성은 모듈을 이해하기 어려운 경향을 말한다.

코드는 명료하고 표현적인 방식으로 작성될 수도 있고, 불명료하고 뒤얽힌 방식으로 작성될 수도 있다.

시간이 지남에 따라 발전하는 코드는 시간이 지날수록 점점 더 불명료해지는 경향이 있다.

불투명성을 최소로 유지하기 위해서는 코드를 명료하고 표현적으로 유지하려는 지속적인 노력이 필요하다.

개발자가 처음으로 모듈을 작성할 때 는 코드가 명료해 보일 수도 있다.

이것은 개발자가 코드에 몰두하고 친밀한 수준에서 그것을 이애하기 때문이다. 시간이 지나 친밀함이 사리지고 나면,

그 모듈을 돌아보고 어떻게 자신이 이런 끔찍한 것을 작성할 수 있었는지 의아해할지도 모른다.

이런일을 방지하기 위해, 개발자는 읽는 사람의 입장에서 생각하고 자산의 코드를 리팩토링하기 위해 노력해야 한다.

또한 다른 사람이 자산의 코드를 컴토하도록 할 필요가 있다.

- 원칙 -

- SRP : 단일 책임 원칙(Single Responsibility Principle)

- OCP : 개방 폐쇄 원칙(Open-Closed Principle)

- LSP : 리스코프 치환 원칙(Liskov Substitution Principle)

- DIP : 의존 관계 역전 원칙(Dependency Inversion Principle)

- ISP : 인터페이스 분리 원칙(Interface Segregation Principle)

이 원칙들은 소프트웨어 공학 분야에서 수십년간의 경험으로 힘들게 얻은 산소이다.

어느한 학자가 만들어낸 것이 아니라, 수많은 소프트웨어 개발자와 연구자의 고찰과 저술의 집합체인 것이다.

  

- 악취와 원칙

설계의 악취는 하나의 증상이고, 객관적으로 는 아닐지라도 주관적으로는 측정할 수 있다.

대개 이런 악취는 하나 이상의 원칙을 위반했을 때 발생한다.

예를 들어, 경직성의 악취는 많은 경우 개방 폐쇄 원칙(OCP)에 충분히 주의를 기울이지 않았기 때문에 발생한다.