13. 소프트웨어 설계에 대한 이야기

건축 설계는 공간 낭비에 대한 예술이다 - Philip Johnson

나쁜 구조로 인해 심각한 악영향이 발생되었다. 통찰력과 설계가 부재한 프로젝트에는 다음과 같은 문제가 발생하기 쉽다.

-      낮은 품질의 비주기적인 제품 업데이트

-      유연하지 못한 시스템으로 어려워진 신규 기능 추가 및 변경

-      시스템 전체에 만연한 코드 수준의 문제들

-      스트레스, 사기, 이직 등 사람의 문제

-      회사 내부에 만연한 지저분하고 정치적인 문제들

-      회사에 필요한 성공의 부재

-      코드 작업에 필요한 엄청난 고뇌와 야근

 

좋은 프로젝트를 이끌어 가기 위해선 어떤 점을 유의해야 하는가?

시스템 구조에 대한 명확한 비전을 처음부터 가지고 있어야 한다.

그래야만 새로운 기능 단위들을 코드베이스상의 정확한 기능 영역에 일관되게 추가할 수 있다.

그렇게 되면 코드가 어디에 있는지에 대한 질문은 필요 없어진다.

 

시스템 전반의 일관성이 필요하다.

모든 수준에서의 모든 결정을 전체 설계의 관점에서 수행해야 한다,

명확한 구조 설계를 통해 일관된 시스템을 구성할 수 있다. 모든 설계 결정은 전체 구조 설계의 관점에서 수행해야 한다.

 

올바르게 설계되어 진행된 프로그램은 구조의 확장에 용이하다.

소프트웨어 구조는 불변의 것이 아니다. 필요하다면 변경하자. 변경 가능하게 만들려면 구조를 간결하게 유지 해야한다. 간결성을 빼앗는 변화에는 저항해야 한다.

 

설계 관련 결정 연기하기

발생할 수 있는 가장 나쁜 상황 중 하나는 아직 모르는 것을 설계하는 경우다. YANGI원칙에 따르면 문제가 정확히 무엇이고 이를 설계에 어떻게 반영해야 하는지 알 때까지 결정을 미뤄야 한다. 추측을 토대로 작업하지 않아야 하고 설계를 정확히 해야 한다.

처음 만드는 시점부터 소프트웨어 설계에 필요할 것으로 예상되는 모든 요소를 추가하는 것은 위험한 일이다. 이는 주방 하수구의 경우와 다르지 않다. 추가 사항을 포함하는 설계 작업은 결국 노력의 낭비가 될 것이고, 이런 추가 사항은 소프트웨어를 유지 보수할 때 짐이 될 것이다. 점점 더 많은 비용이 들어가고 이는 프로젝트가 끝날 때까지 지속된다.

 

품질의 유지가 중요하다.

페어프로그래밍, 이 외의 코드나, 설계에 대한 리뷰 작성되는 모든 코드에 대한 유닛 테스트

이런 부분은 다소 가혹해 보일 수 있지만, 이것들이 지속 된다면 개발자들은 설계를 믿게 되며 반드시 보호해야 한다고 느낄 것이다.

 

기술 부채 관리

임시방편 처리를 기술 부채로 표시해 두었다가 이후 버전에서 수정하도록 했다. 겉으로 드러난 표시들을 처리하기 전까지 개발자들은 기분이 찜찜 할 수 밖에 없었으나, 설계 품질에 대해 책임감을 가지고 있음을 다시 확인해 볼 수 있다.

 

설계 방향을 잡는 테스트

- 핵심적 결정 사항 중 하나는 코드는 유닛 테스트를 거쳐야 하고 시스템은 통합 테스트와 인수 테스트를 거쳐야 한다는 것이다. 많은 이점 중 하나는 다른 어떤 것도 망가뜨릴 걱정 없이 소프트웨어를 변경할 수 있다는 점이다.

- 훌륭한 자동화 테스트를 시스템에 적용하면 최소한의 위험만으로 근본적인 구조 변경을 수행할 수 있다. 이는 작업에 여유를 보장해 준다.

코드 설계에 있어 훌륭한 윤곽을 그려준다는 점이 있다.

- 각각의 작은 코드 요소는 잘 정의된 독립체로 고안 하였는데, 시스템의 나머지 요소 없이도 유닛 테스트를 통과할 수 있어야 했기 때문이다. - 유닛 테스트를 작성함으로써, 각 모듈이 내부적으로는 응집도가 높으면서도 시스템의 나머지 부분과는 결합도가 낮도록 만들 수 있다. 유닛 테스트에 따라 가 단위의 인터페이스를 신중하게 설계해야 하고, API는 유의미하면서도 내부적으로 일관되도록 설계해야 한다.

 

소프트웨어 구조는 코드베이스를 비롯해 그 주변의 건전도를 포함한 거의 모든 것에 영향을 미친다. 좋은 소프트웨어 구조는 프로젝트 참여자 들에게도 번영과 성공을 가져올 수 있다.

다음과 같은 점을 유의하여 훌륭한 소프트웨어를 설계해 보자.

- 코드 작성에 앞서 계획적으로 설계하기 : 많은 프로젝트가 일을 시작하기도 전에 이 과정에서 실패한다. 적절한 긴장감이 필요하다. 더도 덜도 말고 알맞게 설계하자.

-설계자들의 역량과 경험 : 약간의 실수를 미리 경험 해두면 이후 적절한 결정을 내릴 수 있다.

- 개발 진행에 맞춰 설계를 명확하게 유지하기

- 소프트웨어의 전체 설계에 대한 책임감을 팀 단위로 모두에게 지우기

- 설계 변경을 두려워하지 않기

- 적절한 구성원으로 팀 짜기 : 여기에는 디자이너와 프로그래머, 관리자도 포함된다. 적절한 크기의 개발팀이 상호 건전한 업무 관계를 유지하도록 하자. 건전한 업무 관계는 코드 구조에 영향을 미친다.

- 적절한 시점에 설계에 대해 결정하기 : 기능을 구현하기 위한 모든 정보를 확보 시점에서 설계하되 아직 만들 수 없다면 설계에 대한 결정 미루기

- 적절한 프로젝트 관리와 적절한 일정