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

이슈 관리

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

git 브랜치 관리 전략

소스 코드

 

스터디 정리

모나/엘사의 자료

  • 이슈관리
    • 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시간 내에 서비스 만들어 내는 것이 개인적인 목표
  • 현재는 나와 개발이 잘 맞는 것 같다.
  • 공부방법
    • 시간을 짧게 잡고 많이 하는 편 / 하나를 집중적으로
    • 손코딩 많이 함 거의 다 씀, 큰 구조는 다 그린다. 상세 구현도
    • 문법 등도 다 외워야 한다. (vi 를 써야 하기 때문에)
    • 손코딩이 처음엔 오래 걸렸다.
  • 손코딩 하는 것에 의미
    • 생각을 정리할 수 있다.
    • 코드에 대해서 컴퓨터로 치면 내게 되지 않는 느낌인데 손으로 쳤을 때는 직접 다 생각을 해야한다.
    • 코드의 모든 부분을 관리할 수 있다.
    • 컴퓨터로 짜면 굉장히 빠르게 짤 수 있다.
      • vi는 생산성 자체는 낮은데 생산성 보다는 공부 위주로 하기 떄문에 괜찮다.
    • 학습하는 단계에서는 vi나 손코딩이 의미가 있다.
    • 빨리 짜고, 빨리 지우는 것을 좋아함
  • 함수형 언어(레킷?)를 쓸 때의 장점
    • 사람 머리가 한계가 있기 때문에 너무 어려워서 코드를 길게 짜지 못한다.
    • 그때부터 코드를 나누는 것이라고 습관이 되었다.
    • 모든게 함수로 되어있다 보니까 많이 생각하는게 달라진다.
    • C나 자바를 공부했을 때 비교하면서 사고의 폭이 넓어짐

 

 

  • No labels