Agile Development for Bioinformatics (bioxp) 2008
From Big Data Analytics Lab
Contents
[hide]Workshop 3rd day
'살리고' 철학의 두가지 접근
1) 속에서 부터 키워나가는 방법
e.g. 지뢰찾기: 점하나 -> 1차원배열 -> 2차원배열
-> 어떻게 문제를 해결해야할지 감이 올때 사용.
2) 겉을 만들고 속을 채워나가는 방법
e.g. 미로찾기: 꼬리에서부터 거슬러 내려오는 방식
e.g. 지뢰찾기
hint(array) 함수에서 제일 처음 하는일은 return [[2, -1, 2], [2, -1, 2], [1, 1, 1]] 이걸 프린트하도록 먼저 짠다음 속에 살을 채워나가는 것.
return 값중에서 2는 무슨 의미인가? 이런식으로 각 숫자의 뜻을 전개를 한다.
2 = 1+ 1 이라는 의미를 갖고 있다면, 1은 어디서부터 왔는지 array[x] 를 각각 써준다.
이런 방식으로 점점 전개해나가는 방식.
어떻게 문제를 해결해야할지 감이 오지 않을때 이 방식을 많이 사용.
-> 두가지를 alternating하는 경우가 많다.
- 살리고 철학을 적용하기 어려워할 때가 for문이 나타나기 시작할때. (무 -> 유가 창조되기 시작할 때)
e.g. 원하는 결과 : 1,2,3,4를 출력하기
println 1
println 2
println 3
println 4
for (int i=0 ; i<4 ; i++) println i+1
잘 하는 사람이라면 이렇게 바로 할 수도 있지만, 먼저 패턴이 드러나게 전개를 해본다.
int i=0;
i=1; println i
i=2; println i
i=3; println i
i=4; println i
여기서 println i가 반복되고 그 앞부분만 변화된다는 것을 알 수 있으므로 수정하면,
int i=0;
i++; println i
i++; println i
i++; println i
i++; println i
이제는 패턴이 보인다.
내 머리에 열이 오고 있다면 잘못되고 있다는 signal!!! -> 이럴 땐 되돌아가라!!
UPGMA programming
distance matrix로 서로 clustering 하는 방식.
A B C
A
B 2
C 3 4
여기서 가장 거리가 가까운 애를 찾아 먼저 grouping -> A, B가 한 그룹이 됨.
A,B C
A,B
C 3.5
A,B와 C의 거리는 A,C의 거리와 B,C의 거리(그룹끼리의 세부적인 거리)의 평균.
출력: ((A, B) C)
탐험적 사고방식 (Exploratory Testing) - Testing 탐험적 사고방식
exploratory <-> scripted
- 마치 '스무고개' 같은.
- EDA (Exploratory Data Analysis)
- 머리를 full로 쓰는 것!
- 뚜렷한 목적이 없고, 뭘 알아야 하는지 모르는 상태에서 질문을 하고 방향을 바꿔나가는.
- 디버깅할 때 필요하다.
- Test를 할 때 분명히 맹점이 생긴다.
- 구성요소
1) Charters
2) Observation(관찰을 많이 함)
3) Notetaking(적어가면서)
4) Heuristics
- 비 전문가가 전문가가 될 수 있다.
(같은 사건을 봤을 때, 전문가보다 비전문가가 더 많은 것을 생각해낼 수가 있다.)
- None, Some, All
e.g. 체크박스를 테스트해볼 때, 하나도 선택을 안하는 경우, 몇개 선택하는 경우, 다 선택하는 경우를 테스트 해본다.
- too Small, too Big, just right
- data type : 숫자인데 스트링 넣어보고...
- user tour: 이 프로그램을 사용할 서로다른 특징의 5명을 생각해서 그들이 어떻게 사용할지를 상상해보기
- soap opera test: 개연성은 있지만 일어나지 않을 것 같은 과장된 스토리를 만든다.
e.g. sotial networking 서비스의 경우, 포주는 어떻게 사용할까? 를 생각해본다던지.
- 어떤 문제에 대해, 내가 이걸 어떻게알지? 이걸 어떻게 반박하지? 를 생각해본다.
- 사고의 패턴
- where are we? (WAW) : 현재 상황 정리
- watch, learn, leverage (WLL) : '그냥 지켜보는 것만으로도 배울 수 있다.'. 어떤 에러가 났는지 찬찬히 살펴보기.
- what happens when (WHW) : 무엇을 했을 때 어떤 일이 일어날지 생각해보기. 뻔한 답이 나올 input만 넣지 말자. 즉, 1, 2, 3을 순차적으로 넣어보는게 아니라, 2를 넣어보고 -1을 넣어본다던지.
- wise choice (WC) : 여러선택이 있을 때 뭐를 해보면 학습이 최대화가 될까를 생각해서 현명한 선택을 해라.
다음번에 뭘 해보면 좋겠다- 라는 것을 적어가면서. 한 발 더 나아가면 이 일을 해보면 어떤 결과가 나오겠다는 것도 적어본다.
생각나는 것을 다 따라하다보면 흐름이 엉킬 수 있다.
리팩토링(refactoring)
- 프로그램의 behavior를 바꾸지 않으면서 structure를 바꾸는 것.
- w -> w. 작동하는 상태에서 하는 것.
- 교각 뷰 (bridge analysis)를 사용. 있던 다리를 놔두고, 새로 다리를 만든다음, 있던 다리를 없앤다.
- 중복이 있거나 의도가 드러나지 않을 때 리팩토링을 함.
- agile: 미래 변화에 잘 대응하는 방법. 중립을 잘 지켜야 한다. 시스템이 적응력이 뛰어나고 말랑말랑해야함. specialization이 되어있지 않을 수록 좋음.
- 깨진창문이론
- 뉴욕경찰이 버려진 건물들의 깨진창문들을 새 것으로 고쳤더니 범죄율이 떨어졌다. 즉, 깨끗한 코드가 아니면 계속 똑같이 실수를 하거나 더럽게 갈 수가 있다.
- 내가 하고자 하는 의도를 드러내는 것도 리팩토링. 의미가 확실하도록 변수이름을 준다던지...
- 불필요한 코드들을 지우는 것도 리팩토링. 주석처리 해놓은 것이라던지..
- 코드의 양이 줄어드는 방향으로 가는게 좋은것.
- 리팩토링을 하다보면 최적화할 수 있는 요소를 발견하기도 쉬워진다.
- 개발시간이 더 길어질 수도 있지만 양질의 코드를 원한다면 개발 후 바로 리팩토링을 하는 것이 좋다. 개발과 리팩토링 사이에 시간의 갭이 커질 수록 코스트가 올라간다.
- 일반적으로 프로그램을 한 번 만들면 한 번 쓰고 버릴 것이라고 생각들 하는데, 보통은 나중에 다시 쓰는 경우가 많다.
- 리팩토링을 하면 학습을 하게 된다.
- 리팩토링은 습관이 되는 것이 좋다.
- 리팩토링하면서 로직이나 이런것들이 완전히 바뀌어도 상관없다. 단, 로직을 구상해서 확 바꾸는 것이 아니라, 리팩토링을 해가면서 서서히 로직이 바뀌는 것이 좋다.
- 리팩토링을 하는 기본적 단위들
- 중복(3 스트라이크 - 2번 중복까지는 봐주고 3번중복되면 리팩토링 하자. 등)
- 하드코딩된 값들
- 의미가 불분명한 단위(변수)
- 남의 코드 리팩토링할 때
- 최소한 당사자에게 양해를 구한다.
- 같이 리팩토링을 한다거나....