이슈 관리

• 이슈 관리에 대한 기본적인 활용 방법을 잘 모르고 있다.
• 라벨을 활용해 우선순위 관리를 할 수 있다.
• priority란 라벨로 prefix를 두어 관리한다.

git 브랜치 관리 전략

• release 브랜치는 왜 필요한가?
• git-flow를 활용해 브랜치 workflow를 참조할 수 있다.
• 발표자료 : 이슈관리 및 브랜치 전략에 대한 이해

소스 코드

• Github Repository : https://github.com/dobestan/ROR_Music_Parser_with_pretty_code
• Docs : https://github.com/dobestan/ROR_Music_Parser_with_pretty_code/blob/master/README.md

스터디 정리

모나/엘사의 자료

• 이슈관리

  • IMS(이슈 매니지먼트 시스템)

• iteration

  • 개발주기를 지칭하는 하나의 표현

• 이슈관리

  • 이슈란?
    • 버그, 프로그램이 동작하지 않는 부분이라고 생각
    • 큰 의미로 소통이 됨
    • 다수의 사용자가 통합적이고 일관되게 이슈를 관리하기 위해 IMS를 사용한다거나 통합적인 툴을 이용함
      • 오른손이 왼손이 하는 일을 모르는 것이 문제
      • 매니저와 프로그래머가 서로 무슨 일을 하는지 모름
      • 고객(업체)에 해당하는 사람들도 어떻게 처리되고 있는지 모름
    • 시스템으로 관리하게 흐름이 진행됨
    • 컴퓨터 분야에서 이슈라는 의미는 단순한 버그가 아니라 기능변경, 작업, 부족한 문서 등이 될 수 있다.
    • 문제점이라고만 인식되어서는 안됨
    • 문제점이 지칭 하는 것
      • 프로그램 자체의 문제점
      • 예상될 수 있는 문제점
      • 사용자 요구사항
      • 미래의 발전
  • 이슈 관리는 세가지 요구 사항 들을 해결 하기 위한 방법이다
    • 문제점 해결을 위한 디버깅
    • 코드 품질 관리
    • 사용자 요구 사항에 대한 문서화, 소통
    • 요구사항 -> 이슈 등록 -> 해결하기 위한 노력 -> 해결(문제 닫음) 의 흐름
      • 대부분의 관리 툴도 위와 같은 원칙에 따라 활용됨
  • 이슈 관리 툴은 github를  사용하는 것과 무엇이 다른가?
    • 이슈 관리 툴 대부분을 프로젝트 관리 시스템이라고 하는 것이 더 맞을 것 같음
    • 이슈 관리 툴은 소스코드 관리 / 위키 정리 / 해당하는 사람들과의 연락 등을 제공함
    • ex.레드마인을 갖고 팀 프로젝트를 의뢰 할시 소스코드를 서로(개발자,고객)확인하거나 진행률을 보여주는 등을 정리할 수 있음
    • 이슈 관리 쪽에 특화되어있다고 생각하면 됨
    • github는 저장소를 갖고 있으면서 이슈관리 및 위키 등도 갖고 있음

• 브랜치 전략

  • 소스관리, 형상관리, 버전관리 등

  • 효과적으로 브랜치를 나누고 어떻게 관리하는가

  • 어떻게 약속되어서 사용하는게 효과적인가?

  • 주요 브랜치

    • 주요 브랜치는 통합브랜치
    • 계속 바뀌지 않는 것들 계속 갖고 나가는것
    • master 브랜치 : 최종적으로 완성된 소스를 보유하고 있는 브랜치
    • develop 브랜치 : 현재 구현하고 잇는 개발중인 브랜치

  • 보조 브랜치

    • feature, release, hotfix
    • feature 브랜치 : develop 브랜치에서 기능을 만들기 위해 feature+[기능] 브랜치를 생성하고 그 곳에서 구현한 후, develop 브랜치로 머지
    • release 브랜치
      • 배포하기 전의 사소한 버그, 남겨야 하는 메타 데이터 등을 설정하는 브랜치
      • release 하게 되면 태그를 남겨서 어느 정도까지 구현이 되었고, 어느 시점에서 무엇을 했다고 스냅샷을 남길 수 있음
    • hotfix 브랜치 : release 브랜치에서 치명적인 버그가 발생되었을 때 급하게 수정

  • fast forward vs three way (????????)

    • 머지하는 대상 자체가 같은 근간에 있는가 따로 떨어져 있는가?
    • 옵션을 주게 된다면 어느 부분에서 어떻게 머지 되었나 기록됨
    • 참조한다면 롤백 할 때, 어디에서 어떻게 소스코드가 진행되었는지 파악하는데 도움이 될 것 같음
• git flow
  • 추가적인 확장 팩
  • git flow를 만든 사람이 설명하는 부분
    • git의 확장판
    • 높은 수준의 저장소를 다루는 명령어를 포함하고 있음
  • (째롱의 설명 ㅠㅠ...)

엘사의 코딩

• 루비코드로 구현 -> 레일즈로 옮기기 -> 템플릿을 이용한 구현
• 루비코드 구현
  • 글자, embed 코드를 가져오는 것
  • 기능 구현 위주로 빠르게
• 레일즈로 옮기기
  • 설계 구현 없이 기능적인 구현 위주로
• 최종
  • DB에 있는 정보를 가져오고, new를 주면 파싱함
  • 로컬DB에 추가
  • 누르면 노래가 나옴
  • 유튜브 숨겨져 있음
• 설계
  • 첫번째 계획은 아무것도 없이 모듈을 써보자고 생각함 (concern)

  • 여러가지의 기능이 한 컨트롤러에 들어가야 겠다고 생각

  • 시작하기에 앞서 원칙을 정함
    • separation of concerns (관심사를 나눈다)
      • concerns - 코드에 영향을 미치는 정보의 집합
      • 코드가 높은 응집도를 갖고, 낮은 결합도를 가져야 한다.
    • 캡슐화 
      • 다른 개발자가 나의 소스를 봤을 때 무슨 역할을 하는지는 알지만 어떻게 구현되는 것인지는 더 파봐야 안다.
    • 컨트롤러는 단순하게 모델과 뷰를 연결해주는 역할만 함
      • 모델을 무겁게 짜자
  • 개발 명세를 작성함
    • 과정은 c-> p -> c -> p 의 과정을 갖고 잇음
    • 앨범 모델은 두 concern을 갖고 있음
      • 1번, 3번 크롤링 관련한 모듈을 상속받고 있었다
      • 2번, 4번 파싱과 관련한 기능이 있어야 한다.
    • 앨범의 역할이 3개
      • 크롤링, 파싱, 앨범헬퍼를 extend 하는 것
      • db에 대한 validation 
    • 단순하게 컨트롤러에서 get albums를 실행 2가지 호출
    • 타이틀 / 아티스트를 받아옴
    • 받아온 것을 이용해서 유튜브를 받아옴
    • 공통적으로 쓰는 것은 concern으로 사용하고 상속받음
  • 이슈
    • 모델과 db와 1대1 매핑이 안되는 것이 문제점이라고 생각함
    • daum_album 클래스와 1대1로 매핑되는 테이블이 없는게 이슈였다.
    • 네이버 앨범이나, 다음 앨범 등을 만들지 않고 일반 클래스로 만든 다음에 파라미터로 객체를 넘겨서 할 수 있을 것 같지만 고민을 해봐야 함
    • 테이블이 현재는 하나이다.
  • 논의
    • 모델에 클래스 내용을 구현했다가 일반 클래스로 바꿨음
    • active record를 상속받는 클래스에서 인스턴스를 생성하는 것이 부담스러움
    • 모델은 그냥 둠 / 하나의 인터페이스로 작용할 클래스 둘을 상속받을 각각의 클래스가 있어서 구현하면 되지 않을까.
    • 컨트롤러에서 어떻게 해서든 모델을 연결시켜야 하는데, 어떻게 연결 시킬 것인가?
    • active record를 상속받는 모델 vs 일반 클래스도 비즈니스 로직을 포함하고 있으면 모델
    • 파싱하면 앨범 인스턴스가 만들어짐 앨범 테이블에 담김

주디의 이야기

• 프로그래밍이 좋아서 넥스트에 들어왔다.
• 무작정 지원을 해서 프로그래밍을 시작하게 되었다.
• 프로그래밍을 시작했는데 블로그 만지던 수준이 아니기 때문에 처음엔 어려웠다
• 1~2학기 때는 하라는 것만 했는데, 프로그램을 짜고 어떤 과정을 이해하는 것은 개경프때부터 시작됨
• 예전에는 프로젝트를 하면서 따라갔는데 이제는 사람들한테 보여줄 수 있는 페이지를 만들고 싶어서 하고 있다.
• 스스로 찾아서 하고 싶은 것이 늘었다.

• 공부 방법
  • 학교에서 프로젝트를 하면 따라가는 프로젝트가 있고 개별적으로 만드는 프로젝트가 있다. 교수님을 따라갈 때만드는 것은 베껴쓰기 수준인데 개별적으로 만드는 것은 모두 다시 쳐보면서 내코드를 친 것이다. 
  • 전체적으로 다시 구현하다보면 이해하면 이해하는 부분과 이해하지 않는 부분이 나온다. 
  • 베껴씀으로 인해서 어떻게 구성되어 있는지 모두 보게 된다. 
  • 어떤 메소드 안에 어떤 기능이 있는지 머릿속에 잘 들어온다. 
  • 구현된 내용이 어떻게 다른지, 어떤 차이점이 나오는지 등을 보게 된다. 
  • 베껴쓰면서 나만의 코드로 바꾸는 것도 많다. 즉, 나만의 리팩토링을 한다.
• 개발에 있어서 올해의 목표
  • 익숙해지는 것. 서비스의 흐름을 떠듬떠듬 이해하고 있다. 익숙해지기 위해서 재미있으려고 하는 것 같다.
  • 다 익숙해지면 뚝딱 만들고 빠르게 파고 들어갈 수 있어서.
  • 아직 벽이 느껴지기 때문에 허무는 것을 하고 싶다.

엘사의 이야기

• 내가 개발을 해야 제대로 된 창업을 할 수 있겠다는 생각을 함
• 2013년도 초에 C를 처음으로 하면서 vi 로 시작! 지금 생각하면 잘한 선택
• 포인터 개념도 모르고, C를 한번 봤다 하는 정도로
• 시간이 지나고 자신의 수준에서 할 수 있는게 없어서 재미가 없었다.
• 방학때부터 C를 시작하고 2학기 때부터 컴공 전공을 듣게 되었다.
• 수업중에 프로그래밍을 프로그래밍 답게 짜는 법을 배우게 되었고, 생각이 개발자 스럽게 바뀌었다.
• 72시간 내에 서비스 만들어 내는 것이 개인적인 목표
• 현재는 나와 개발이 잘 맞는 것 같다.