Page tree
Skip to end of metadata
Go to start of metadata

역할 정의

RoR-2주차 스터디 피드백 - 주디

  • 역할 : 2주차 스터디 동영상을 보고 각 개인별 장, 단점을 분석해 피드백한다.
  • 스터디 내용정리

github 이슈 관리, 브랜치 관리 - 모나, 엘사

  • 역할1 : github의 이슈 관리 현황을 공유하고, 이슈 관리를 위해 지켜야할 원칙을 만들어 공유한다.

RoR 개괄 소개 및 아키텍쳐 - 각목

  • 역할 : RoR과 관련해 개발자가 알아야할 지식을 정리하고 공유한다.

RoR 테스트 방법 공유 - 호구

  • 역할 :  RoR과 관련한 테스트 방법을 공유한다.

RoR 호구의 학습곡선 이야기

  • 중-고등학교부터 대학교입학, 넥스트 생활까지의 이야기.

 

 

스터디 내용 정리

 

2번째 짝 프로그래밍 회고 (모나 / 주디)

  • 룰을 정해 놓고 짝 프로그래밍을 하는 것이 좋다.
  • 될 수도 있고 안 될 수도 있지만 해야할 것이 정해져 있기 때문에 우선 시도해 본다.

 

해야 할 것

  1. 코드 형상 관리, 브랜치 전략 등 확실하게 정하기
    1. 앞으로 어떻게 할 것인가?
    2. 역할 분담에 대해서 명확히 하기
  2. 코드 리뷰
  3. 소스코드 별 사용처( ?) - 특정 기능이 어느 부분에 들어가야 하는가
  • cf) 형상관리
  • 시스템 형상 요소의 기능적 특성이나 물리적 특성을 문서화하고 그들 특성의 변경을 관리하며, 변경의 과정이나 실현 상황을 기록·보고하여 지정된 요건이 충족되었다는 사실을 검증하는 , 또는  과정.

     http://terms.naver.com/entry.nhn?docId=861725&cid=2954&categoryId=2954

 

코드 리뷰

  • 모나 / 주디의 코드
    • 네이버 파서 제작
      • 네이버에서 파싱한 자료(가수, 제목, 앨범 등)를 이용하여 유튜브에 검색함
      • 유튜브에서 나온 결과(동영상)의 주소를 이용해서 View에 플레이어를 보여줌
      • scaffold(? )에서 네이버 파서를 만듦
        • 모델과 컨트롤러 중에서 어느 곳에 넣어야 할지 고민하였음
        • 비즈니스 로직은 모델 쪽에 넣는 것이 맞다고 생각했지만 메소드가 많아지고 정리가 안된다는 느낌을 받음
        • 하나의 객체에 URL 을 전달하고, 객체에 물어보는 식을 처리
        • 클래스를 새로 나눠서 네이버 앨범 파서 라고 지정
    • 웹 상의 테스트는 어떤 것이 있을까?
      • 웹 상에서 테스트 코드를 작성한 것이 처음이다.
      • 요청 했을 때 response가 success/fail 인지 테스트 한 것
      • cf) 웹페이지 자체를 테스트 하는 것도 있음
    • 주요 이슈
      • 여러개의 플레이어를 정적으로 가져와도 작동하지 않는다.
      • 단일 책임의 원칙
        • 유튜브 데이터에서 가져오는 것은 유튜브 URL, 이미지 URL 두가지가 있음
        • 한 메소드에서 처리를 해도 되는가? 단일 책임의 원칙에 위배되지 않는가?
      • 테스트 관련
  • 호구의 코드
    • 인코딩 이슈
      • 기본 인코딩과 표시되는 인코딩이 UTF-8로 같은데 아직 해결책을 찾지 못함
      • cf) 스프링 프로젝트의 경우
        • 톰캣의 기본 UTF 설정 값이 있는데, 헤더에 해당 인코딩을 추가하지 않으면 기본 UTF 값으로 적용된다.
    • 유튜브
      • 컨트롤러 생성
      • 전체 30개의 데이터를 가져옴
      • 파싱한 것은 컨트롤러로 이동
      • 한 메소드 안에서 URL, TITLE을 가져옴
        • 단일 책임의 원칙?

 

단일 책임의 원칙

의견1

  • 유튜브 URL을 얻는 메소드 내에서 이미지 URL을 얻는 메소드를 사용함
  • 이미지 URL을 얻는 메소드를 사용하는 과정에서 유튜브 URL을 얻을 때 사용한 소스를 재활용함
    • 소스 - 파싱해서 가져온 HTML 코드
  • 역할로 본다면 두가지가 같다고 이야기 할 수 있다.
의견2
  • 클래스 이름은 네이버 파서인데, 유튜브 URL 기능을 사용하고 있다.
    • 벌써 단일 책임의 원칙을 위배하고 있다.

의견3

  • 보기 나름이다.
    • '유튜브 데이터를 뽐아옴' 이라고 표현한다면 하나의 기능이다.
    • '제목 /앨범/가수'로 본다면 각각이 다른 기능이다.
  • 타이틀/URL을 따로 사용할 필요가 없다고 생각해서 메소드를 따로 가져올 필요가 없다고 생각한다.
    • 리팩토링 해서 나누면 나눌 수도 있다.

의견4

  • 기능별로 나눠야 한다.
  • 메소드 이름이 crawl 인데 그 안에 parse 가 들어가는 것은 단일 책임의 원칙에 위배된다.
  • 다른 메인의 흐름을 갖는 메소드가 더 필요하다.
    • parse와 crawl 을 호출하는 메인 메소드

 

구현 방향

  • 모나의 생각
    • 컨트롤러에서 구현 -> 모델 -> 모델 안에서 클래스를 상속받음 의 순서대로 구현
    • crawling 등을 active record 를 상속받는 모델에서 하는 것은 말이 안된다.
    • 소스코드의 위치는 모델 하위에 잇는 것인가?
  • 호구의 생각
    • concens의 역할
      • 모델에서 데이터를 저장하기 전에 모듈을 저장해 두는 곳
      • ex) 해쉬 변환, beforesave 등과 같은 모듈

 

추상화

 

호구의 이야기

  •  넥스트에 잘 온 것 같다.
  •  물어볼 곳도 많다.
  •  기존의 지식을 갖고 할 수 있었다.
  •  프로그래밍은 오픈 소스 등이 많고 한번에 머리속에 넣는 것이 안되니까 거부감이 있었다.
  •  다 알아야 한다는 강박관념이 있었지만 불가능 하다는 것을 알게 되었다. 지금은 익숙해졌다.
  •  가끔 정말 하기 싫을 때가 있다.
  •  예전에는 학점을 올리기 바빴는데, 지금은 그런게 많이 없다.
  •  나 자신의 성장에 집중하게 되었다.
  •  지금은 프레임 워크는 많이 익숙해졌다 (라우팅, 마이그레이션 등등)
  •  예전부터 컴퓨터 공학과를 와야겠다고 생각했다.
  •  초등학교 때는 게임이 좋았고, 고등학교 때는 나중에 창업하고 싶었다.

 

스터디 회고

주디

  • 단일 책임의 원칙과 추상화를 논의하는 과정에서의 인사이트가 큼
  • 단일 책임의 원칙에 대해서 지식을 습득하는 것 뿐만 아니라, 논의하는 것이 좋았다.
    • 여러 사람이 논의하기에 좋은 주제라고 생각
    • 결과물을 빠르게 내기 위해서 우선 코딩하고 나중에 리팩토링 하면서 정리해 가는 것도 나쁘다고 생각하지 않지만, 일정한 규칙과 틀을 잡아놓고 코딩하는 것이 멀리까지 본다면 더 체계적이고 빠르게 완성 할 수 있을 것이다. 
      • 물론 구조를 잡아가면서는 시간 소요가 필요할 것이다. 
    • 개인 작업에서도 필요한 과정이지만 특히 공동작업시 분업, 개발 방향, 우선순위 등을 정할 때 도움이 많이 될 것이라는 생각이 들었다. 

 

 

 

 

  • No labels