[클린 소프트웨어] chapter 7. 애자일 설계란 무엇인가?

시작하며

이번 장은 시스템을 설계하는 과정에서 갖춰야할 것들에 대해 설명하고 있다. 시스템을 완성하는 것도 중요하지만, 코드가 점점 유지보수하기 어려워지면 재설계(renewal)를 필요로 하기 때문에, 이를 설계 단계에서 방지해야 한다.

설계의 악취: 부패하고 있는 소프트웨어의 냄새

• 경직성(Rigidity): 다른 부분까지 많이 변경해야하기 때문에 단순한 방법으로 변경이 어렵다. (코드가 의존적인 경우, 한 부분을 변경하려고 하면 얽혀있는 다른 부분까지 변경해야하기 때문에 번거로움)
• 취약성(Fragility): 시스템이 취약할 경우, 변경 했을 때 아무런 관련이 없는 부분까지 망가지기 쉽다.
• 부동성(Immobility): 설계를 재사용하기 어렵기 때문에, 재사용 가능한 컴포넌트로 구분하기 어렵다.
• 점착성(Viscosity): 제대로 동작하기 어렵다. 점착성이 있는 프로젝트는 설계를 유지하기 어렵다.
• 불필요한 복잡성(Needless Complexity): 과도한 설계 또는 유용하지 않은 기반구조가 포함되어있다. (미래에 일어날 일들을 과도하게 준비함)
• 불필요한 반복(Needless Repetition): 반복적인 구조가 설계에 포함되어있다. 반복된 부분을 찾아내서 적절한 추상화를 통해 이를 없애면 시스템을 유지보수 하기 쉬워진다.
• 불투명성(Opacity): 혼란스러운 표현을 지양해야 한다. 코드를 읽고 이해하기 어렵다. 다른 사람이 보았을 때 한눈에 이해하기 쉬운 표현을 사용하는 것이 좋다.

무엇이 소프트웨어의 부패를 촉진하는가?

우리는 때때로 예상하지 않았던 요구사항의 변경을 해결하기 위해 설계를 변경하게 된다. 하지만 요구사항 때문에 설계가 실패한다면 우리의 설계 방식에 문제가 있는 것이다. 그렇기 때문에 변경에 대해서 탄력적인 설계를 만들어야 하고, 이것을 보호할 수 있는 방식을 찾아야 한다.

애자일 팀은 소프트웨어가 부패하도록 내버려두지 않는다

지속적인 리팩토링을 하는 것이 도움이 된다. 설계를 단순하게 유지하고 단위 테스트 및 인수 테스트로 뒷받침하여 설계를 유연하고 변경하기 쉬운 것으로 유지할 수 있다.

요구사항은 끊임없이 변화한다. 새로운 요구사항을 만족시키기 위해 미래에 있을 비슷한 종류의 변경에도 탄력적일 수 있도록 만든다.

→ 애자일 팀은 처음 모듈을 설계할 때 변경될 사항을 예상하지 않고 가장 간단한 방법으로 설계하였다. 또한 나중에 변경될 요구사항에 대해서는 추가적인 처리를 지금 하지 않았다. 요구사항이 변경된 다음에야 비로소 탄력적일 수 있도록 모듈의 설계를 바꾸었다.

애자일 개발자는 해야 할 일을 어떻게 알았는가?

1. 그들은 애자일 실천방법으로 문제를 찾아냈다.
   → 의존성의 방향 때문에 유연하지 않음 (현재 상위 수준의 모듈이 하위 수준의 모듈에 의존하고 있음)
2. 그들은 설계 원칙을 적용해 문제를 진단했다.
   → DIP를 적용하여 의존성을 거꾸로 뒤집어야 함
3. 그리고 그들은 적절한 디자인 패턴을 적용해 문제를 해결했다.
   → 전략(STRATEGY)패턴을 적용해 해결함

위와 같이 소프트웨어 개발의 세 측면 사이에서 일어나는 상호작용이 바로 설계 작업이다.

가능한 좋은 상태로 설계 유지하기

• 다음은 없다. 나쁜 냄새가 나면 미루지 말고 바로 개선해야한다.
• 작은 단위의 부패라도 방치하면 나중에는 감당할 수 없을 정도로 위험이 커진다.

결론

• 애자일의 설계는 과정이지, 결과가 아니다.
• 시스템의 설계를 간단하고 명료하게 유지하려는 노력이다.

마치며 ⛳️

시스템을 완성하는 것에 초점을 두지 않고, 나중에 할 유지보수까지 고려하여 어떻게 설계해야하는지 알게 되었다. 좋은 소프트웨어를 만들기 위하여 작은 문제가 발생하면 바로 고치고, 지속적인 리팩토링을 통하여 미래에 있을 변화에 탄력적일 수 있도록 관리해야겠다!