2021-02-07(Sun)

항목	내용
학습 날짜	2021-02-07(일)
학습 시간	11:00~24:00
학습 범위 및 주제	객체지향
학습 목표	루비로 객체지향 코드를 만드는 감을 익힌다.
동료 학습 방법	-

상세 학습 내용

협업이라면 더더욱 테스트에 기반한 코드구현을 해야한다고 믿는데, 이번 프로젝트에서는 테스트 코드다운 테스트코드를 만들어내지 못한 느낌이다. 이런 고민을 저격하는 책이 있었으니- 바로 '루비로 배우는 객체지향 디자인-지속가능한 소프트웨어를 만드는 방법'이라는 책이다.

책 '객체지향의 사실과 오해'을 읽으며 알게된 관념들을 좀 더 프로젝트에 잘 적용할 수 있기를 바라며 책을 폈다. 하단은 책 '루비로 배우는 객체지향 디자인-지속가능한 소프트웨어를 만드는 방법'을 학습하며 적은 메모.

1장 객체지향 디자인

절차지향 소프트웨어는 이 세계를 정해진 절차들의 묶음으로 생각한다. 반면 객체지향 소프트웨어는 이 세계를 객체 사이의 자발적인 상호연관의 연속으로 파악한다. 이 관점의 차이가 객체지향 디자인이 유연하도록 만들어준다.

객체 지향 디자인이란

소프트웨어 유지보수 문제

• 요구사항 변경은 무조건 발생한다.

• 애플리케이션의 변경과 확장이 용이하지 않다면 이런 요구사항을 충족시키기 어렵다.

어떤 경우에 수정이 어려운가?

• 객체 간의 상호작용은 객체가 주고받는 메시지 속에 녹아 있다.

• 올바른 객체에게 올바른 메시지를 보내기 위해서는 메시지를 보내는 객체가 메시지를 수신하는 객체에 대한 지식을 어느정도 가지고 있어야한다.

• 이런 지식은 의존성이 되어 애플리케이션 수정을 어렵게 한다. 지금은 수정이 쉽더라도 언젠가는 수정이 어려워진다.

그래서 객체 지향 디자인이 뭔데?

• 객체지향 디자인은 의존성을 관리하는 것이고, 객체가 변화를 받아들일 수 있도록 의존성을 정리하는 코딩 기술의 묶음이다. 이 모든 것은 변화의 비용을 최소화하기 위한 목표를 반영한 것이다.

• 객체지향 디자인은 특수한 요구사항의 변화를 미리 예측하는 것이 아니다. 그저 언젠가 무언가는 변한다는 사실을 받아들이고, 지금은 무엇이 변경될지 알 수 없다는 사실을 받아들이는 것이다. 따라서 미래를 섣불리 추측해서 구현을 선택하지 않는다. 그저 미래를 대비해서 가능한 선택지를 여러 가지 만들어 놓고 변화하고 움직일 수 있는 공간을 남겨 놓을 뿐이다.

• 디자인은 정해진 법칙을 따르는 활동은 아니다. 대신 원칙과 패턴이라는 도구에 따라 요구사항을 구현하기 위한 선택을 반복하며 지금의 판단의 대가를 뒤로 미루는 활동을 끝없이 하는 것이다.

  • 객체지향의 원칙들: 유명한 건 SOLID 원칙과 데메테르의 원칙 등이 있다.

  • 객체지향의 디자인 패턴들: GoF의 디자인 패턴 등등

디자인은 언제 실패하는가?

• 디자인 자체가 부족할 때

• 디자인을 오용할 때

• 디자인 작업과 프로그래밍 작업이 동떨어져 있을 때

  • 이를 막기 위해 애자일하게 디자인과 구현을 반복할 필요가 있다. 그래야 디자인이 '적절한 자기조절 능력'을 가지게 된다.

  • 애자일이 '커다란 디자인을 먼저 구상하지 말라'고 한다고 해서 디자인을 하지 말라고 하는 것은 아니다. 오히려 애자일 작업방식은 변화를 보장하므로, 진짜 좋은 디자인을 통해 코드를 배치해서 쉽게 변경할 수 있도록 만드는 것이 중요하다.

학습 내용에 대한 개인적인 총평

오늘은 프로젝트 세부모듈 구현에서 벗어나서 전체 프로젝트 방향을 잡는데 도움이 될 법한 학습을 진행하기로 마음 먹었다. Backbone의 collection과 model 사용법을 좀 탐구해볼까 싶기도 했는데 기껏 학습한 객체지향 개념을 프로젝트에 잘 녹여내고 있는 것 같지 않아서 객체지향에 대해서 파보았다. Appearance channel을 이용을 위한 인터페이스를 생성하는데 참고해야지.

다음 학습 계획

• Appearance view 구현완료