Agile Development for Bioinformatics (bioxp) 2008

From Big Data Analytics Lab

Workshop 4th day

일정소개

  • 자동화, TDD, continuous integration, 회의를 효율적으로 하는 방법
  • 확률문제는 2D 이하라면 geometric하게 풀면 쉽다.
    • 즉 representation을 바꾸면 더 쉬워질 수도. 구간으로 그려본다던지.
    • 프로그래밍 할 때 그림으로 그려보면 더 쉽다.


  • 프로그래밍을 하면서 잘못될 확률이 있는게 무엇일까 생각되는게 있다면, heuristic 기법을 사용해서 테스팅을 해본다던지. 그 테스트를 해보는 시점은 프로그래밍 중간에 하는 것이 좋음. 프로그래밍이 다 끝나고 하게 되면, 어떤 부분이 틀렸는지 눈에 잘 들어오지 않는다.
    • e.g. random()에서 9가 나오지 않는다던지 하는 것들.


  • 프로그래밍을 많이 하다보면, 'rand()에 몇을 곱해야 하는지' 하는 것들이 idiom이 되어버려서 실수를 잘 하지 않게 된다.


자동화

코드를 자주 확인하는 것이 좋지만, 그러면 코스트도 올라가고 흐름이 끊길 수도 있다.

즉, 다른 것을 자동화하기 전에 '테스트 자동화'를 먼저 하자. 그러면 다른 것도 자동화하기가 쉬워진다.


  • 웹페이지 자동화를 배워두면 좋습니다!
    • mechanize라는 툴 -> 루비, 펄, 파이썬에 모두 있다.
    • 브라우저 자체로 자동화를 하면 느려질 수 있음.
    • 파이썬의 pamie -> 브라우저를 컨트롤 할 수 있음
    • 파이어폭스의 Selenium IDE를 이용하면 쉬움 (ie는 pamie를 이용하면...)
  • 규칙을 정해라. (욕을 세번하면 자동화를 하자. 이런식으로.)

   -> 자동화에 점점 익숙해져서 자동화 시간이 짧아진다.


Unit Test

각 단계가 맞는지 확인하는 법

  • 테스트를 할 땐, inspection point를 늘리는 것도 좋은 방법이다.
    • 불안한 부분을 함수로 쪼개거나. (random() + n 을 얻는 부분을 함수로 따로 빼서 unit test를 한다던지...)
  • python은 unittest 기능이 내장되어있고, java는 netBeans, C는 Cgreen이라는 unit testing framework가 있음.


회의를 효율적으로 하는 법

(agile 적으로 회의하는 법)

  • 인덱스 카드에 회의 절차, 회의를 할 때 이것만큼은 지키자 를 써놓는다. 그리고 회의가 있을 때 그 카드를 들고 간다.
    • e.g.
- 회의 끝나는 시간이 정해져 있어야 한다.
- 진행자가 있어야 한다.
- 서기가 있어야 한다.
- 서기는 키워드를 기록하되, 회의하는 사람들이 모두 볼 수 있는 상황에서 기록을 한다. (뭐가 결정이 됬고, 뭐가 남았는지는 사람들이 알 수 있다.)
- 한사람이 독차지하지 않게 한다.
- 끝날 때 다음 액션플랜이 정해져야 한다.
- 회의 끝난 후에 위키에 회의한 내용을 적는다. 등등등....
이런것들을 회의카드에 적는다.
  • 결과적으로 병목이 줄고, 회의 시간도 줄어든다.


  • 회의를 어떻게 할 것인가에 대해 회의를 한번 해라.
    • 어떻게 할 건지 약속을 만드는 것이 중요하다.
    • 약속을 지켰는가 체크리스트를 만들어라.
      • 회의 진행자가 있는가, 기록이 되고 있는가, 시간관리, 준비를 잘 해왔는가, 자유로운 분위기였는가,...


  • nudge
    • 내가 무엇을 했을 때 이 회의의 대화내용이 바뀔것인가를 생각해보기.
      • 실제 프로덕트를 가져온다던가. -> 지시대명사를 쓰게된다. : 대화가 구체적이되고, 오해가 없고, 진전이 생긴다.
    • 대화의 내용을 바꿀 수 있는 환경을 만들어라.
      • 추상적인 이야기가 오고간다면, 종이에 그림을 그려라. 대화의 양상이 바뀐다.
      • 사람들이 회의실에 오기전에 테이블이나 의자 배치를 바꿔보기.
    • 몸으로 내는 시그널들 (제스쳐,...)이 다른 사람들에게 영향을 준다.
      • 앉아있는 사람옆에 가서 선다 -> 말이 줄어든다.
      • 얼굴을 마주본다. -> dynamic feedback이 오고갈 수 있다.
      • 아이스크림을 돌린다. ㅋㅋㅋ


  • agile은 technical 보단 social network를 중요하게 생각한다.


  • agile 철학 중에 '용기' 라는 것이 있음.
    • 용기를 내자! 작은 것 부터 실천하라.


agenda를 만들기!

말없이 실천해보기.

how to make meetings work 라는 책.

실험해보고 직접 눈으로 보고 느껴라.


  • 의견충돌을 해결하기위해 회의가 끝날때까지 가는 경우가 있다.
    • 회의 시간을 정해라.
    • 누구나 동의할 수 있는 것을 뽑아라. 추상적 레벨을 높이거나 줄이면서 조절할 수 있다.
      • e.g. 중요한 결정 vs. 적은 정보 : 정보를 늘리기엔 시간이 걸리니 가벼운 결정으로 바꾸자.


TDD (Test-Driven Development, 테스트 주도개발)

테스트를 먼저 만들고, 그 테스트를 통과하는 코드를 개발하는 방법.

'테스트 하나 만들고, 조금 구현하고'를 반복

언제하면 좋을까? : 삽질한다는 느낌이 들때, accountability가 필요할 때

TDD는 내가 가진 자원을 full로 쓰는 것.

책: <테스트 주도 개발> - 김창준님 번역 

//
                                    // 김창준님께서 짜오신 간단한 숫자야구 프로그램
                                    //  lang: groovy
                                    //
                                    
                                    a= [5, 2, 3, 3]
                                    b= [2, 2, 3, 5]
                                    println "strike:" + (strike = [a, b].transpose().collect {it[0]==it[1] }.sum{it ? 1: 0})
                                    println "ball:" + (ball=(1..9).collect { [a, b]*.count(it).min() }.sum() - strike)

위의 코드는 함수형 언어스타일. 함수형 언어스타일은 side effect가 없다.

이렇게 기존 언어에서 제공되는 함수들을 쓰면, 실수가 적어진다.

제공되는 함수가 어떻게 동작할지 잘 모르겠는 경우에는 간단한 test를 만들어서 수행해본다.

e.g. transpose() 가 뭐하는지 모를때, assert나 assertEquals를 이용하거나, println 같은걸 이용해서 동작시켜본다. -> println ([[1,2,3],[4,5,6]].transpose())


assert관련 다른 메소드 검색

- http://labs.google.com/sets -> assert 검색
- 혹은 JUnit의 매뉴얼을 살펴보기