1장 설계와 아키텍처란?

설계(design)와 아키텍처(architecture)는 다음과 같은 의미로 흔히 사용된다.

  • 아키텍처(architecture) : 저수준의 세부사항과 고수준의 무언가

  • 설계(design) : 저수준의 구조 또는 결정사항

하지만 둘은 차이가 없다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 설계의 구성요소다.

목표는?

좋은 소프트웨어 설계의 목표는?

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화하는 데 있다.

설계 품질을 재는 척도는 고객의 요구사항을 만족시키는데 드는 비용을 재는 척도와 같다. 새로운 기능을 출시할 때마다 비용이 증가하면 나쁜 설계다. 반면 비용이 낮게 유지되면 좋은 설계다.

사례 연구

엔지니어 수가 상당 수 증가했지만 같은 기간의 생산성은 동일한 회사가 있다. 즉, 같은 기간에 코드 라인당 비용이 증가한것이다.

엉망진창이 되어 가는 신호

다음은 엉망진창이 되어 가는 신호다.

  • 시스템을 급하게 만듬

  • 결과물의 총량을 프로그래머 수 만으로 결정함

  • 코드와 설계의 구조를 깔끔하게 만들려는 생각을 하지 않음

이렇게 되면 개발자가 헌신함에도 불구하고 노력이 개발보단 엉망이 된 상황을 대처하는데 소모되기 때문에 진척이 없어진다.

경영자의 시각

경영자는 월별 인건비 증가 추세를 보면서 조치를 취해야 한다고 생각할 것 이다.

무엇이 잘못되었나?

현대의 대다수 개발자는 뼈 빠지게 일하면서도 깔끔하게 잘 설계된 코드가 중요하다는 사실을 잊고있다. 당장 시장에 출시하는게 중요하다는 거짓말에 속아 코드를 정리하는 일을 뒤로 미룬다. 새로운 기능은 계속 추가되고 코드는 정리되지 않아 생산성은 0을 향해 수렴한다.

제이슨 고먼은 실험을 했는데, 6일 동안 3일은 TDD를 통해 개발하고, 3일은 TDD를 하지 않고 개발했다. 실험 결과 3일 모두 TDD를 통해 개발한 날이 더 빠르게 프로그램이 완성되었다.

빨리 가는 유일한 방법은 제대로 가는 것이다.

생산성이 감소되고 비용이 증가하는 현상을 되돌릴 수 있는 유일한 방법은 만들어낸 엉망진창인 코드를 개발자가 책임지도록 하는 것뿐이다. 전체 시스템을 재설계 한다고 해소되지 않는다.

자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.

결론

개발 조직이 할 수 있는 최고의 선택지는 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.

소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

Last updated