애자일 팀에서, 큰 그림은 소프트웨어와 함께 발전한다. 각 반복에서 팀은 시스템의 설계를 개 선해 지금 그대로도 충분히 가능한 한 제일 좋은 시스템이 되도록 한다. 나중의 요구사항과 필요에 대해서는 그리 오래 생각하지 않는다. 그리고 내일 필요해질 것이라고 생각하는 기능 을 지원하기 위해 오늘 기반구조(infrastructure)를 짜 맞추려 하지도 않는다. 그보다는，현재 구조에 초점을 두고 더욱 개선하기 위해 노력한다. p.108
애자일 설계에 대한 요약이라고 볼 수 있다. 기반구조를 만들어 놓고 기능을 추가하는 방식이 아니다. 나중에 수고가 더 많이 드는 것이 아닌가 하는 의문이 든다.
잘못된 설계의 증상
- 경직성(Rigidity): 설계를 변경하기 어려움
- 취약성(Fragility): 설계가 망가지기 쉬움. 한 군데 변경 -> 많은 부분이 잘못되는 경향
- 부동성(Immobility): 설계를 재사용하기 어려움. 다른 시스템에서 유용하게 쓸 수 있는 부분이 있지만 분리하기 어려움.
- 점착성(Viscosity): 제대로 동작하기 어려움. [소프트웨어 점착성] 변경이 필요할 때 설계를 유지하지 않는 방식이 더 쉬운 경우. [환경의 점착성] 개발 환경 느리고 비효율적인 경우.
- 불필요한 복잡성(Needless Complexity): 과도한 설계. 현재 시점에서 유용하지 않은 요소가 포함됨.
- 불필요한 반복(Needless Repetition): 마우스 남용. 같은 코드가 조금씩 다른 형태로 계속 반복되어 나타나면서, 개발자는 추상화된 개념을 잃게 된다.
- 불투명성(Opacity): 혼란스러운 표현
이 착취는 코드의 작은 부분이 아니라 소프트웨어의 전체 구조로 고루 퍼져 나간다.
원칙
위의 증상들을 완화시켜주는 원칙들
- SRP: 단일 책임 원칙
- OCP: 개발 폐쇄 원칙
- LSP: 리스코프 치환 원칙
- DIP: 의존 관계 역전 원칙
- ISP: 인터페이스 분리 원칙
악취와 원칙
아무 악취도 나지 않을 때는 원칙을 적용하지 않는다. p.109
Chapter7. 애자일 설계란 무엇인가?
“소프트웨어 개발생명주기를 검토한후, 공학 설계의 기준을 실제로 만족시킬 유일한 소프트웨어 문서는 소스 코드 목록뿐임을 알 수 있었다.” 잭 리브스(Jack Reeves)
결국，소스 코드가 바로 설계다.
소프트웨어에서 어떤 것이 잘못되는가?
기존 시스 템은 계속 발전하고 변경되며, 새로운 설계는 그것을 쫓아가야 한다. 새로운 설계가 첫 번째 릴리즈에 이르기도 전에 혹과 궤양이 새로운 설계에 생기는 셈이다.
어떻게 보면 아무리 노력해도 언제나 새로운 레거시가 만들어지는 셈이다.
무엇이 소프트웨어 부패를 촉진하는가?
변경에 대해서도 탄력적인 설계를 만드는 방 식을 찾아야 하고, 그것이 부패하지 않도록 보호할 수 있는 방식을 사용해야 한다.
애자일 팀은 소프트웨어가 부패하도록 내버려두지 않는다
시스템의 설계를 가능한 한 명료하고 단순하게 유지하고, 이것을 많은 단위 테스트와 인수 테스트로 뒷받침한다. 이런 작업을 통해 설계를 유연하고 변경하기 쉬운 것으로 유지할 수 있다.
테스트가 설계의 유연함을 돕는다고 한다. 리팩토링할 때 자신감을 심어주기 때문인 것으로 생각된다. 반면 경험이 없는 나는 테스트 코드가 있을 때 테스트 코드를 신경써야 하기 떄문에 쉽다는 느낌은 들지 않았다. 좀 더 경험을 쌓아봐야겠다.