MapReduce

Posted by epicdev Archive : 2012. 6. 23. 04:55

출처: http://en.wikipedia.org/wiki/Mapreduce


"Map" step: The master node takes the input, divides it into smaller sub-problems, and distributes them to worker nodes. A worker node may do this again in turn, leading to a multi-level tree structure. The worker node processes the smaller problem, and passes the answer back to its master node.


"Reduce" step: The master node then collects the answers to all the sub-problems and combines them in some way to form the output – the answer to the problem it was originally trying to solve.



한장의 그림으로 요약하는 MapReduce

출처: http://www.searchworkings.org/blog/-/blogs/introduction-to-hadoop/


  

지나친 테스트

Posted by epicdev Archive : 2012. 6. 16. 02:29

도가 지나친 수준으로 테스트에 관심을 갖는 경우도 있다.


  • 테스트를 기능하게 하려고 실제 코드의 가독성을 희생시킨다. 실제 코드 테스트를 가능하게 하는 것은 반드시 윈-윈 상황이 되어야 한다. 하지만 테스트를 가능하게 하려고 실제 코드에 지저분한 코드를 집어넣어야 한다면, 뭔가 잘못된 것이다.
  • 100% 코드 테스트에 집착하는 일. 코드의 90%를 테스트하는 노력이 종종 나머지 10%를 테스트하는 비용보다 적은 노력이 들기도 한다. 그 10%는 어쩌면 버그로 인한 비용이 별로 높지 않기 때문에 굳이 테스트할 필요가 없는 사용자 인터페이스나 이상한 에러 케이스를 포함하고 있을지도 모른다.
  • 사실, 코드를 100% 테스트하는 일은 일어나지 않는다. 테스트되지 않은 버그가 있을 수도 있고 테스트되지 않은 기능이 있을 수도 있으며, 요구사항이 달라졌다는 사실을 모르고 있을 수도 있기 때문 이다.
  • 버그가 야기하는 비용이 어느 정도인지에 따라서, 테스트 코드를 작성하는 시간이 의미를 갖는 부분이 있고 그렇지 않은 부분도 있기 마련이다. 만약 웹사이트의 프로토타입을 만든다면, 테스트 코드 작성 건은 전혀 의미가 없다. 한편 우주선이나 의료장비를 통제하는 프로그램을 작성한다면 아마 테스트 코드에 주된 관심을 쏟아야 할 것이다.
  • 테스트 코드로 실제 제품 개발이 차질을 빚게 되는 일. 우리는 단지 프로젝트의 일부분에 불과한 테스트가 프로젝트 전체를 지배하는 경우를 본 적이 있다. 테스트가 숭배되어야 하는 신의 자리를 차지하고, 프로그래머들은 자신의 시간이 다른 일에 쓰이는 것이 더 낫다는 사실을 망각한 채 자신을 위한 의식과 동작에 몰두한다. 




읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


  

테스트에 친숙한 개발

Posted by epicdev Archive : 2012. 6. 16. 02:20

테스트하기 어려운 코드의 특징과 이것이 설계와 관련된 문제에 미치는 영향

특징 

테스트 문제 

설계 문제 

전역변수를 사용한다 

테스트할 때마다 모든 전역 변수를 초기화해야 한다. 그렇지 않으면 테스트가 서로의 결과에 영향을 줄 수 있다.

어느 함수가 어떤 부수적인 효과를 가지는지 판별하기 어렵다. 각각의 함수를 별도로 고려할 수 없다. 모든 게 제대로 작동하는지 알려면 프로그램 전체를 생각해야 한다. 

코드가 많은 외부 컴포넌트를 사용한다 

처음에 설정할 일이 너무 많아서 테스트를 작성하기 힘들다. 따라서 테스트를 작성하는 일이 즐겁지 않아 테스트 작성을 회피한다.

이러한 외부 시스템 중에서 어느 하나가 제대로 작동하지 않으면 프로그램이 실패한다. 프로그램에 가한 수정이 어떤 효과를 낳을지 알기 어렵다. 클래스들을 리팩토링하기 어렵다. 시스템이 더 많은 실패 모드와 복구 경로를 가지게 된다. 

코드가 비결정적인(nondeterministic) 행동을 가진다 

테스트가 변덕스럽고 안정적이지 못하다. 가끔 실패하는 테스트가 그냥 무시된다. 

프로그램이 경합 조건이나 재생하기 어려운 버그를 가지고 있을 확률이 높다. 프로그램의 논리를 따라가기가 어렵다. 현장에서 발생한 버그를 추적해서 수정하기가 매우 어렵다.


테스트하기 좋은 코드의 특징

 특징

테스트 장점 

설계 장

클래스들이 내부 상태를 거의 가지고 있지 않다

메소드를 테스트하기 전에 설정할 일이 거의 없고 감추어져 있는 상태가 별로 없기 때문에 테스트 작성이 수월하다.

소수의 내부 상태를 가지는 클래스는 이해하기 더 간단하고 쉽다.

클래스/함수가 한 번에 하나의 일만 수행한다

더 적은 테스트 코드가 요구된다.

더 작고 간단한 컴포넌트는 더 잘 모듈화되어있고, 시스템이 서로 더 멀리 떨어져 있다

클래스가 다른 클래스에 의존하지 않고, 서로 상당히 떨어져 있다

각 클래스가 독립적으로 테스트된다 (여러 클래스를 동시에 테스트할 때에 비해서 훨씬 쉽다) 

시스템이 병렬적으로 개발될 수 있다. 클래스가 쉽게 수정될 수 있고, 혹은 시스템의 나머지 부분에 영향을 주지 않으면서 제거될 수도 있다.

함수들이 간단하고 잘 정의된 인터페이스를 가지고 있다 

테스트 대상이 잘 정의되어 있다. 간단한 인터페이스는 테스트를 위해서 더 적은 일을 요구한다. 

프로그래머가 인터페이스를 쉽게 배울 수 있어 해당 인터페이스는 재사용될 가능성이 더 높다. 




읽기 좋은 코드가 좋은 코드다

저자
더스틴 보즈웰 지음
출판사
한빛미디어 | 2012-04-06 출간
카테고리
컴퓨터/IT
책소개
이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리...
가격비교


'Archive' 카테고리의 다른 글

MapReduce  (0) 2012.06.23
지나친 테스트  (0) 2012.06.16
자기 주변에 있는 라이브러리에 친숙해져라  (0) 2012.06.16
변수의 범위를 좁혀라  (0) 2012.06.15
쇼트 서킷 논리 (Short-Circuit Logic) 오용 말기  (0) 2012.06.15
  
 «이전 1 ··· 7 8 9 10 11 12 13 ··· 55  다음»