2021-02-09(Tue)

항목	내용
학습 날짜	2021-02-09(화)
학습 시간	11:00~24:00
학습 범위 및 주제	Websocket, Rails Active Record, Backbone
학습 목표	Appearance view 구현을 완료한다.
동료 학습 방법	jujeong, sanam과 페어프로그래밍을 진행

상세 학습 내용

Rails 테크닉 한토막

Rails Active Record에서 여러 속성 조건으로 한번에 검색하기를 통해 Active Record에서 좀 더 간략하게 쿼리를 날릴 수 있음을 알게되어 써먹었다. 구체적으로 예를 들자면

chat_ban = ChatBan.where(user_id: params[:user_id]).find_by_banned_user_id(params[:banned_user_id])

위처럼 쓸데없이 복잡한 쿼리를 아래처럼 바꿀 수 있다는 것.

chat_ban = ChatBan.find_by_user_id_and_banned_user_id(params[:user_id], params[:banned_user_id])

한편 where에는 해쉬를 넘길 수 있다. 덕분에 검색 조건을 아래처럼 줄여버릴 수 있다.

# chat_ban = ChatBan.where(Hash[*params])

아래는 책 루비로 배우는 객체지향 디자인을 읽고 적은 간략한 메모다.

2장 단일 책임 원칙을 따르는 클래스 디자인하기

단일 책임 원칙은 왜 중요한가

한 개 이상의 책임이 있는 클래스는 재사용이 어렵기 때문이다. 이 클래스 속에서 여러 책임들은 서로 얽혀 있을 가능성이 높다. 때문에 쉽게 가져다 쓸 수 없다.

반면 단일 책임 클래스는 하나의 책임만 가지고 있기 때문에 쉽게 가져다 쓸 수 있는 코드(pluggable units)다.

클래스에 단일 책임만 있는지 어떻게 알 수 있을까

• 클래스는 단순해야한다는 말을 명심하자. 클래스는 최대한 작으면서도 유용한 것만 행해야 한다.

• 클래스의 책임을 한 문장으로 만들어보자 .이 때 '그리고'라는 단어가 포함된다면 이 클래스는 하나 이상의 책임을 가지고 있을 가능성이 높다. 만약 '또는' 이라는 단어를 사용한다면 클래스는 서로 연관되지도 않은 둘 이상의 책임을 가지고 있다는 뜻이다.

변화를 받아들일 수 있는 코드 작성하기

몇가지 방법이 있다.

• 데이터가 아니라 행동에 기반한 코드를 작성하자. 데이터에 직접 접근하지말고 필요한 getter/setter를 이용해서 접근하자

• 모든 곳에 단일 책임원칙을 강제하자

  • A 객체에서 책임을 분리하면서 분리된 책임을 가질 B 객체를 만들어야하는지 확신이 들지 않을 수 있다. 이 경우엔 block을 이용해서 선택을 유보할 수 있다.

    class Gear
      attr_reader :chainring, :cog, :wheel
      def initialize(chainring, cog, rim, tire)
        @chiainring = chainring
        @cog = cog
        @wheel = Wheel.new(rim, tire)
      end
      
      def ratio
        chainring / cog.to_f
      end
      
      def gear_inches
        ratio * wheel.diameter
      end
      
      Wheel = Struct.new(:rim, :tire) do
        def diameter
          rim + (tire * 2)
        end
      end
    end

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

이것저것 한게 많아도 하루 종일 코딩하고 나면 진이 빠져서 기록으로 남기기 어렵다. 특히나 오늘은 타 모듈의 PR을 Review하고 테스트하는데 시간을 대부분 활용했다보니 기록이 애매하다.

하루 종일 코딩하며 쌓이는 지식과 깨달음들을 좀 더 적극적으로 글로 남길 수 잇도록 노력해야지..

다음 학습 계획

• Appearance view 구현완료